World: r4wp

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]

Forgot also to mention that PICK and POKE now accept logic! value 
as index.

Re. Hex, how about underscore? Fairly clear and not too dissimilar 
to 0x2FAB notation.

0_ffccbbee 2_11011011 16_2FAB

Red/System Question: In Struct A, there is a menber which points 
to struct B. In Struct B, there is a member which is a function pointer, 
whose parameter is a pointer to Struct A. ... How can I do this in 
Red/System. This is not a fiction case. I am studying SQLite surce 
code, struct sqlite3_file and struct sqlite3_io_methods are exactly 
like this.

This any help?

Red/System []

a!: alias struct! [
  a1  [integer!]

  a2  [integer!]            ;; this is used to hold address of struct 
  b
  a3  [integer!]
]    

f!: alias function! [s [a!]]
f: func [s [a!]] [print [s/a1 lf]]

b!: alias struct! [
  b1 [f!]
]
  
a: declare a! 
b: declare b!


a/a1: 5
a/a2: as integer! b 
a/a3: 0
b/b1: as f! :f

foo: as f! b/b1           
foo a

Thanks, Peter

Jerry: if I understand correctly, what you want to achieve is:

    Red/System [ ]

    structA!: alias struct! [
        p [structB!]
    ]

    structB!: alias struct! [
        fun [function! [a [structA!]]]
    ]


As is, it won't compile in Red/System as structB! is not yet defined 
when defining structA! (and the compile is making a single pass only, 
so can't look ahead). 


The workaround is to define `p` as integer! and use type casting 
when accessing it.


Also note that if you reverse the order of definitions and start 
by defining structB!, you could use the same workaround for `a` argument 
type (define it as integer!, then apply type casting when appropriate).

I have added a new function type today: routine!. It allows to write 
a Red/System function in a Red program. The compiler will marshal 
(or type-cast) the arguments back and forth automatically.

Here is the Fibonacci example rewritten as a routine:

Red [ ]

fibonacci: routine [
    n          [integer!]
    return: [integer!]
][
    either n < 2 [
        n
    ][
        (fibonacci n - 1) + (fibonacci n - 2)
    ]
]


The function body is Red/System code, so it will run at full Red/System 
speed.


Integer! and logic! values are converted automatically, other Red 
datatypes are passed boxed but type-casted as Red/System counterparts 
(as defined in the Red runtime). Hint: floats will be converted automatically 
too.

So, passing and processing a block! series would look like this:

Red [ ]

add-one: routine [
    blk       [block!]
    return: [block!]
    /local value tail int
][
    value: HEAD(blk)
    tail: TAIL(blk)
	
    while [value < tail][
        if TYPE(value) = TYPE_INTEGER [
                int: as red-integer! value
                int/value: int/value + 1
        ]
        value: value + 1
    ]
    RETURN(blk)
]


I haven't yet released the code, it needs a bit more work, it should 
be ready by tomorrow.


The purpose of routine! datatype is to provide access to ultra-fast 
and low-level code for Red program in a simple way. The design is 
not yet fully set in stone, so suggestions and comments are welcome.

That's cool, it's something like rebcode.

How about something like having a block of Red/System code inside 
Red code?

System [...some R/S code...]

Endo, what you want is described in Section 17 in the Red/System 
Spec   http://static.red-lang.org/red-system-specs.html#section-17

Very cool Doc!

awesome.

In C, struct astruct { char c; int values[3]; }; How do I write this 
in Red/System? Thanks. It's the integer array which confuses me.

Thanks Jerry, shame on me :)

There are no arrays in this bootstrap version of Red/System. So you 
have to manage this with a pointer:

Red/System []

s: declare struct! [
  c  [byte!]
  i1 [integer!]
  i2 [integer!]
  i3 [integer!]
]

; intialise the structure
s/c: #"a"
s/i1: 1
s/i2: 2
s/i3: 3

;create a pointer and point it at the first integer
i: as integer! s

i: i + 4                          ;; set i to address of first integer
ip: as pointer! [integer!] i

;; add the integers
sum: 0
count: 3
until [
  sum: sum + ip/value
  ip: ip + 1
  count: count - 1
  count = 0
]

print ["The sum of the integers is " sum lf]

There is a probable issue with value alignment as explained in http://static.red-lang.org/red-system-specs.html#section-4.7

I'm not sure how to handle "packed" stucts in Red/System.

Also, the docs state that the value alignment may vary by processor 
so the line
	i:  i  + 4


may not be valid on all platforms (though I think it is safe with 
IA-32 and ARM).

That's cool, it's something like rebcode.

It has a broader range of usage and it's faster than rebcode.


How about something like having a block of Red/System code inside 
Red code?

System [...some R/S code...]


This is already implemented since a while in form of a Red compiler 
directive: #system [...]

Thanks. Peter. It's very helpful.

To have a tightly packed semi-array of dynamcic length, use allocate 
and free

Doc, thanks very much for routine!. It's brilliant and exactly what 
I need to make the bindings available from Red. However, #define 
not being context aware is still a blocker

There's not much that can be done currently for #define, you can 
use #enum instead to workaround it in such cases. 


Anyway, we will need to rethink the preprocessor in Red/System v2, 
and if possible, remove it. It has been added at the beginning of 
Red/System because Red was not yet there to provide a higher-level 
macro system. Now that Red is alive, we could start thinking of a 
better alternative to the current Red/System preprocessor.

That would be good; I still have mixed feelings about it

It would have to be something that can be processed by Red but still 
able to generate stand-alone Red/System

I would like to get rid of it, for many reasons. Firstly because 
it was not meant to be part of Red/System, but added later for practical 
needs, secondly because Red/System code could be built/composed more 
efficiently from Red.

In other words, we need some kind of Red wrapper (or maybe dialect) 
on top of Red/System to make it easier to construct programmatically.

Sounds right

I haven't had time yet to think about such replacement solution, 
so ideas are welcome.

Routine preliminary support pushed. See commit log for examples. 
The routine! type still needs to be added.

Routine! datatype added, reflection is supported.

Doc, I'm very glad to see you're still working hard on Red!  I was 
concerned that the psychological effect of everyone paying attention 
to R3 source, plus your own curiousity about it, might derail you 
for a while.  I'm still eagerly awaiting every advance you make!

Actually, I still haven't found time to read the whole R3 sources 
base. I was too busy this week designing some new parts of Red.

doc, congrats you were accepted to the dev program of Leap motion 
:-)

... and yes, please do continue with Red development, I believe that 
in the end it is good to have rebol like alternative :-)

Pekr: thanks, I hope to get the device + SDK in January. My application 
to their developer program was based on an innovative IDE for Red 
powered by Leap Motion device. ;-)

sounds cool :-) Lately I was wondering about the possible benefits 
of Red and R3. Difficult to judge, but could there be any overlapping 
ground, where twose two projects could cooperate? e.g your IDE for 
R3 to, simply a language would be a plugin, or - both projects want 
to address Android - could one bridge to JNI be used for both?

Pekr: I don't know. We'll see how things evolve in the next month. 
In order to cooperate with R3, it would be first necessary to determine 
who's really in charge of R3 or what R3 fork should Red cooperate 
with... :-)