AltME groups: search

hmm, what a pity ... if all agree, that having OS Rebol is a good 
thing, even for RT, then I wonder why noone want to release? What 
is the point in having Rebol clone sitting on own hd, unreleased?

I don't know how that works on OS X. I only know that it just works 
on other Unixy systems such as Linux and Syllable

If extra code is required on OS X, then that can be expected from 
finished commercial apps, but Boron is a volunteer project a year 
old

How do you start R3 on OS X? Isn't there an app setting where you 
must tell OS X to start a command line program in a terminal?

I mean like each application is forced to put its dependecies into 
specific folders within its install path.  this way you can very 
easily verify that things are wath they should, and can make OS lib 
calls which act with confidence.

its hard when the damn paths are so obscure that you need to call 
the OS using libs to get the paths confidently.
its hard when those paths change all the time.
its hard where there are more than one path per application.


its just really complex when the darn paths could be simple... even 
on linux, they keep changing the paths almost every release on some 
distros.. it gets ridiculous.

hopefully with MS recent october 22 announcement of the canning of 
XP we can finally forget that OS for install targets :)

So you aren't comparing Classic, you are comparing running OS X 10.1 
apps in 10.6.

well, they just relax the enforcement... the rest of the os is still 
there... they still support most of the old api, its still just a 
tack-on more stuff and try to make it compatible again.  I know some 
of the kernel changed, but that doesn't really affect applications 
that much, since that is mostly doing stuff behind the API wall.

that will probably happen in the next OS they are taunting us with... 
their cloud OS thing.

anyhow... all I meant is that windows should have started from scratch, 
learn from past mistakes and build the leanest/cleanest OS they every 
built, instead we end up with an install which takes several GBs 
on disk and 2GBs of RAM minimum to run.

Adrian, "so it executes"  I meant installing rebol in the OS via 
file extensions so it always uses the -qs arguments over and above 
those it gets from the explorer.


also can shortcuts have arguments in win7?  this was removed in vista.

another thing which is missing is explicit font path.   The Os might 
not know, but at least if we could configure it manually then we 
could script independently of linux install.

as a reboler, I don't want to write system specific and environment 
 resolving code.  


my script should be able to ply itself to whatever system its installed 
on and still read/write its files in proper OS expected places.


This is what we are talking about Andreas... viewtop specifically 
has nothing to do with this.  this is for ALL scripts to be compliant.


if I had a command which allowed me to build a system-compliant "application 
data path" then it would write stuff in ~/application/ on linux and 
whatever profile/app data/application   path is being used by your 
flavour of windows.


right now, I'd have to write a library which determines this and 
it probably will screw up on ubuntu, or Mac Or the latest windows.

things like user names and user folders have to be extracted within 
a routine using proper OS calls, either WinAPi or Env values if that 
is what your OS uses.

and yes... you have to manually change the command-line arguments, 
but then the OS' editors break up in what I can't remember, I think 
rebol disapeared from the "installed applications" list, although 
the file association still worked.

Does ACCESS-OS do anything on Windows?

What we got in 2.7.8, that I know of:

- Bug fixes and enhancements to improve Cheyenne, and other apps 
that have to do similar stuff.

- Some native fixes for non-Windows platforms, particularly Linux. 
See ACCESS-OS.

- Environment variable stuff: GET-ENV expansion on Windows, SET-ENV, 
LIST-ENV

- Function fixes: SELECT object!, FIND object!, RUN enabled, LIST-REG/values

- R2/Forward: FUNCT/extern, LAST?, COLLECT-WORDS, RESOLVE, APPLY 
fixes, EXTRACT fixes, ASCII? fixes, LATIN1? fixes, INVALID-UTF?, 
CD, LS, MORE, PWD, RM

Instead of access-os there are also new natives list-env and set-env

Karl has published the 3D Boron demo, including OpenGL Boron builds 
for Linux and OS X:

Consistency between OS platforms. On platforms other than Windows, 
/Core doesn't need X or any other kind of GUI, and so doesn't require 
the libraries (good for headless servers). When there is no GUI, 
there is no clipboard. The Windows version of R2 just inherited this.

