World: r4wp
[#Red] Red language group
older newer | first last |
PeterWood 21-Apr-2013 [7140] | add -> added |
DocKimbel 21-Apr-2013 [7141] | That is just called team work. :-) |
Arnold 21-Apr-2013 [7142] | Would be nice to be able to download the Red zip file and be able to compile scripts in another directory? |
Kaj 21-Apr-2013 [7143] | How do you mean? What you seem to ask is already possible |
Arnold 21-Apr-2013 [7144] | I was in the impression that Red and Red/System scripts should be in a directory within the Red dir. Where the other (test)scriots are too. I am now hesitant to put a new zip over the old one and lose my scripts (but maybe even that fear is vain). |
Kaj 23-Apr-2013 [7145x2] | Nenad did a lot of work on making it location independent. A few issues remain, for example that Red/System always gets compiled into the builds/ subdirectory, but the source can be anywhere |
If you just unzip, thereīs no reason your scripts would be lost, but you can make it a lot easier by not putting them in the Red folders | |
Andreas 23-Apr-2013 [7147x2] | Not sure what mode of compiling Red/System you are thinking about, but if you compile via rsc.r, you can tell it where to write the binary by passing a `-o` command-line option. |
As in: rebol2 -qsc rsc.r -o hello tests/hello.reds | |
Kaj 23-Apr-2013 [7149x3] | Iīm referring to the normal case of wanting to get the output in your working directory. Red does that now, but Red/System not without using that switch |
You also need to give the full path to the source file | |
Actually, you also have to give the full path in the -o switch | |
Arnold 23-Apr-2013 [7152] | I did some compiling today and found the resulting executable in the build directory. |
Andreas 23-Apr-2013 [7153] | Relative paths work for me. |
MaxV 23-Apr-2013 [7154x2] | Ishttps://github.com/dockimbel/Redthe official Github site? |
Is https://github.com/dockimbel/Redthe official github site? | |
Pekr 23-Apr-2013 [7156] | yes, it is ... |
Kaj 23-Apr-2013 [7157] | ./ paths donīt work for me on rsc.r |
DocKimbel 23-Apr-2013 [7158x2] | Kaj: I think I've found a workaround for the semi-random compilation crash on Linux. It seems SELECT has some deep stability issues in R2. |
At least in 2.7.6 and 2.7.8. | |
Kaj 23-Apr-2013 [7160x2] | Good news and bad news at the same time... |
Didnīt you already replace SELECT with FIND in other places? | |
DocKimbel 23-Apr-2013 [7162] | Yes, in compiler.r, I did replace SELECT on most places where it was used on hash! series. |
Pekr 23-Apr-2013 [7163] | Don't tell Fork, or you will need R3 soon :-) |
DocKimbel 23-Apr-2013 [7164] | ;-) |
Gregg 23-Apr-2013 [7165] | But just think what a great test this will be for Red's SELECT when it is self-hosting. :-) |
DocKimbel 23-Apr-2013 [7166x4] | Red codebase is the only place where I've encountered those SELECT internal instabilities, I don't remember even seeing them in Cheyenne. |
Gregg: sure ;-) | |
BTW Kaj, you should be able to play with Red/System shared libs generation on Linux soon. | |
Actually, the SELECT expression where the compilation error occured was involving a word lookup in an object context, so those lookups are done, as far as we know, using internal hash tables, I wonder if the issue is not related to hash tables implementation bugs in R2. If I tried to put a PROBE between SELECT and the word lookup, the error was disappearing. | |
Pekr 23-Apr-2013 [7170] | btw - would there be any benefit with the Red's ability to create shared libs, for R3 guys? R3 can already use Red to generate extensions, right? And R3 lacks the interface for DLLs. Maybe for R2 guys? |
Kaj 23-Apr-2013 [7171x3] | Doc, great; that will open up many more possibilities |
Petr, it will make the R3 bridge available for other platforms than Windows | |
It will also allow writing shared libraries for R2 for other platforms than Windows | |
DocKimbel 23-Apr-2013 [7174] | Question: does a Linux shared library need to call __libc_start_main() or can it assume safely that this will be done by the host app? |
Kaj 23-Apr-2013 [7175] | Seeing how much trouble we had forcing us to call the C library setup in Red programs, I think libraries donīt need to do it, but thatīs conjecture |
Andreas 23-Apr-2013 [7176x2] | Nope, a lib must not this. |
Sorry, that came out incoherent: a library does not need to call __libc_start_main. | |
DocKimbel 23-Apr-2013 [7178x2] | Good! |
I'm doing some changes in the exit sequence of Linux/Syllable executables. Currently, the Red main() passed to __libc_start_main was never returning as it was calling exit(). I'm changing that now to give the libc a chance to call its .fini routines and let it handle the exiting. | |
Arnold 23-Apr-2013 [7180] | About the relative path, that was possible. Indeed. The Rebol console changed the path a few times so i needed to change it accordingly, but after that it was reusable. |
Kaj 23-Apr-2013 [7181] | Are you talking about compiling Red or Red/System? |
Arnold 23-Apr-2013 [7182x2] | I posted "my" "random" program via the Red mailinglist. It seems to work, but I really wonder how this is possible, maybe because the same or other memory is allocated. |
Red/System | |
Kaj 23-Apr-2013 [7184] | Odd, I canīt use ./ paths from the working directory |
Arnold 23-Apr-2013 [7185] | I used relative paths ../../red-ownscripts/ |
Kaj 23-Apr-2013 [7186] | ./ is a relative path |
Arnold 23-Apr-2013 [7187x2] | On Windows 7 not on macosx |
And my Red is a couple of weeks old. | |
Andreas 23-Apr-2013 [7189] | ./something paths work for me, on Linux. |
older newer | first last |