World: r3wp

I need a pointer to a struct of which only 0MQ knows the structure. 
So any pointer will do, unless you want to make Red/System strongly 
typed

dockIbel one cool thing thqt could help promoting RED would be to 
do a openSUZE minimal distro using their tool that gives a linux 
ready to use out of the box with all needed to code or enhance red

I know it zas made for Illumination software creator and was a good 
enightenment for it

plus ISC opensuze distro was custom distro of the year which spread 
even more the word

could be a good way in a middle term to have tools + OS etc in a 
single CD

No need, it already exists

You're right, I should add a mention about it on red-lang.org.

Kaj: I pushed a few fixes and changes on ALIAS support, it now behaves 
strictly as described in the specification. For the 0MQ binding, 
you need to replace [struct! message!] occurences with [message!] 
to make it compilable with the new version.

Including your previous changes, I figure?

Yes.

Processed your changes, and indeed it builds again

Have a new batch of issues, but will research more first

In the spec in 4.5.5, shouldn't the child structs gift/first and 
gift/second be created individually (and assigned to the struct pointers 
in gift) before their members can be assigned?

At the end of the last example in 4.6.2, shouldn't

a/count: p/count

be

a/count: p/value

?

It would also be good to make it clear that the integer! pointed 
to by p needs to be separately allocated (presumably by foobar and 
GetPointer)

4.5.5: yes, you're right, the example is missing gift/first and gift/second 
proper initialization.

4.6.2: right too, it is a typo.

At the end of 4.6.5,

;-- writes 123 (4 bytes) at 40000008h

should be

;-- writes 123 (4 bytes) at 40000004h

(I hope)

Yes, it's 40000004h as the index is one-based.

By the way, what minimum CPU is your emitter targeting?

You mean the current IA32 implementation or more generally?

Red/System requires at least a 32-bit CPU.

The current IA32 implementation should work on a 386 I guess (but 
would need to check for some of the addressing mode used, they might 
not be all available on the 386). A safe minimum CPU should be the 
Pentium.

OK. So maybe it would conflict with the minimum 486 target of Syllable 
Server. Syllable Desktop targets 586

Not that I'm testing Server on 486, and the utility is dubious. But 
Red will be suitable for embedded systems, so there may be a good 
niche in 486 systems-on-a-chip

Wouldn't it be good to be able to write pointer! [ ] instead of pointer! 
[integer!] for a void pointer? I cringe a bit every time I see it. 
(Spoiled by REBOL, I guess)

A pointer! [integer!} is not a void pointer, it's a pointer to an 
integer.

I cringe whenever I see a multi-part statementthat is supposed to 
be taken as one thing that isn't a function call or in a block; all 
of the pointer! [something] statements qualify. Why is the 'pointer! 
word there at all? In the places where types are allowed, wouldn't 
the block be enough? Or is pointer! not a type, but instead a one-parameter 
function that returns a type, that for some reason has a ! on the 
end of its name?

You mean having:
    foo: func [[integer!]][...]
instead of:
    foo: func [pointer! [integer!]][...] 
?

sorry, bad syntax

Yeah, that second one looks like it takes two parameters.

I mean if the first takes one.

So: 
   foo: func [a [[integer!]]][...]
instead of:
    foo: func [a [pointer! [integer!]]][...]
?

Yes, the second one looks like it takes void pointer or a pointer 
to an integer, the pointer! word referring to a void pointer.

Realizing that this is supposed to be one thing trips me up all the 
time.

Weirdly enough, if the ! was gone from that keyword for the typed 
pointers it wouldn't trip me up because it would look like the subsequent 
block is part of an expression. Then the pointer! word would refer 
to an untyped pointer (void pointer) on its own with no block needed, 
though I would prefer handle! instead for R3 compatibility, and to 
make it more visually distinct from pointer (without the !).

We already have similar construction for the struct! type...I really 
don't see why this one should be wrong...Pointer! is not a void pointer, 
simply because a pointer! needs to point on something. A C void pointer 
is just a memory address, so an integer! would work fine to represent 
it on all 32/64-bit platforms I can think of.

Brian: your mental representation of a function specification block 
is wrong, it is not made of REBOL expressions, but it is a separate 
dialect with its own rules. Pointer! is closer to those rules than 
pointer (with no ending !).

Darn, I didn't get around to summarizing that argument here about 
struct vs. pointer in the google group, so it looks like its conclusions 
were completely ignored.

Also, if this syntax makes you choke, you can just use: #define handle! 
integer!

So much for pointers just being a simplified syntax for a subset 
of the struct types.

You asked me to summarize the argument in a google group post, but 
I didn't. Sorry.