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

World: r3wp

[Red] Red language group

Andreas
23-Mar-2011
[559]
there is. and where do you get the idea from that this library is 
for tutorial purposes?
Dockimbel
23-Mar-2011
[560x4]
Brian: I don't intend to make Red deviate from the BSD road in anyway, 
I'm very much attached to keep it as open as possible. If some 3rd- 
party libraries with compatible license, can be used to add *optional* 
features, that shouldn't be a problem. The official Red distribution 
will always stay BSD.
Btw, I usually try not to read GPL code for features that I might 
have to implement in my pubic projects (not only Red). I've also 
stayed away from the host-kit source code for the same reason, knowing 
that I might have to work on similar features someday.
I didn't read the asm subroutine library source code, just the Manual, 
which is very informative.
Each routine has several implementations depending on the features 
available at runtime in the CPU (SSE, SSE2, SSE3,...). So, it's a 
bit too large for my needs (I would prefer selecting the best implementation 
at compile-time).
Kaj
23-Mar-2011
[564x3]
A few wildly different observations
I usually try to refrain from being a spelling nazi, but I did have 
a snicker at "pubic projects (not only Red)" :-)
The host kit is published but the licence is undetermined, so you 
could argue it's public domain
Dockimbel
23-Mar-2011
[567]
Hehe :-) Shouldn't chat on AltME while working.
Kaj
23-Mar-2011
[568]
At least not about those projects :-)
Andreas
23-Mar-2011
[569]
Unfortunately, the public domain argument won't get far:
**  Copyright 2010 REBOL Technologies
**  All rights reserved.
Kaj
23-Mar-2011
[570]
I just mean to say that Carl is creating a problem for himself by 
publishing with the monicker "open source" but undetermined licence
Andreas
23-Mar-2011
[571]
Absolutely.
TomBon
23-Mar-2011
[572]
or just take it as WTFPL
Kaj
23-Mar-2011
[573x5]
Even apart from the continuous creation of uncertainty, which everyone 
knows kills business
Anyway, it's hard to keep up with Red development. :-) I meant to 
say that in an unconnected context
I've updated the 0MQ binding again to the latest Red, and implemented 
the remaining 0MQ functions:
http://rebol.esperconsultancy.nl/extensions/0MQ
Among other things, you should now be able to set socket options, 
for example to create publish/subscribe topologies
Dockimbel
23-Mar-2011
[578]
Good job! It's nice seeing Red/System implementation near R2/R3 ones. 
I'll need to find some free time this weekend to start playing with 
0MQ and Red/System.
Kaj
23-Mar-2011
[579]
The code uses the new preprocessor. It's starting to look quite nice, 
and I've split off the examples into separate files, to the binding 
is now a proper separate library/#include file
Dockimbel
23-Mar-2011
[580]
Source code looks good. I need to add a "contributions" section in 
red-lang.org to reference your 0MQ page.
Kaj
23-Mar-2011
[581]
Thanks. It's very nice how you keep solving the crooked parts in 
it :-)
Dockimbel
23-Mar-2011
[582]
Your first implementation was very helpful for improving Red/System, 
especially the preprocessor part.
Kaj
23-Mar-2011
[583]
Communicating in code :-)
BrianH
23-Mar-2011
[584]
Almost all of the mezzanine changes to R2 starting with 2.7.6 are 
MIT licensed as part of R2/Forward. The R2 SDK source includes an 
attribution clause in the headers. Anything else in REBOL written 
by me can be contributed under the same license.
Rebolek
25-Mar-2011
[585]
I am now able to compile RED program that throws "Illegal instruction" 
under OSX which is good thing as it means that the compiler now produces 
at least valid Mach-O header :)
Kaj
25-Mar-2011
[586]
You're implementing Mach-O?
Rebolek
25-Mar-2011
[587]
I'm just trying to ;)
Kaj
25-Mar-2011
[588]
Cool!
Dockimbel
25-Mar-2011
[589x3]
Rebolek: great news! :-)
I'm glad someone picked up the task of implementing Mach-O output 
format.
Rebolek: maybe OS X requires position-independent code for executables? 
Checking it right now...
Rebolek
25-Mar-2011
[592x3]
I should have basics required for functioning executable soon. If 
it still throws "illegal instruction" then, well...
Doc no it doesn't, I just still haven't got all the sections done.
but I'm close.
Dockimbel
25-Mar-2011
[595x2]
Good, it will make the porting easier.
A link for Andreas: http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/MachOTopics/1-Articles/dynamic_code.html


I was thinking about using some similar trick for ELF to allow efficient 
PIC support (avoiding the indirection table). It works by having 
a fixed offset between CODE and DATA segments in memory, so DATA's 
start address can be calculated at runtime, and all globals can be 
accessed using a simple offset.


It should be enough to reserve enough space for CODE segment (let's 
say 10MB) and make DATA entry point fixed? I wonder if the relative 
offsets between segments are preserved when the segments are moved 
by OSes (I hope so)?
Kaj
25-Mar-2011
[597]
10 MB should be enough for everyone ;-)
Gregg
25-Mar-2011
[598x2]
Heck, 640K should be enough for anyone. ;-)
And...REALLY cool Bolek.
Dockimbel
25-Mar-2011
[600]
I first wrote 1MB, then I raised it thinking of possible libs that 
could get statically linked by users. But, it could be even easier, 
just hardcoding the DATA address offset somewhere in the CODE segment 
at linking time might be enough (no need to reserve fixed space in 
CODE segment).
Rebolek
26-Mar-2011
[601]
Another milestone reached ;) Now I get "segmentation fault" instead 
of "illegal instruction" :)
Dockimbel
26-Mar-2011
[602]
Have you defined a new runtime in red-system/runtime/ for OS X?
Rebolek
26-Mar-2011
[603]
Right now I just copied the Linux one.
Dockimbel
26-Mar-2011
[604]
Does OS X support the same syscalls?
Rebolek
26-Mar-2011
[605x2]
Yes. It's not recommended, but I think that for basic test it's enough.
http://www.opensource.apple.com/source/xnu/xnu-1504.3.12/bsd/kern/syscalls.master
Henrik
26-Mar-2011
[607]
are there specific CPU limitations? could this be done for, say, 
a 6502?
Dockimbel
26-Mar-2011
[608]
It requires 32-bit integer support for source compatibility with 
other platforms, but if you don't care about compatibility, it should 
be possible to make a 6502 emitter ;-)