World: r3wp

I'll wait for your new commit then.

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

Porting to OSX should be done asap, after the beta announcement.

That will be fantastic!!!

Yes, I know a few potential Red/System testers that are waiting for 
that too.

Thanks for the fix, pulling it and testing right now.

No problem. Hope it's okay now.

Yes, I am just adding another assertion in the f1-f function body 
to verify that the word lookup is done on local context first.

Yes, I should take the Red->Red/System compilation road.

Did you change your opinion on this? Wasn't the plan originally to 
compile Red directly?

Right, I wanted to make a direct native compilation for Red too, 
but emitting Red/System might be shorter way to reach the goal.

As Red/System is a dialect of Red, the compilation should be quite 
easy to achieve.

Updated the C and 0MQ bindings for the unset EITHER return value 
fix

However, their functioning is still hampered by the not as-logic 
function! bug, which affects half my functions

I won't be able to get back to Red before tomorrow.

No problem, it's just a note about the state, and it's ready for 
the solution

Thanks for the fix! The bindings are fully functional now

Cool!

I've overhauled the design of the 0MQ binding. The high level interface 
is now better tuned. Memory management is moved out of it, so it's 
more efficient. No more thrashing of the allocator for message containers

Message holders don't leak memory anymore, but now the payload of 
sent messages leaks, due to what seems to be a bug in callbacks. 
More in the tracker

The callback is called just fine, but seems to corrupt something 
while running.

Thanks for the report, in any case.

Kaj: good to know that you working on improving the 0MQ binding. 
I will have a look on the callback issue.

Thanks for the first fix, but it doesn't work yet

Right, Andreas fix shouldn't change anything, see my comment: https://github.com/dockimbel/Red/commit/89f2533a5712a389ae15220be3ca75e75f4728c2

I will run his test case step by step to see what's wrong.

Works fine on Windows, so it looks like a Linux-specific issue...

When we can expect support for decimal numbers?

You mean floating point?

yes

I'm pretty certain that Nenad has said that he won't be adding binary 
floating point numbers to Red/System as they will not be needed to 
build the Red runtime. So at the moment, I would only expect them 
once Red is available.

Not anymore, because he has now decided to compile Red to Red/System, 
so Red/System will need full support

I think that's a good thing, but it may still be wise to postpone 
the implementation. Having Red will enable more people to contribute, 
but on the other hand, the lack of floating point is blocking a few 
contributors now

Floating point support should be added to Red/System if my tests 
shows that I can safely do the Red->Red/System compilation, else 
it will be supported at Red level. Anyway, it is not a priority for 
me, so it probably won't be added before Q4 2010 (unless someone 
wants to contribute by adding it to Red/System).

Q4 2010 is in the past... :) but thanks for the info. I can wait.

Sorry, Q4 2011.

Those years are passing too fast. :-)

but at least Red seems to be keeping up

Andreas' fixes to callbacks on Linux work now. I've enabled them 
in the 0MQ binding and with that, the binding is now pretty much 
production ready

Andreas did a great debugging work on that.

Yep

Thanks. Good to hear that it's now working for you as well, Kaj.

Very cool. Thanks to all of you for coordinating on this.

Is it possible to compile R3 extensions right out-of-the-box? That 
would be pretty cool.

Robert: yes, as soon as we add DLL generation support in Red/System.

it will not be much useful without floats ;-)

Nice try :-)

You'll still have to implement the R3 extensions interface

The 64-bit integer support might also be required in Red/System for 
that.

Indeed, it doesn't seem to be possible to get away without that