World: r3wp

Maybe I should tell a bit, how I work, to make it easier for you 
to understand, what you've got for now. I do much of assembly line 
programming, because it reduces the time of development. So when 
I wrote the lexer, I didn't just implement e.g. numbers, because 
arithmetics would be the first functionality, I would finish. I implemented 
all 40-50 datatypes, I wanted in World, in the lexer at the same 
time. So the lexer is prepared for more datatypes, than what actually 
works for now, and you will just see "Valid <something>" from the 
lexer, when it recognizes such a type.

Like:

w> 1x2 [bob-:-server-:-com]
Valid pair: 1x2
Valid email: [bob-:-server-:-com]


Btw. date! and time! isn't well implemented for now, and I'll put 
that in the next update to README.

(Actually the lexer might just recognize around 30 datatypes, because 
some types need to be created with MAKE.)

Why does world open a listening socket at port 8080?

World seems to be fussy about which directory it is launched from


Is there a way to figure out, what directory a command launches from, 
which will work across platforms? I could check argv[0] in main(int 
argc, char **argv) , but that wouldn't work, if world is put in a 
bin, which is part of $PATH.

sqlab, it does by defaul?

*default

Sorry. it opened a listening socket at port 0.

What do you do to see that on your system? What os?

At first start on Win XP. I got a warning from the firewall.
After I checked with process explorer

Ok, under Windows, I found, I had to initialize the networking, so 
that's done at startup. (This isn't necessary under OS X and Linux.) 
You can see the code being executed in the function init_net () in 
the file src/host/win32/network.c. If you think, it should be done 
otherwise, let me know.

The file is found at
https://github.com/Geomol/World
if that wasn't clear.

Does R3 (or R2) also cause your firewall to give a warning?

Topic: Routines

I suggest expanding the make routine! spec to the following:

	routine-name: make routine! [
		"routine description"
		[special attributes]
		library
		"routine-name"
		[
			argument1 [arg1-world-type] arg1-type
			"argument description"
			argument2 [arg2-world-type] arg2-type
			"argument description"
			...
		]
		return-type return-world-type
	]


, where the following fields are optional: Routine description (string!), 
Special attributes (block!), Argument name (word!) and Argument description 
(string!).


Then good documentation can be made with HELP. Argument names are 
not really needed, as routines are compiled code in a library, but 
names can make the docs easier to understand.

seems to be fine... what about the return-world-type as optional?

And then it should try to guess it from the return-type?

yes

Ok, makes sense.

and maybe to make same order like for args.

Actually I had it like that at first, but I found the reverse order 
to be easier to understand. (It can be just me.) Because then I read 
a simple routine spec as: routine is in library, named "routine-name", 
take argument with world type arg1-world-type, which is converted 
to arg1-type, returns return-type, which is converted to return-world-type. 
The sequence makes good sense to me.

And [arg1-world-type] is in a block, so I can allow more than one 
type in the future.

(if typechecking is preferred)

If routine takes no arguments, the argument block could even be optional. 
Today an empty block is needed.

I do not remember clear, if all versions of R2 or R3 gave warnings 
at first start, but now they are in my exception list. And at least 
once I got suspicious of R2 too, as it initialized / loaded libraries 
not needed.


The curious thing is, that now I do not get a warning at start of 
world again. And I did not allow it, but choosed "ask again".

I guess you will get it once you type TEST end enter.

right

Is there a way to figure out, what directory a command launches from, 
which will work across platforms?

Yes and no. There are platform-specific ways. This gist of it:

- Linux: readlink("/proc/self/exe")
- OSX: _NSGetExecutablePath
- Win32: GetModuleFileNameW

(We recently discussed this issue in relation to R3 as well.)

Topic: system/version/platform

To check for which platform, World is running on, system/version/platform 
can today be:

	"Mac OS X"
	"Linux"
	"Win32"


Is that suitable? Are there better suggestions? Is there a standard 
for this?

Maybe I should call it "Linux32" and hold the 64-bit versions clean... 
So there can be a future "Linux", which is 64-bit.

The current Linux version is compiled under Linux Mint 12 "Lisa" 
32-bit.

No standard, I fear. You could use the compiler's (GCC's) target 
machine verbatim, though.

Like:

$ gcc -dumpmachine
i686-apple-darwin10

For GCC, you can see get the target machine tuple with the "-dumpmachine" 
flag. This would give you stuff like:
i486-linux-gnu
x86_64-linux-gnu
arm-linux-gnueabi
i686-apple-darwin10
i586-mingw32msvc

Yep.

Not sure if that's the best idea, but maybe worth considering.

Yes, worth considering. But do we like to type that in scripts?

My Win32 say:

$ gcc -dumpmachine
i686-pc-mingw32

I think for scripts we want a small helper library with various predicate 
functions.

REBOL use this: version.revision.update.platform.variation
See: http://www.rebol.com/docs/version-numbers.html
I could add a system/version/variation at some point.

A helper lib sounds like a good idea, then I could make changes later.

Like: linux? windows? 32bit? 64bit? etc.

ARM, X86, MIPS? There's more than just OS and bits...

That can be handled with system/version/variation, which I'll add.

Then you might consider having the platform be a word of just the 
platform name, but also include a platform-plus-hardware word in 
a different field. This would make specialty code that switches on 
the OS (for API stuff) or full platform (for selecting native code) 
much easier to write.

So platform: 'windows but variation: 'windows-intel-32

Or whatever your naming convention is.

I see your point. It's not easy to find a good way, that is sure 
to cover all future possibilities.

I went for strings, so it could be e.g. "Mac OS X" and not the word 
mac-os-x.