I suspect that the problem is more likely to be with 'call than REBOL 
in CGI mode as REBOL/Services  runs as a CGI under Xitami on Windows.

The problem does not occur on OS X.

are there known bugs where DECOMPRESS works on certain data in one 
OS (OSX here), but not in another (Windows XP)?

I did this under OS X with R2:

>> write %/Volumes/NICOM/test.txt "Testing..."
(and the files was produced, then)
>> rename %/Volumes/NICOM/test.txt %/Volumes/NICOM/test2.txt
** Access Error: Cannot rename test.txt

So an error.

Reading the source for RENAME, it rename the file by changing its 
name in the directory file. And this doesn't work for some reason 
with USB sticks under OS X using R2.

rename capabilities in file handling do not normally allow paths 
to be used (in the OS itself).  otherwise these are a called 'move 
file operations. 


e.g. if you try using paths with rename in the DOS shell, you get 
errors.

In answer to your comments link above:
- Syntax errors are triggered before semantic errors: 1.3, 11

- Words that start with + and - are special because of potential 
ambiguity with numbers: 1.1

- Arrows are only allowed in the special-case arrow words, not generally: 
1.2, 1.3, 4

- %: is ambiguous - it could be a file that wouldn't work on any 
OS, or the set-word form of %, so an error splits the difference: 
10.2
- Fixed already: 2.2 for arrows in R3, 7, 13


Some of the rest are related to http://issue.cc/r3/537and others 
have been reported already. If you want 10.2 to not trigger an error, 
it is more likely to be accepted as a set-word than a file. Thanks 
for these, particularly the lit-word bugs.

Crashes under OS X too:

>>  -1 * -2147483648
Floating point exception

I thought several times to implement FORM-DECIMAL in C and support 
the different country styles. Should be queried from the OS. And 
yes, all Rebol functions should be aware of this.

I want to share with you an "interoperability problem" I encountered. 
In Windows (at least in not too old versions) there are two versions 
of string-handling functions:

- ANSI (in fact using a codepage for latin charset)
- widechar (in fact UNICODE, restricted to 16 bits, I think)


It looks, that Apple OS X "prefers" to use decomposed UNICODE, also 
known as UTF-8MAC, I guess. That means, that it e.g. for a Robert's 
file it generates a filename looking (in a transcription) as follows:

%"Mu^(combining-umlaut)nch.r"

As far as the UNICODE goes, this is canonically equivalent to

%"M^(u-with-umlaut)nch.r"

, but:


- Windows don't consider these file names equivalent, i.e. you can 
have both in one directory

- When using the former, the ANSI versions of Windows system functions 
"translate" the name to: %"Mu^(umlaut)nch.r"

-- the %"Mu^(umlaut)nch.r" is a third file name, distinct from both 
of the above, so, if the R2 reads it in a directory, it is unable 
to open it

Linux also would not consider them equivalent. I understand why Mac 
OS is always canonicizing file names, but, they chose the most stupid 
way to do it, and it's a pain in the ass most of the time. In the 
end, I prefer Linux where you can end up with two files named in 
a way that looks exactly the same, but that has a file system that 
behaves in a predictable way.

Build hello.exe under OS X and works under Windows :)

Kaj: if you want to cross-compile, you currently need to hardcode 
the target format in %compiler.r at:

    fmt: select [			;TBD: allow cross-compilation!
        3	'PE			;-- Windows
        4	'ELF			;-- Linux
        5	'Mach-o		;-- Mac OS X
    ] system/version/4

I wanted to get back to the roots (80's for me) of computing, a time 
where an entire OS + programming langage could fit in a 16KB ROM 
;-).

I'd allow for 20KB, though. Atari was 8K OS + 8K BASIC + 4K decimal 
floating point :-)

Btw, PIC mode will have to be supported at some point of Red evolution 
in order to be able to build dynamic libraries for Linux (don't know 
for OS X).

Rebolek: maybe OS X requires position-independent code for executables? 
Checking it right now...

