World: r3wp

In my first release, I wrongly read ESP data instead of [ESP] for 
Syllable.

Ah, the detail devil :-)

I once offered a little glowing "code protecting" angel statue to 
one of my developers. It was supposed to keep devil out of your code 
if you kept it close to your screen. Can't find it online anymore, 
maybe that would help...:-)

:-)

New Red/System document is available: BNF language grammar description 
(by Rudolf W. Meijer)
http://static.red-lang.org/A_BNF_grammar_of_Red_System.pdf

Very cool Doc (and Rudolf).

I've cleaned up my cURL binding enough to put it in a repository:

http://red.esperconsultancy.nl/Red-cURL

very nice work!

Thanks

cURL link added to Contributions section: http://www.red-lang.org/p/contributions.html

I'm temporarily bored with all the cURL bindings, so I've started 
working on an SDL binding

good choice:)

that's nice!

I thought you would like it, Oldes :-)

We'll see how far we can get with sound and graphics without floats

I can open and close a window now. Imagine VIEW [ ] :-)

I can have a window without any borders, so you could make your own 
window manager

Got variable-arguments functions (with optional runtime type info) 
working in Red/System. Will release it tonight or tomorrow. RTTI 
is allowed only for variable-arguments functions for now. I could 
be extended to fixed arity functions,but only if I need it for building 
Red.

Kaj: are you working on a SDL-based View clone?

Well, let's first get some pixels in those windows :-)

Hm. I'm developing on Syllable Server. On Syllable Desktop, I can 
load the SDL library and print its version, but it segfaults on opening 
a window

It's the same bug that crashes cURL. It doesn't even get to opening 
the window, it prevents the SDL library from properly initialising

When I add C library initialisation, SDL also initialises

So it works out of the box on Linux but not on Syllable OS?

Yes, exactly like cURL

Have you investigated what is causing that difference on Syllable?

Not deeper than the LSB spec you found that lists possible functionality 
that any implementation can put in there

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

Maybe you could find out what is causing that in Syllable and fix 
it?

There's nothing to fix. This is how it's implemented in Syllable's 
case

Most of the adaptation of Syllable to standard software is in the 
C library. This is where the handshake between kernel and userland 
is done in common systems

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.

OK, thanks. It will also be needed on other systems, though, in forms 
specific to their C library. I've already included the deviations 
for Linux

I haven't tested it yet, but I'm sure that without it, things such 
as get-env won't work

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

That's fair enough. I also like to postpone things until they're 
proven necessary :-)

BTW, this call could prevent Red from working on Syllable as that 
libC init is a blackbox. I especially fear a clash with Red and libC 
thread init routines.

It would be much worse if it weren't a black box. :-) You'd have 
to duplicate all the initialisations done in there for all systems 
and all C libraries and all versions of them

If Red threading will be incompatible with C libraries, it will be 
usable in pure Red programs, but not in any program that uses any 
library that uses the C library

Some incompatibilities with multi-threaded C libs might happen, but 
mono-threaded C libs should be safe.

cURL is mono-threaded, though

I don't know exactly what libC is doing in its thread init routine 
nor I have time now to investigate that. We'll see if any issue arises 
once Red gets multithreading support.

I'm fairly sure they would be fixable

BTW, Red will probably be distributed both as a standalone exe and 
as a dynamic library. So if people wants or needs to deeply rely 
on C libs, they could embed Red in a C project easily.

For Syllable Desktop I have to disable CDROM support, because we 
have only recently ported that to SDL. But now I get the windows, 
both with and without border

it should not be difficult to port View engine, no? SDL is surely 
very welcomed ....

The View engine is under unknown licence, so it's useless

Do you see them as competing? If the View engine were BSD, I would 
still put it on top of SDL