World: r3wp

The REBOL community?

Boron is using all the right open source buzz words, except AltME, 
and look what traction it got

I'm not sure that you can associate Boron's lack of popularity with 
the fact that Karl does not use AltME.

Maybe, but I can associate my misgivings with communication systems 
that make you jump through hoops

Do you mean the Boron mailing list?

Mailing lists are among the worst, yes

Ah, the unintegratedness begins. When I type >> in GitHub to denote 
a REBOL result prompt, it interprets it as indent markup

If you had told me twenty years ago that I would be writing prose 
such as "Local logic! in prin-int leaks as global function!", I would 
have seen it as a sure sign of dementia

I implemented error checking in the 0MQ examples. It has revealed 
three bugs in Red

It has exploded the code, though. It's quite ugly and inefficient

Keep up the good work Kaj!

Thanks, I intend to

Karl has failed to engage with the Rebol community as far as I can 
see.

Kaj: thanks for the reports. I was aware of NOT issue and already 
encountered the local name clash, but never got the time to isolate 
it. Fixing them now, before going beta, is a good timing.

So we are going beta soon? :-)

Red/System will go beta as soon as I:
- fix the remaining bugs from the tracker,

- decide on 2 last syntax issues discussed on the ML (concerning 
struct/pointer literal syntax and aliases)
- make a pass on the specification to fix/update/complete it.

It could happen today, but I will be probably too busy with other 
non-Red tasks.

And then? RED language implementation, generating Red/System code? 
That will actually mean reimplementing all REBOL natives - how long 
do you expect it to take to get to an alpha? One year? More?

The next step will be working on Red memory manager, then Red compiler 
(including reimplementing all the base natives). Alpha should be 
available around September, 1st.

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

September 1st for the compiler, right? Not the whole REBOL reimplementation? 
You can't be so fast :-) And if you are fast, you should rename to 
SupaRED :-)

I said "base natives", so not a whole REBOL reimplementation.

I will detail the milestones on red-lang.org just after the beta 
announcement.

Peter, the %function-test.reds script is missing from your last commit.

It seems to be there : https://github.com/dockimbel/Red/blob/58afdfbf99699c7bcd3f57231edae9c495e00f99/red-system/tests/source/function-test.reds

Ah...let me check why precisely the test script is complaining...

It's in the wrong place. sorry. It's in source/ when it should be 
in source/units

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.