Have you defined a new runtime in red-system/runtime/ for OS X?

Does OS X support the same syscalls?

Andreas: that's the idea. All Red/System features are here to serve 
either the interfacing with OS and third-party libs (mostly C libs) 
or to serve the upper layer (Red) needs.

If you need some external eyes to look at your code or test it (I 
can test on OS X), you can "gist" it  (https://gist.github.com/) 
and put the link here. I, Andreas, or someone else could have a look 
at it.

After re-reading the new specs draft, I noticed a few errors in the 
pointer! examples. Also, I think that having struct! passed as value 
by default was a bad move, it makes the "passed by reference" case 
too verbose (requires to declare a pointer! [struct! ...] and a get-word! 
syntax). I think that I'll revert default struct to be passed "by 
reference" and find a special syntax for the extremely rare cases 
when a struct needs to be passed by value. I can't remember any OS 
API nor mainstream C lib that require passing struct by value (anyone?).

I just visited the Haiku OS website, and I can see, that it was accepted 
for the Google summer of code 2011. Maybe once Red becomes an alpha, 
we could apply too? Let's say for 2012 :-)

could be a good way in a middle term to have tools + OS etc in a 
single CD

This after going through the Atari trauma, and having decided never 
to do that again, seeing all those other people go through the Commodore 
trauma, the Amiga trauma, the RISC OS trauma and the BeOS trauma

Only following this whole cool stuff here from the side, but what 
would be really cool is, if Red can live without any specific C lib 
binding. Either by providing the used functions itself in a sideeffect 
free version or by adding support to a OS free lib that can run on 
bare metal.

Robert: being free from any dependency (including C lib) is my intention, 
but:
- C lib is available as system library in any major OS

- C lib functions are more optimized, so will run faster than Red/System 
alternatives


However, as I would like to be able to make Red (or just Red/System) 
run on many embedded platform too (e.g. Arduino and NXT), I don't 
want to have to statically link with C lib there (because of the 
memory footprint). My current idea is to provide both: C lib bindings 
and alternative functions coded in Red/System only, in a transparent 
way for the user.

Doc, the thing is, yes on an OS there is a c lib. But what if you 
don't have an OS or don't need one?

So, how about a way to always keep a list of external used functions? 
This make it simpler to make Red totally stand-alone later. The hard 
part to get rid of all the lics & OS stuff is, that you have to find 
out, which functions you have to "clone".

I would be suprized if there was no C compiler for all those plug 
computers, but anyway, I will do my best to have a dependency-free 
Red core option. I will keep all the core bindings in separate per-OS 
files, so it will be easier to track them.


I guess it would be fun to implement a micro-OS in Red/System for 
these micro-platforms, I always wanted to get my hand on a custom 
TCP/IP stack implementation :-) .

There is a C compiler but the clib is mostly dependent on the OS 
as well. So, no standalone, bare metal C lib. That's the problem. 
Using the clib, you need to have the OS as well.

Well, the details of Red implementation are not have been yet documented, 
but the general idea is to implement as much features as possible 
in Red itself relying only on Red/System's support functions exported 
to Red level. So for networking, Red/System should publish to Red 
the low-level OS mappings required and let Red implement everything 
else. This is the plan, but it not set in stone, it could be changed 
during implementation if a better approach emerges.

I think Steve Shireman has done TCP stacks in the past. 


My only recent thought, related to OS dependencies and such, was 
what it would be like if your only interface to files was a memory 
mapped file interface. Thinking about languages and desktop/server 
systems, not the embedded stuff.

I did such installation several times, manually configuring everything, 
last time was in 1997. An OS requiring me to do that in 2011 is a 
joke.

when writing a new emitter, the "challenge" is mostly the rather 
tedious task os transliterating C structs into REBOL struct!s

(I messsed up the copy from Windows to OS X.)

Got a very simple Red/System program running on OS X: 
    Red/System [ ] quit 42
;-)

