World: r3wp

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.

Maybe platform could be, 'macosx, 'linux and 'windows and variation 
something like 'intel-32, 'intel-64, etc. Or do we need a third variable?

So maybe no variation, but instead processor and bits.

Can you SWITCH on two words at once?

In fact, there's so much more than OS and bits, that it's hardly 
worth trying to come up with an all-encompassing scheme.

Others have tried, and failed.

One of the common situations where you need to do platform-specific 
stuff is in loading prebuilt libraries, and those depend on the platform 
and processor variant. That means that selecting one requires selecting 
both, or all 3 if you have a seperate bits field. One SWITCH is better 
than 3.

I would like to have platform, which is kinda the OS, I guess. And 
the consequence of what Andreas just said, then the rest should just 
go into one variable, variation.

case [all [linux? arm?] [...] all [linux? amd64?] [...] ...]

Can you SWITCH on two words at once?


Yes, SWITCH can handle that. I don't have CASE yet, but probably 
will.

Something like this?

switch [platform variation] [
	[linux intel-32] [do something]
	[linux intel-64] [do domething else]
]

(sorry, that was bad syntax, but you get the idea)