World: r4wp

Release v0.2.5 is out: http://www.red-lang.org/2012/03/redsystem-v025-released.html

I've tested almost all binding examples on Syllable and Linux

I've changed the developing branch of the C library binding to be 
the main branch again (technically, it isn't a merge):

http://red.esperconsultancy.nl/Red-C-library/timeline

Could it be that when a function is applied to multiple argument 
expressions, f exp1 exp2, they are computed in reverse order?

Is that acceptable? It's quite anti-intuitive, especially once inline 
assignments will be supported

Anti-intuitive ? It makes the generated code simpler to write since 
the parameters are pushed in reversal order so that the called function 
can unstack them in order.
C compilers do the same IIRC.
But I agree it's not rebol compliant.

I'm not sure if C forces any order for parameters evaluation.

But i'm sure it makes the compiler's task easier to evaluate in reversal.

I know you already know Kaj, but it sounded like you asked for logic 
:-)

Could it be that when a function is applied to multiple argument 
expressions, f exp1 exp2, they are computed in reverse order?


I agree that it is not intuitive, but doing otherwise would make 
it more complicated to support external libs. It could be possible 
to preallocate the stack and fill it in reverse order, so that arguments 
are executed in right order for the user, but that wouldn't work 
for variadic functions (can't preallocate the stack before compiling 
all the arguments).


It would be nice to add a ticket in the tracker to keep this issue 
in mind.

As we do the compilation and code generation in one pass in current 
Red/System, we can't look ahead to determine the boundaries of each 
expression in a variadic block of arguments in advance, to be able 
to extract their datatype.

OK. It got me in trouble, though, because I used this statement in 
the Fibonacci computation:

print [
	"Fibonacci " parameter ": " fibonacci parameter  newline
	"Elapsed time: " subtract-time  now-time none  start  newline
	"Process time: "
		(to-float form-integer process-time) /
		to-float form-integer clocks-per-second  newline
]

In the C version I already noticed that I had to put the computation 
in front of the reporting, but I hadn't expected this, and certainly 
not in a language that looks like REBOL

Actually, the single pass nature of Red/System strengthened my assumption 
that the computation would be in natural order

We have a "chunked" compilation mode that could be used to re-order 
the code once generated, but I'm not sure it could work in such case. 
The best thing to do for now is to document it in the tracker.

Done

Thanks.

Doc - congrats to 0.2.5 release - nice to hear, that first alpha 
of Red can be here in few weeks, although it will not do much yet 
...

First alpha of Red in a few weeks?  Sounds great!

that's what Doc replied on his blog:


@Thomas: for the very first Red alpha, only memory management, basic 
datatypes and a few natives/actions. Ports and I/O will probably 
be added in following alpha versions, as PARSE. If we don't hit any 
walls, we should have it a few weeks, probably a month.

The first Red will probably have all the capabilities of Red/System, 
so I think it will be able to do quite a lot

Exciting news

http://development.syllable.org/news/2012-03-14-20-30-RedSystem-bindings-with-C-cURL-SDL-SQLite.html

Nice. Wil you push to OSNews? :-)

Already done

Maybe apart to C lib, you might mention in one sentence, that other 
big change for Red/S was addition of float support ...

It's in there

Implementing basic features for block! datatype support.
. RED - finally :-) How Btiffin says - go Doc, go! :-)

Does anyone know how to change a float into an integer or round a 
float to its nearest integer counterpart?

dunno, maybe via type casting? as integer! ... but not sure if it 
works for floats, or only pointers ...

http://static.red-lang.org/red-system-specs.html#section-4.9

The current partilal support for float does not support casting between 
float and integer datatypes

It seems float to integer is not allowed. Maybe some library call 
wrappers will be needed for that?

Support for converting between integer! and float!/float32! has not 
been implemented yet. The only way to achieve it right now is to 
rely on an external lib (libc?) or implement your own conversion 
routine in Red/System.

Yes, the C library binding can do that

FYI, I am making good progress on the Red runtime, but I had to start 
implementing the Red compiler earlier than planned, to be able to 
define more accurately the right runtime API that the compiler needs. 
So at the time that the runtime will be ready, I should have a first 
Red compiler partial implementation working.

Sounds logical to me

round-ceiling and round-floor in math.reds do rounding to integer, 
but they still return a float value

To convert to an integer value, you have to go through strings. You 
can use the format function in C-library.reds for that, but I see 
I haven't defined a shorter float wrapper yet

Doc - we are watching your progress via the Twitter messages, and 
looking into Github :-)

I've added some floating point convenience wrappers matching the 
other data types

This should work for conversion:

to-integer form-float

Note that the string returned by form-float should be freed

The other way around is already used in my Fibonacci and Mandelbrot 
time processing:

to-float form-integer

On Linux, you could also avoid going through strings and use lrint(3)/lrintf(3).

Is that GLibC specific?

ISO C 99

OK, that could be considered as a binding enhancement, then