It took me a few hours to write the file emitter but a full day of 
debugging to make it work. It seems that the issue was related to 
stricter stack alignment requirement on OS X (16 bytes alignment) 
and a different ABI for syscalls. 


It currently works thanks to a few hacks, but I need to extend the 
IA-32 emitter to implement these new requirements in order to make 
it output correct code for OS X.

For those curious about Mac OS X low-level ABI for function calls: 
http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/LowLevelABI/130-IA-32_Function_Calling_Conventions/IA32.html

Doc, great news for those of us who primarily develop on OS X these 
days.

Not only those. I appreciate the ability to target OS X without having 
to run it or know anything about it :-)

It also seems it's only required for system calls on OS X

Only OS bindings.

And I need to change the OS default selection code in the compiler, 
so that the `-t Darwin` option won't be required when running on 
OS X. That fix will also enable the unit tests to work properly.

The unit tests run in approximately two-thirds of the time under 
OS X than they do under Windows/XP running under VirtualBox.

Load time = Red executable load time. The OS does the job of binding 
the required shared library and making their functions available 
to Red/System programs.

Mac OS X now fully supported: http://www.red-lang.org/2011/07/mac-os-x-port-released.html

Tested ok on all OS (including Syllable).

I mean: it looks like Syllable is not initializing the C lib the 
same way as other OS.

It would be surprising if it would, because this is very OS specific

Well, then I am ok to add that libC init call in Syllable's runtime 
part (runtime/syllable.reds) as long as it doesn't need any other 
OS-specific additions in Red/System.

I won't add it for other OS until it becomes mandatory for Red.

Tasking

 will be brought by actor! datatype which will use a pool of OS threads 
 underneath. I am not sure what you mean precisely by "events". Liboop 
 and libevent are nice libraries, but probably overkill for Red, so 
 I will implement similar low-level OS bindings specifically for Red 
 (probably merged in the actor abstraction). For OS threads, I will 
 pick up the API provided natively by each OS.

BrianH: I need to correct a bit my answer to your question. Actually, 
there is a small code emitter dependency on the 'callback attribute. 
It is used to save special registers (edi, esi, ebx) to conform to 
IA-32 ABI. It is only needed when providing callbacks that are invoked 
by the OS or external libraries.


I should be able to keep this feature in the new revision while making 
it transparent to the users.

Kaj, this may be a dumb question but what OS are you using?

It's a choice we can reconsider once Red/System will be rewritten 
in Red. But we'll probably end up choosing the same option, because 
of the overheads of deviating from the format C libs and OS API expect. 
Anyway, it should be an interesting debate. :-)

Got my QEMU/ARM Debian instance working properly now. I am using 
WinSCP to automatically transfer the compiled binary files between 
the host and guest OS.

Is there possible something like CALL in Red/System? I expect currently 
"no", so what's the right aproach to it? Map system calls via wrapping 
an OS libary? Do you plan to have something like CALL to have easy 
interfacing along with PARSE in Red level? :-)

New compilation targets have been provided for Linux and derivated 
OS running on ARM:

change to 


New compilation targets have been provided for Linux and derivative 
OSs running on ARM:

Red/Systerm ARM port on OSNews: http://www.osnews.com/story/25468/Red_System_Language_Gets_OS_X_ARM_Android_Backends

Mac isn't tagged as an OS on Freecode

ditto for Syllable. But I am not sure OSNews.com would publish language 
alpha state news, if not OS related. I tried to report on R3 alpha 
and some milestones, and it was refused ...

I don't see the necessity for an external lib for concurrency or 
events management, when the OS are already providing everything we 
need (I guess that pthread lib is standard part of Linux now?).

on-quit: function [  ; Register handler for normal program termination.
;	handler		[function! []]  ; Callback
	handler		[integer!]
	return:		[logic!]
][
	#either OS = 'Syllable [
		not as-logic _on-quit handler none none
	][
		not as-logic _on-quit handler
	]
]

