World: r3wp

The pointer! [...] syntax does make sense as a shortcut for struct! 
[value [...]] in function specs - that type equivalence was the important 
part of the earlier argument, not syntax issues. The only place that 
the syntax looks weird is in AS calls, where otherwise expression 
rules would apply. I'll look over the specs later this evening and 
see if there's anything really weird-looking.

You mean that you would prefer writing it without outer brackets 
for type casting (like: as pointer! [integer!] ...)?

(as proposed by meijeru on the ML)

No, I mean that pointer! [integer!] would be exactly the same type 
as struct! [value [integer!]] - type equivalence between pointer! 
and struct!. This would make the pointer! type a syntactic sugar 
shortcut for a subset of the struct! type. That is the semantic portion 
of what you wanted me to write down for you in a google groups post 
so you could refer to it when you were implementing that suggestion. 
There were also syntactic issues, but those don't matter as much.

This was long before meijeru got on the Red google group.

Right, I think I should add it as a note in the specification draft.

I've been busy lately so I haven't read the latest couple spec drafts. 
Must catch up and comment, quick before you finalize things.

I will push new specification changes and fixes tonight. I have added 
a type casting matrix for all possible type combinations. I am currently 
  implementing the missing cases.

Do you make a distinction between implicit and explicit type casting? 
Does Red/System have any implicit type casting at all yet?

Yes, it does an implicit type casting for math and bitwise operations 
on the second argument.

I have pushed the changes for the type casting matrix support (both 
in docs & implementation). I need to add proper tests to cover that 
tomorrow.

4.6.6 of the spec now says that the official type for a void pointer 
is integer! but this leads to type mismatches with null

Null is currently of type pointer! [integer!], I need to get it back 
inside the compiler to make it polymorphic. Just use 0 for integer! 
or handle! (if you've defined it) in the meantime.

I would like to introduce my second Red binding, for the standard 
C library:

http://red.esperconsultancy.nl/Red-C-library

So far I have bound 25 functions and written two higher level wrappers

I've used it to implement printing of integers in the examples for 
the 0MQ binding

Doc, feel free to use any of it that you need in Red

You can print integers in Red/System

Just include this - https://github.com/dockimbel/Red/blob/master/red-system/tests/quick-test/prin-int.reds

May not be clever but it prints integers.

I know, but this is a solid solution, and there are 26 more functions 
:-)

I've bound all memory management functions, most of the string processing 
functions and a few system interfacing functions

Looks good and will also act as a good example.

Thanks

Kaj, thanks for the contribution. I have planned to wrap some of 
the memory manipulation functions too as soon as I finish the work 
on aliasing and type casting.

Hats off to Kaj!
 - from Miejeru on the Red Google Group

Thanks :-)

Red can load library functions with different calling conventions, 
but which convention does the emitter generate for its own functions? 
Cdecl?

Internal functions: stdcall

Wouldn't it be better for compatibility to use cdecl?

I am not sure about the argument order, though...it might be opposite 
of stdcall

I doubt it, because so far I have been able to interchange them. 
The differences must be very small

For porting the cURL binding, I will need callbacks. I'm sure cURL 
on most systems expects them to be cdecl

cdecl for internal functions is only required for callbacks from 
external app, so I planned to add it for internal functions that 
are exported.

OK, when is that plannned?

In a not-too-distant future :-) I don't have precise ETA for that 
as it is not required for Red building. I will add that feature when 
working on the DLL building mode, so probably one of the next weekends 
(maybe on June, 4-5 if there's no other urgent tasks).

Great, thanks

I wanted also to add PIC code generation, so I am not sure which 
one I'll do first. What do you think?

By DLL building mode, do you mean having Red generate shared libraries?

Precisely.

Brilliant

PIC support will be required for that.

I thought about implementing PIC support first and testing it using 
Syllable's executables.

For DLL, you need PIC. I can use callbacks before that, so I'd say 
the order is cdecl, PIC, DLL

That would be nice, too, but it's quite possible that executables 
can already run on Syllable if they can be generated at the right 
start address

Ok, I have no personal priorities for these tasks, so I'll take yours.

Ah, right, that was the last show-stopper.

BTW, I tried installing Syllable on VMWare 7 and it failed to recognize 
the disk controller (I tried every possible disk modes and Syllable 
boot mode). I might have not picked the right image to install...I'm 
retrying right now with this one: http://downloads.syllable.org/Linux/i686/systems/Server/0.1/SyllableServer-0.1.i686.VM.7z

Oh, that's old. We only got a VMware image contributed for Server 
0.1, so it's much better to run the installation for Server 0.4