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

World: r3wp

[Red] Red language group

Endo
5-Jul-2011
[2685]
Wow! veeery nice news! Thanks guys!
Maxim
5-Jul-2011
[2686]
really good work guys!
Kaj
5-Jul-2011
[2687]
http://www.osnews.com/story/24921/Red_System_Reaches_Beta_Loads_Syllable_Shared_Libraries
Dockimbel
5-Jul-2011
[2688]
hehe, again on OSNews! Thanks Kaj!
Kaj
5-Jul-2011
[2689x2]
My pleasure
As long as you keep Red relevant for Syllable, I can get it on OSNews 
;-)
Dockimbel
5-Jul-2011
[2691]
Sounds like an invitation to rapidly fix the cURL binding issue. 
;-)
Kaj
5-Jul-2011
[2692x2]
Yeah, it's a tricky one
I was going to ask you if you considered sending the beta to plnews.org, 
but it seems to be gone
Dockimbel
5-Jul-2011
[2694x2]
If you can provide a minimal example exhibiting the issue, I should 
be able to locate the problem from the disassembled code.
I will make post a news on freshmeat.net tonight (I still have some 
things to change on the web site).
Kaj
5-Jul-2011
[2696x2]
I'm not used to working at that low level, so I'm moving a bit slowly 
on it
We're becoming popular. The trolls are very quick to respond now
Dockimbel
5-Jul-2011
[2698]
:-)
Kaj
5-Jul-2011
[2699x4]
http://development.syllable.org/documentation/introduction/part-1.html
GDB on Syllable currently only supports real-time debugging, as crashed 
applications do not generate a 
core" file (crash dump)."
If GDb still works, I guess that prevents me from getting a backtrace
The kernel log is probably the best backtrace we can get
Andreas
5-Jul-2011
[2703x3]
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
Kaj
5-Jul-2011
[2706x4]
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
Jerry
5-Jul-2011
[2710]
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.
Dockimbel
6-Jul-2011
[2711]
Jerry: thank you! 37k followers, that's huge!
Henrik
6-Jul-2011
[2712]
silly question: is it possible now to build a CSV parser in Red?
Dockimbel
6-Jul-2011
[2713]
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.
Henrik
6-Jul-2011
[2714]
ok, I was just looking into the idea if it was possible to build 
one with better performance than what I currently can.
Dockimbel
6-Jul-2011
[2715]
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.
Henrik
6-Jul-2011
[2716]
ok, thanks
Kaj
6-Jul-2011
[2717]
The parsing functions in the C library binding can get you halfway
Kaj
7-Jul-2011
[2718]
Got the cURL binding to work on Syllable, starting from Andreas' 
example. :-) Will research some more and report on the tracker
Dockimbel
7-Jul-2011
[2719]
Good news!
Maxim
8-Jul-2011
[2720x2]
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.
Steeve
8-Jul-2011
[2722]
good sauce
Dockimbel
8-Jul-2011
[2723x2]
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
Andreas
8-Jul-2011
[2725]
And straight from the source (I think we already had this here in 
the past):
http://www.agner.org/optimize/calling_conventions.pdf
Dockimbel
8-Jul-2011
[2726]
You're right, and it looks like I missed it last time. Thanks for 
giving the right source link.
Dockimbel
9-Jul-2011
[2727x4]
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
Ashley
9-Jul-2011
[2731]
Doc, great news for those of us who primarily develop on OS X these 
days.
Kaj
9-Jul-2011
[2732x3]
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