World: r3wp

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

Isn't it enough to just make it behave like View?

I hope so

There will always be subtle differences, though, so like Red, it 
won't be fully compatible

View is events, basic graphics structure, DRAW and window handling, 
as I see it.

All that except DRAW is done by SDL. For extra functionality, there 
are many libraries

This is what I want to make:

http://www.youtube.com/watch?v=8nA4WaJTc7Y&NR=1

GEOS on C64 is much better :)
http://www.youtube.com/watch?v=j1Mnvead8Tc

Support for functions with variable number of arguments just released.

New attribute 'variadic documentation: http://static.red-lang.org/red-system-specs.html#section-6.3.3

New attribute 'typeinfo documentation: http://static.red-lang.org/red-system-specs.html#section-6.3.4

'typeinfo is a variant of 'variadic that provides also argument type 
at runtime.

Shouldn't that be type-info?

Endo, it's in development

I want attributes to be single words, so as callback is also wrote 
without an hyphen, I decided to do the same for typeinfo.

I might change 'typeinfo to 'type or 'info only, but these words 
alone are too common, so, not enough accurate.

If someone has a better proposition for 'typeinfo, I am ready to 
replace it.

Callback is written like that in English (otherwise it would be a 
verb instead of a noun), but type info is written as two words

TYPED would also do

TYPED sounds good, based on a glance at the docs.

I can now draw a pixel on an SDL screen in a format of 32 bits per 
pixel

Humble beginnings, but I've had a series of issues already

Getting the basics working is sometimes the hardest part.

I had TYPED in my short-list, so I guess it would be a better choice 
for a single word.

Now that variable arguments and RTTI are available, I have re-designed 
the basic screen printing functions. I have inserted a _ character 
in front of all PRIN-* functions, as they should not be used anymore 
in the general case (I might drop them completly later if they are 
not useful anymore). 


Before releasing it, I would like to get some feedback first. Now 
only the polymorphic PRINT and PRINT-WS (inserting spaces) functions 
should be needed. LF, CR, TAB, SPACE have been declared, so can be 
freely used in print blocks (or anywhere else). Variadic and typed 
functions have now a relaxed syntax, allowing to pass a single argument 
without enclosing [ ] brackets.

PRINT: print one or several arguments one after each other.

PRINT-WS: print one or several arguments, inserting a space character 
between each arguments.

Here how it looks now:

* printing without newline

    print "hello"
    print 123
    print ["hello" 123 tab "world"]

* printing with newline

    print ["hello" lf]
    print [123 lf]
    print ["hello" 123 tab "world" lf]

* printing with space inserted

    print-ws ["hello" 123 "world"]
    print-ws ["hello" 123 tab "world" lf]