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

World: r3wp

[Red] Red language group

Dockimbel
21-Jun-2011
[2348x2]
Yes, it depends on the calling convention.
For example, if you encode the arguments number as the first value 
pushed on stack, you can pass a variable number of argument. The 
called function needs, of course,  to use the same convention.
Andreas
21-Jun-2011
[2350x3]
freebsd with libc requires a bit more work
freebsd's libc expects two symbols already exported: environ and 
__progname
so for that we'll most likely require an "#export" directive or something
Kaj
21-Jun-2011
[2353x2]
Bummer
Using Syllable as a development workstation for FreeBSD would be 
a cool feature :-)
Andreas
21-Jun-2011
[2355]
well, i could hardcode a hack in the ELF emitter
Dockimbel
21-Jun-2011
[2356]
If the hack doesn't disrupt too much the existing code, why not.
Andreas
21-Jun-2011
[2357x3]
we'll probably want #export for shared libraries anyway
A Red-generated FreeBSD binary: http://bolka.at/2011/tmp/hello-fbsd.bin
:)
(And the hack that made it happen: http://pygments.org/demo/19023/.)
Kaj
21-Jun-2011
[2360x6]
Cool :-)
size? struct! doesn't work yet:
#include %../ZeroMQ-binding.reds
print-integer size? message!
print-newline
*** Compilation Error: undefined symbol: message! 

*** in file: %/users/administrator/Red/Red-ZeroMQ-binding/examples/reply-server.reds 
*** at:  [message! 
    print-newline
message! is aliased in ZeroMQ-binding.reds, but it doesn't seem to 
carry over to the source file where it's included
The 0MQ binding should now be thread safe and release its allocated 
memory
Dockimbel
22-Jun-2011
[2366x5]
Andreas: great!
Kaj: the compilation message there is wrong, the compiler wasn't 
expecting an alias name (but it should). I will fix that today.
Andreas: heelo-fbsd.bin works flawlessly on FreeBSD8.2!
Andreas: adding support for shared library is in my todo list for 
the next weeks.
Got my virtual struct! lib working ok. It is not perfect but should 
cover our needs for Red bootstrapping. Finally, we'll be able to 
get rid of /View.
Kaj
22-Jun-2011
[2371]
Great!
Dockimbel
22-Jun-2011
[2372x2]
Will merge it to main branch in a few minutes.
300 commits reached! And now the compiler runs on /Core!
Kaj
22-Jun-2011
[2374x2]
Excellent
(Must write a cheer bot one of these days)
Dockimbel
22-Jun-2011
[2376]
hehe :-)
Henrik
22-Jun-2011
[2377]
Silly question (I'm not in the loop), why was View necessary? Feel 
free to point to a blog post or something that explains it.
Andreas
22-Jun-2011
[2378x2]
because we used struct! quite heavily
which (still) is not available in /core
Henrik
22-Jun-2011
[2380]
ok, interesting.
Andreas
22-Jun-2011
[2381x2]
the binary emitters (PE, ELF) need to adhere to the respective format 
specification, which is usually supplanted with C struct definitions. 
the primary issue is that C structs have particular (platform-specific) 
memory layout rules, which REBOL's struct! mimicks.
for example a struct of an 8-bit char! and a 32-bit integer! takes 
up not 40-bits but actually 64-bits in size (due to alignment constraints, 
in this case).
Henrik
22-Jun-2011
[2383]
so this is one of the challenges that are required to solve, when 
creating a new binary emitter?
Andreas
22-Jun-2011
[2384x3]
when writing a new emitter, the "challenge" is mostly the rather 
tedious task os transliterating C structs into REBOL struct!s
Have a look at the current ELF/PE emitters, for example:

https://github.com/dockimbel/Red/blob/master/red-system/formats/ELF.r#L87

https://github.com/dockimbel/Red/blob/master/red-system/formats/PE.r#L145
For comparison, that's the spec of the ELF "Ehdr" struct:
http://sco.com/developers/gabi/latest/ch4.eheader.html
Dockimbel
22-Jun-2011
[2387x3]
REBOL/Core 2.7.8 doesn't run on FreeBSD8.2, it requires libm.so.4 
(FreeBSD 4)...
# ln /lib/libm.so.5 /lib/libm.so.4
# rebol

/libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required 
by "rebol"
Getting /Core to run on FreeBSD looks like a real challenge :-)
Kaj
22-Jun-2011
[2390]
Aren't there "compat" libraries for FreeBSD 4 etc. backwards compatibility?
Dockimbel
22-Jun-2011
[2391]
Yes, but it requires me to install a lot of stuff...The real issue 
is that /Core is built on obsolete libraries version.
Kaj
22-Jun-2011
[2392]
I know, but all operating systems should deal with backwards compatibility, 
and the Unixes usually do it with optional packages that you need 
to install
Andreas
22-Jun-2011
[2393x3]
hmm, /core 2.7.8 runs fine for me on freebsd 8.2
let's see where those ancient libm/libc versions come from :)
compat6x-amd64-6.4.604000.200810_3 :)
Kaj
22-Jun-2011
[2396]
So the compatibilty base seems to be FreeBSD 6
Dockimbel
22-Jun-2011
[2397]
I tried: pkg_add -r compat6x-amd64 from http://www.freshports.org/misc/compat6x, 
but keep getting "unable to fetch messages".