World: r3wp

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]

Very nice. This takes Red/System a step beyond C

The only thing I'm not wild about is the print-ws name. Do you think 
something like print-wide would be too long?

Well I consider PRINT-WS already too long, but -WIDE is nicer, so 
it might be a good alternative.

I use a lot of PRIN-* functions every day for debugging purpose, 
so this new, much more powerful PRINT alternative, will save me a 
few hundred keystrokes each day (just not having to type PRIN NEWLINE 
anymore makes me happy). :-)

:-) It also reads a lot more elegant

Indeed.

In PureBasic, there are Print and PrintN functions. PrintN adds new-line 
to the end.
For Print-ws, what about Print-Form ?

we can use PrintN for single argument: PrintN "Hello" --> Print ["Hello" 
lf]

I considered PRINT-FORM but I've found it not meaningful enough. 
PRINT-WIDE is a better hint at what the function does.

I will publish these changes tomorrow morning and will bump the version 
number, as they would break most of existing scripts. I will write 
a blog entry to describe the changes.

Did you do any performance improvements? I just updated after a bit 
over a month and my SDL test, drawing a gradient, is a lot faster 
:-)

I wonder why we use lf, instead of a newline. Then we add a description 
to the doc, something like lf adds a newline :-)

LF is shorter, and newline was already defined

Did you do any performance improvements?

 I did a few small code optimizations, but they should not have noticeable 
 effects. Maybe your code relies on a tight loop that benefited from 
 them?

btw - what's the resolution re floating support in Red/System? Kaj 
is now trying to port SDL, so I wonder if for the gfx (which was 
not planned to be the RED's target),it will be the necessity,or not?

Floating point support will come to Red/System when the float! Red 
datatype will be implemented.

And float is planned, right?

Of course, there is just a lot of other feature that are much higher 
in priority.

features

Basic SDL does not require floats yet, so I have some room left to 
grow :-)

What's becoming a problem first is the lack of 16 bits integers. 
They're in structs and arrays, so I have to do trickery now to access 
them