World: r3wp
[Red] Red language group
older newer | first last |
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". |
older newer | first last |