World: r3wp

And the error output for a function starts at the offending parameter, 
so that's actually pretty good, but it's not obvious

Here's a message that's not very clear:

*** Compilation Error: type mismatch 
*** expected: [pointer!] , found: [integer!]

*** in: %/users/administrator/Red/Red-ZeroMQ-binding/examples/../ZeroMQ-binding.reds 
*** at:  [0 as-message message data]

I can't compare pointers to zero any more. Presumably, these are 
the arguments to the zero? function, but that information is lost

As a nitpick, there's an excess space in the message, before the 
comma

It seems that NULL is defined as integer! 0

So it seems that there is no way anymore to pass a null pointer to 
a function or to compare a pointer to null

null-p: as [pointer! [integer!]] 0

does that work?

I tried AS POINTER!

The only syntax I can get to compile is as pointer! [integer!] 0

null-ptr: pointer [integer!]
null-ptr/value: 0

should probably work as well

but `as pointer! [integer!] 0` is fine, if it works. the spec needs 
a fix so that the examples match the syntax spec, though.

Wouldn't that set the pointed to integer?

indeed, sorry for the confusion

Are imports type checked yet?

I can't get past the null comparisons, but I've checked my other 
fixes in to Fossil

Are imports type checked yet?
 Yes (but untested yet).

Thanks for all your feedback, it is really helpful. I will review 
every issue you've raised today.

Thanks. The 0MQ binding is a nice test case

I was a bit confused yesterday about ALIAS usage, due to this ticket: 
https://github.com/dockimbel/Red/issues/39.I jumped on fixing it 
too fast without first checking the specification, so I mistakenly 
extended ALIAS beyond its original purpose (which is just for aliasing 
struct! declarations, as described in section 4.5.5 of the specification).

I just pushed a new commit that reverts back some of the changes 
I did for aliased types yesterday, and fixes the compiler errors 
reported by Kaj.

I have uploaded a patched version of the 0MQ binding here: http://static.red-lang.org/tmp/red-0mq-fixes.zip

Among the changes, 'null is now a global variable defined as a null 
pointer.

So, #define is the way to go to rename existing types and ALIAS is 
reserved for struct! only (it allows to circular references that 
couldn't be done using macros).

Kaj: "If Red/System truely is to be strongly typed, there needs to 
be more than just pointer! [integer!]. The issue I'm currently having 
is exactly that there is no matching declaration for what I need" 
Could you tell me what is your need precisely?

it allows to circular references
 => it allows circular references

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