World: r4wp

More than ever. ;-)

Hopefully we will see some synergies with the two projects.

I just had a very short look on R3 code yesterday's night, what striked 
me the most at first look is how both R3 and Red are struggling (in 
different ways) to avoid writing C code as much as possible. :-)

in what way is R3 struggling to write C code? Isn't it written purely 
in C?

It seems that is uses some REBOL templates to generate some additional 
C code during the building process, like this one:

https://github.com/rebol/r3/blob/master/src/boot/types.r

r3 / src / tools section is great :) I especially like make-make.r

R3's source also avoids direct C code by doing a lot of the work 
in macros. With the macros, the C source of a native doesn't look 
that much different than mezzanine code.

I noticed some similarities too in actions

Doc, as R3 got released on 12.12.2012, you should prepare some release 
or nice Red surprise for 21.12.2012, to be on pair :-)

Pekr, something like "The end of World and Red"?(no offense,  just 
a  joke Doc and John) :-)

Actually old stuff will die off - Mayans thought about the date as 
of the new fresh era, new oportunities, so quite the opposite :-)

World has already ended with its closed-source nature :)

Cyphre: don't count on that (at least for Red)! ;-)

I don't agree. (of course) World is on hold because of lack of finances 
to bring the development forward.

The World has ended the Maya's before the Maya's could end the World.

Donated 50 EUR so that Nick has at least something to match :-)

Thanks! :-)

Other donations have been made as well, but it's great to remind 
people that we need to support Doc so he can focus and keep making 
great progress. Thanks Petr.

Ah, glad to hear that :-)

I yesterday donated just 15EUR (just for a pizza, and didn't intend 
to mention it here), but if Nick will match it will be 2 pizzas :P

:-)

If I cut each pizza in four parts, that's almost 8 lunches! :-)

Actually, good decent pizza in restaurant is about 3-5€ here, so, 
15€ is at least 3 pizzas!

Janko, every bit counts. I've donated this month, but I will match 
December donations in a January donation, up to USD$200. So, donations 
in December get double matching up to USD$200, if Nick matches as 
well.

Red 0.3.1 released: http://www.red-lang.org/2012/12/red-v031-functions-support-added.html

- function support
- path get/set notation support
- refinement support for native functions
- expressions in parentheses compilation

- new datatypes: function!, paren!, path!, lit-path!, get-path!, 
set-path!

- new actions and natives: find, select, copy, reflect, type?, halt,...

- extended mold, form and comparison operators to all new and existing 
datatypes
- many new mezzanines functions

- modulo and remainder operators on floats implemented for ARM backend
- Quick-Test testing framework ported to Red
- a truckload of new unit tests
- many bugfixes
- about 200 new commits to the Github repository
- updated Red/System formal description document

Gregg: thank you very much!

Wow! That's great Doc.

We'll try to keep you supplied with plenty of pizza. :-)

Is http://www.red-lang.org/p/roadmap.htmlcurrent? You've been making 
so much progress, I'm guessing it's a little out of date.

Why default red's functions refinements value is false?

To avoid having to use to-logic when using refinements to pick a 
value in a series. For example:

In REBOL:
    foo: func [/only][pick [1 2] only]
    foo

    ** Script Error: pick expected index argument of type: number logic 
    pair
    ** Near: pick [1 2] ref

In Red: it should return 2.

Note that PICK taking a logic! value is not yet implemented, it will 
be added in the next days.

This is a code pattern I use often, but always find it annoying to 
have to add a to-logic call each time in front of refinements.

Gregg: It will need to be updated a bit, right

Thanks for supporting Red, Gregg! The others, too

Great Doc !

Funny, I usually just reverse the order of the PICK elements and 
use NOT.

Are only the refinements FALSE, or also extra arguments?

Unused refinements only. Extra arguments are set to none.

OK, that sounds useful

It is also more consistent, as used refinements are set to TRUE.

Just specifiying a return type adds 68 bytes to a function. Why is 
that?

(In Red)

It shouldn't have any effect on the generated code size. Can you 
send me the function?

It's the Fibonacci function in the C library binding. I checked in 
a Red version. If you add return: to that it becomes 68 bytes bigger

Does the function becomes bigger or the whole binary?

The binary. The function would be hard to estimate

Then, that's normal, the added size is for dynamically creating the 
extra literals you've added to the spec block. Remember that the 
source code of your function is built-in the final binary, so you 
can use reflection and soon, rebuid the function dynamically at runtime.

Also, you won't find the source code of block literals in text format 
if you scan the binary, because they are stored as code and not data. 
That is the only way currently they can be stored in compiled binaries. 
Storing them as text would need a way to load them and then compile 
them at runtime (it will be possible in the future, but not right 
now).


Anyway, the probably best way to store all those series literals 
is to allow the use of a redbin format. We will have that too at 
some point.

Ah, thanks

New features of the day: 
- SWITCH implemented (/default refinement supported)
- CASE implemented (/all refinement supported)

- FIND and SELECT extended to handle datatype values matching. Example:

    find ["hello" 2 red] integer!
    == [2 red]