World: r3wp

real-time debugging
 should be fine.

(unless that means something different than i suspect it does.)

1. compile a binary using red as usual
2. instead of running the binary directly, run it via gdb:

    $ gdb builds/hello
    (gdb) run

3. when the program segfaults, you should be back in gdb
4. print a backtrace using "backtrace":

    (gdb) backtrace

The problem with the current GDb on Syllable is that it doesn't know 
how to load shared libraries, so it can't load cURL

backtrace says it has no stack

The issue with shared libraries seems to be limited to the fact that 
cURL can use libdl. I don't know what was different now, but I got 
a GDb trace. Will put it on the tracker

The crashes seem to happen when cURL calls the C library, so outside 
the Red program. I'm not sure it's useful to disassemble a minimal 
Red example

I have 37,000 followers in Sina Weibo (aka Chinese Twitter), Most 
of my follower's are programmers. I've just mentioned Red in Sina 
Weibo. I hope that will make Red be noticed in China. I would like 
to thank Dockimbel for Red.

Jerry: thank you! 37k followers, that's huge!

silly question: is it possible now to build a CSV parser in Red?

There is no Red yet, only Red/System which is a low-level dialect. 
So, yes it is possible, but there's no special feature that would 
help you much for that task.

ok, I was just looking into the idea if it was possible to build 
one with better performance than what I currently can.

It will probably be much faster than the one you could write in REBOL, 
but you'll have to do all the memory management manually.

ok, thanks

The parsing functions in the C library binding can get you halfway

Got the cURL binding to work on Syllable, starting from Andreas' 
example. :-) Will research some more and report on the tracker

Good news!

just found this... it could be a good reference for low-level bit 
handling in Red.
  

though the code is in C, its probably easier to understand this way 
and convert to Assembly after (when no comparable machine instruction 
exists).
http://graphics.stanford.edu/~seander/bithacks.html

it has soooo many variations and its been thouroughly tested and 
analysed by thousands of people.

good sauce

Bookmark: "Calling conventions for different C++ compilers and operating 
systems" 

http://www.scribd.com/doc/51814542/36/Relocation-of-executable-code

Right link should be rather: http://www.scribd.com/doc/51814542/calling-convention

And straight from the source (I think we already had this here in 
the past):
http://www.agner.org/optimize/calling_conventions.pdf

You're right, and it looks like I missed it last time. Thanks for 
giving the right source link.

Got a very simple Red/System program running on OS X: 
    Red/System [ ] quit 42
;-)

It took me a few hours to write the file emitter but a full day of 
debugging to make it work. It seems that the issue was related to 
stricter stack alignment requirement on OS X (16 bytes alignment) 
and a different ABI for syscalls. 


It currently works thanks to a few hacks, but I need to extend the 
IA-32 emitter to implement these new requirements in order to make 
it output correct code for OS X.

Rebolek: I think that your first implementation should work once 
I upgrade the compiler.

For those curious about Mac OS X low-level ABI for function calls: 
http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/LowLevelABI/130-IA-32_Function_Calling_Conventions/IA32.html

Doc, great news for those of us who primarily develop on OS X these 
days.

Not only those. I appreciate the ability to target OS X without having 
to run it or know anything about it :-)

16 Bytes stack alignment is also preferred/required for MMX/SSE

It seems GCC always uses it

http://www.cs.uaf.edu/2010/fall/cs301/lecture/10_27_sse.html

It also seems it's only required for system calls on OS X

http://stackoverflow.com/questions/612443/why-does-the-mac-abi-require-16-byte-stack-alignment-for-x86-32

happy to know that Mac version is in progress.

Actually, the link I gave to Apple's docs does not cover syscalls...I 
couldn't find any official Apple doc about that. MacOS X seems to 
conform to BSD syscalls calling convention.

I use #pragma pack(4) to control alignment. Read about it here:


http://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/64bitPorting/MakingCode64-BitClean/MakingCode64-BitClean.html

GCC 4.5+ uses/requires 16 byte stack alignment per default.

Hello.reds running on MacOS X: http://static.red-lang.org/MacOSX-hello.png

cool :)

Doc, another stupid question: Are there going to be certain platform 
specific parts of code in a Red/System program?

Only OS bindings.

But those defined in current Red/System runtime have an abstraction 
layer, so the runtime API is the same for users on all platforms.

I try to make sure that Red/System code can work the same on all 
platfoms (at least for 32/64-bit ones).

First MacOS X support version released: https://github.com/dockimbel/Red/commit/8b34c8684e273dd31b6778fc654f5e5548db6f37

There are still several things to fix in the runtime.

And I need to change the OS default selection code in the compiler, 
so that the `-t Darwin` option won't be required when running on 
OS X. That fix will also enable the unit tests to work properly.

Just reading %rsc.r, it seems Andreas already added such feature...there's 
probably a bug in compiler.r preventing it from working properly...

Ok, issue fixed, the `-t` option is no more required on MacOS X for 
native compilation.