Pekr: (short answer) Red/System (and Red) generate executable binaries 
while R2/R3, while World and all other interpreted languages just 
run code in an interpreter or VM. This is a big difference, because 
Red can use the OS to load libraries at "load-time" instead of having 
to write code to do it (as all others interpreted languages require). 
This is also faster than loading manually. Red/System doesn't have 
yet a x-platform extension for adding "run-time" library loading 
support, just because we don't need it at all for now, but it can 
be added easily, by wrapping libFFI for example, or implementing 
it purely in Red/System.

But all the OS and third-party libraries we're currently using in 
Red/System have stable API, not the need for runtime loading has 
not appeared yet.

Pekr: you've mixed up completly "load-time" and "run-time" library 
loading. You don't need a library handle at "load-time" (unless you 
want to hack something in the OS). Also, you don't need any of your 
code above, just the #import declaration with the right function 
names (finding the right names seems to be the most complex part 
in the case of the library with the weird API you're using)

Q: Will this language be an open or closed source project?


A: Long answer: The plan is to fully open source it at some point, 
when version 1 is ready. Host depending sources are open in the alpha 
release, and it may make sense to open source more and more along 
the way, like sources for the different datatypes. The IT world is 
constantly changing. My nephew just went to the Devoxx Java conference 
in Belgium. Everybody had portable Mac computers. That was very different 
just a few years ago. Who knows, what devices we'll use in 5 years? 
I like to bring my software with me to new platforms. To be able 
to support new platforms faster, open source is a good thing. But 
some things needs to be fulfilled, before I'll open source it all.

1. This isn't a hobby project. I've invested a lot of time and work 
in this project, and I need to find a way to get something back from 
all that. One option is to have a good manual ready for developers 
to buy, open source it to get a lot of developers interested, and 
make a profit that way. There may be other ways (like someone or 
some company paying me to open source or make projects in World).

2. I need to know more about the consequences of open sourcing it, 
so I can avoid any nasty surprises. Knowing more from other similar 
projects could help. I need to figure out a proper license.

3. Even if I keep the sources simple and clean, I would like to clean 
up even more, before it can be open sourced.

A: Short answer: Currently it's partly open source.

Q: What is the main target?

A: The World prompt is a very powerful tool. Being what is known 
as "network transparent" helps in the era of the Internet. Server 
scripting and client scripting are obvious uses. The ability to easily 
make dialects makes it possible to wrap the language around the problem 
instead of trying to change the problem to fit the language. Interfacing 
with other technologies ... see "Introduction" on http://world-lang.org
in a few days.

Q: Is it closer to R2, R3, RED, Topaz architecture?

A: World run its code within a custom made virtual machine (VM). 
Compiling in World compiles World sources to this VM. This happen 
when source code is run or if explicitly compiled. REBOL is always 
interpreted (AFAIK), so that's different. I'm far from an expert 
in Red and Topaz, but as I understand it, Topaz is compiled/translated 
to JavaScript. So the JavaScript engine can be seen as the VM in 
World. And Red is compiled to native code, so that's different too. 
As I see it, all these languages work differently and can complement 
each other. (Help me here, if I'm wrong in any of this.)

Q: What was the main motivation, aka - why yet another language?

A: After I've learned REBOL, I find it frustrating to program in 
most (all) other languages. The difference is like when humans moved 
from carving words in stones to using a printing press a la Gutenberg. 
Then I found, I couldn't complete projects like my Canvas RPaint 
program on all major platforms (Win32, OS X and Linux), I couldn't 
run my code on new portable devices, and I needed better performance 
with scientific applications. With my background in graphics, music 
and science, I expect the language to develop into those areas.


Q: If (you) don't have any other target, why don't you work on Red? 
Or fork a project from Red?

A: I started initial work on World in late March 2009. The first 
post in the Red group here in AltME is from 27-Feb-2011. At that 
time, World was more than 7'000 lines of C.

Q: Does World compile into bytecodes (a la java) or machine languages?

A: Into bytecodes for the virtual machine. Each VM instruction is 
32 bytes (256 bits) including data and register pointers.

Q: Can you do operators with more or less than 2 arguments?

A: Not yet. I've considered post-fix operators (1 argument), and 
it shouldn't be too hard to implement. To motivate me, I would like 
to figure out some really good examples. With more arguments, I can 
only think of the ternary operator ("THE ternary operator"). I'm 
not sure, World needs that.

Q: Is range! a series! type?

A: No, range! is a component datatype. It has two components just 
like pair!.

Q: What platforms are supported?

A: For now Mac OS X (64 bit), Linux (32 bit) and Windows (Win32). 
The code is very portable. It took me a few hours to port to Linux 
from OS X and just a few days to Windows.

Q: What platforms do you plan to support in the future?

A: It would be cool to see World on all thinkable platforms. I personally 
don't have time to support all. World is not a hobby project, and 
I'm open for business opportunities to support other platforms. The 
host depending code is open source. I mainly think 64-bit.


Q: I'm a little sorry to see the R2-style port model instead of the 
R3 style. Are all ports direct at least?

A: Yes, ports are direct (no buffering). The ports and networking 
are some of the most recent implemented. More work is needed in this 
area. I would like to keep it simple and fast, yet flexible so we're 
all happy.


Q: What in the world is going on with the World Programming Language? 
This looks like something that must have been under wraps for a long 
time. What's getting released?

A: I didn't speak up about this, until I was sure, there were no 
show-stoppers. The open alpha of World/Cortex is being released as 
executables for Mac OS X, Linux and Windows (Win32), as are the platform 
dependent sources and initial documentation. World implement 74 natives 
and more than 40 datatypes. The Cortex extension (cortex.w) implement 
100 or so mezzanine functions and some definitions. The REBOL extension 
(or REBOL dialect in rebol.w) implement close to 50 mezzanine functions 
(not all functionality) and some definitions.

Q: Did you do some speed benchmark? (R3 vs R2 vc World) ?
A: Yes:

(All tests under OS X using R2 v. 2.7.7.2.5 and R3 v. 2.100.111.2.5)

- A mandelbrot routine (heavy calculations using complex! arithmetic) 
is 6-7 times faster in World than code doing the same without complex! 
in R2 and 11-12 times faster than R3. If using same code, it's 2.5 
times faster in World than R2 and 4.2 times faster than R3.
- A simple WHILE loop like:
n: 1000000 while [0 < n: n - 1] []

is 1.8 times faster in World than in R2 and 2.8 times faster than 
in R3.

- I tested networking in two ways. One sending one byte back and 
forth between client and server task 100'000 times using PICK to 
get it, and another sending 1k bytes back and forth 10'000 times 
using COPY/PART to get it from the port. Both were around 3 times 
faster in World than in R2. (I didn't test this in R3.)

- I tested calling "clock" and "tanh" routines in the libc library. 
I called those routines 1'000'000 times in a loop and subtracted 
the time of the same loop without calling. Calling "clock" is 2.4 
times faster in World than in R2. Calling "tanh" (with argument 1.0) 
is 5.9 times faster in World than in R2. (I didn't test this in R3.)


(Some functions are mezzanines in World, which are natives in REBOL, 
so they'll in most cases be slower in World.)

Q: We already know that your physics background influenced the new 
complex numbers datatype. Should we expect further progress of this 
kind (physics/science)?

A: After pointing this language out to a couple of friends from university, 
I was quickly asked to give scientific examples, like making a Lorentz 
attractor. There will come examples like that. Also I have some contacts 
at the Niels Bohr Institute (Copenhagen University), that I would 
like to show the language to and see, if we can create some projects.


Q: How long has this been in the making in general & how much time 
have you spent programming it?

A: I started R&D late March 2009. In March 2010, I had >7'000 lines 
of C. Then I took almost a year break from World and started up again 
Spring 2011. I have used much time on it this year (2011). So I've 
used 1-2 years effectively, I guess.


Q: Is there a way loading and interfacing pure object files, how 
about callbacks?

A: I don't have much experience in this area. Two of the closed alpha 
testers have looked at interfacing with sqlite3, which uses callbacks 
for some stuff. I would say, it doesn't work 100% yet, but it's being 
worked on. I need to see examples of loading and interfacing with 
pure object files to judge, how much of such functionality should 
be in World.


Q: Wouldn't it be useful to treat the kwatz! type same way as binary! 
so you don't need to always convert it? I mean, all functions that 
are able to take binary! arg should be able to use the kwatz! as 
well...or do you think are there any problems regarding that?

A: I've thought of that and came to the decision, that KWATZ! should 
be treated with some care. Are we always sure, we want to treat that 
data as binary? I need more experience using KWATZ! to judge that. 
Conversion could be fast, if the AS function was introduced, which 
should just change the type without copying.


Q: Is there a call-in interface available, meaning I can embed World 
in other programs?

A: Not yet. Internally I do call World functions from C (to parse 
URLs) by pushing arguments on the VM stack and call the execute_vm() 
C function. I imagine an interface much like in Lua (lua_call), but 
a little more work is needed, before we're there. This is an alpha 
release, so things will change/be added, before we move to beta release.


Q: Regarding your thesis I guess you have something like an integrated 
db or a special datatype for permanent storage too.. ?
A: Too early! :)

Q: What subset of REBOL2 will run without change in World?

A: Uh, ah, hard to tell at this point. When I need new functionality 
in World (because I want to run some of my R2 scripts), I consider, 
if it should be part of World/Cortex or if the new functions should 
go into the REBOL expansion/dialect (%rebol.w). I want World/Cortex 
to be small and compact. The idea with %rebol.w is, that much of 
R2 code could run, after this script has run.


Q: Are there datatype and function comparisons between World and 
REBOL2?

A: No, I haven't documented that ... yet. Maybe someone else wanna 
document that!? But there are differences, like the REBOL decimal!, 
which in World is called real!. And then %rebol.w just include the 
line:
decimal!: :real!
, so REBOL scripts using that will run.


Q: How many people were working on this World? :) Is it just a single 
man project?
A: Yes, just me.

Q: Will there be a GUI?

A: I would really need a GUI for my own work at some point. I have 
ideas, but nothing set in stone yet. And I want World to be open, 
so different GUIs should be possible, also the native GUIs in the 
different OS.


Q: Are you rich enough to buy Rebol Technologies and employ Carl? 
:-)
A: [KWATZ!]

Size is probably because of some Windows includes/libs. From my mac:

-rwxrwxr-x+  1 john  staff  360286  4 Dec 09:53 world_linux
-rwxr-xr-x   1 john  staff  346216  3 Dec 11:27 world_macosx
-rw-r--r--+  1 john  staff  515991  4 Dec 09:50 world_win32.exe


The OS X and Linux version is much smaller. I have to dig into that 
at some point. But I don't think, it's so important right now.

On OS X, World seems to be fussy about which directory it is launched 
from:

Rodney:Simple-Test peter$ cd ~/Languages/World
Rodney:World
 peter$ ./world

Loading Cortex... Done

World/Cortex 0  Copyright (c) 2009-2011 John Niclasen, NicomSoft

build: Dec  3 2011 11:27:45

w> .

Hello, World!
w> tes
t
== true
w
> quit

Rodney:World peter$ cd ~/Code/Rebol/Simple-Test

Rodney:Simple-Test peter$ ~/Languages/World/world

World/Cortex 0  Copyright (c) 2009-2011 John Niclasen, NicomSoft

build: Dec  3 2011 11:27:45

w> .

** Error: . has no value

** Near: .

w> test

** Error: test has no value

** Near: test

w> quit

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.

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?

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

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.

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

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.

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.

Defining routines is very flexible, a bit against my simplistic philosophy 
for World, but now it's done. Having e.g. libc (OS X example):

libc: load/library %/usr/lib/libc.dylib

Defining PUTS can be as simple as:

puts: make routine! [
	libc "puts" [
		[string!] pointer
	]
	sint
]

or as full of info and features as:

puts: make routine! [
	"Writes a string to stdout followed by a newline."
	[typecheck]
	libc "puts" [
		string [string!] pointer "String to write to stdout"
	]
	sint integer!
]