• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r4wp

[#Red] Red language group

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.
Kaj
23-Apr-2013
[7190]
From a separate working directory?
Andreas
23-Apr-2013
[7191x2]
That's indeed still partially broken (completely in Red/System, for 
-o in Red). Thanks for reporting.
I'll push a fix shortly.
Kaj
23-Apr-2013
[7193]
Thanks!
Andreas
23-Apr-2013
[7194]
Pushed. If you give it a try, please let me know if it works for 
you as well.
Kaj
23-Apr-2013
[7195]
Iīll have a go tomorrow
PeterWood
23-Apr-2013
[7196x3]
Did you run the tests before pushing the commit Andreas?  I now have 
a few failing Red/System tests. I'm in the middle of writing some 
tests and need to get those commitable before I can take a look.
From a quick look your commit has changed the default for red/system 
so that executablles are now built in the current working directory 
rather than the builds directory.
Quick-Test is built to handle the previous behaviour so is broken 
at the moment.
Arnold
24-Apr-2013
[7199]
(@Kaj your apostrophe is a Yen sign in my AltME on Mac)
PeterWood
24-Apr-2013
[7200]
Being written in REBOL/View, ALTME encodes characters in the Windows 
codepage under Windows, MacRoman under OS X and UTF-8 (I think, it 
may be ISO-8859-1) under Linux. So if you use any character  other 
than standard ASCII characters, it will appear differently on differnet 
systems.
DocKimbel
24-Apr-2013
[7201]
Andreas: watch out for regressions, this is a sensitive feature as 
it affects everything else: test suite, my own local tests scripts, 
Red compilation toolchain, documentation on github homepage, etc...