r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Red] Red language group

Kaj
19-May-2011
[1453x2]
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
Andreas
19-May-2011
[1455x2]
null-p: as [pointer! [integer!]] 0
does that work?
Kaj
19-May-2011
[1457x2]
I tried AS POINTER!
The only syntax I can get to compile is as pointer! [integer!] 0
Andreas
19-May-2011
[1459x2]
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.
Kaj
19-May-2011
[1461]
Wouldn't that set the pointed to integer?
Andreas
19-May-2011
[1462]
indeed, sorry for the confusion
Kaj
19-May-2011
[1463x2]
Are imports type checked yet?
I can't get past the null comparisons, but I've checked my other 
fixes in to Fossil
Dockimbel
20-May-2011
[1465x2]
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.
Kaj
20-May-2011
[1467]
Thanks. The 0MQ binding is a nice test case
Dockimbel
20-May-2011
[1468x7]
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
Kaj
20-May-2011
[1475]
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
shadwolf
20-May-2011
[1476x4]
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
Kaj
21-May-2011
[1480]
No need, it already exists
Dockimbel
21-May-2011
[1481x2]
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.
Kaj
21-May-2011
[1483]
Including your previous changes, I figure?
Dockimbel
21-May-2011
[1484]
Yes.
Kaj
21-May-2011
[1485x2]
Processed your changes, and indeed it builds again
Have a new batch of issues, but will research more first
Kaj
22-May-2011
[1487x7]
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)
Dockimbel
23-May-2011
[1494x2]
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.
Kaj
23-May-2011
[1496x5]
At the end of 4.6.5,
;-- writes 123 (4 bytes) at 40000008h
should be
;-- writes 123 (4 bytes) at 40000004h
(I hope)
Dockimbel
23-May-2011
[1501]
Yes, it's 40000004h as the index is one-based.
Kaj
23-May-2011
[1502]
By the way, what minimum CPU is your emitter targeting?