Could R3 use RED's DSL to compile R3 programs?
Here's a whack idea. Could R3 use RED's DSL to compile R3 programs? If I understand correctly the compiler, linker, etc, are just a DSL of Rebol. Also the view and VID of RED are just DSL's of Rebol so couldn't R3 be used to jump start RED on various platforms? The idea being that R3 is all C code which you can compile now anywhere, supposedly, in theory. Hostile fork has said he's cleaned up a lot of R3 code so that it can be ported easier. The plan being to use the cleaned up hostile fork code, combine with RED's compiler, combine with RED's view and VID. The backend graphics library could be AGG or X11 for platforms that have no present graphics libraries set up to be used by RED presently. (hostile fork said he deleted this(the X11 code).
I didn't know Unix Rebol packages used X11 for the backend graphics library in R3 but assuming it was there then maybe that is so. Could be that AGG uses X11. Not sure.).
Of course probably most will wait for RED but it would nice if the code converged but have R3's base in C so as to have a different path yet use all the advances of RED as they come out. Also Saphirion R3-gui has networking.
The main question is can RED's DSL compiler compile R3 code?
My apologies for asking such weird questions. I'm just really curious about certain things. I'm probably the only person I know that's interested in Basalt glass fiber for reinforcing concrete.
posted by: Sam 24-Jan-2017/3:52:25-8:00
> Hostile fork has said he's cleaned up a lot of R3 code so that it can be ported easier.
I don't know that I said that the motivations were *greater* portability.
The goal was to keep the core at about the same level of dependency control as R3-Alpha (a "Core" build). Yet be based on the Atronix/Saphirion codebases that had diverged from that into a monolithic View-only build. Basically, to stay the course of being a simple low-dependency ANSI C89 program.
So most of the "cleaning up" has to do with fixing systemically broken things. A presentation if you missed it:
> The main question is can RED's DSL compiler compile R3 code?
No. And there are few R3 codebases out there in use, and none of those would help in porting Red to new platforms.
One might argue that if Rebol3/Ren-C could be used to build Red itself that would help. But it would only help run the compiler on the target...and not in running the instruction set of the target in the produced executable.
(And after all, the *wisest* people in the room know that bootstrap is the real test of whether your tool is any good...so Red should be bootstrapped as soon as possible...should have been already, right? :-P)
posted by: Fork 24-Jan-2017/5:03:08-8:00
"I don't know that I said that the motivations were *greater* portability."
"...Basically, to stay the course of being a simple low-dependency ANSI C89 program..."
I guess that, portability, was more of my internal thinking. My apologies for putting meaning on things you didn't say.
"...But it would only help run the compiler on the target...and not in running the instruction set of the target in the produced executable..."
Yes. True. I was thinking more along the lines that R3 has some things in it now that RED doesn't so you could use R3 instead but use some of RED's GUI which looks like it's going to be good. It's very likely that my thinking is wrong on this but if I didn't ask I couldn't get an answer.
"...(And after all, the *wisest* people in the room know that bootstrap is the real test of whether your tool is any good...so Red should be bootstrapped as soon as possible...should have been already, right? :-P..."
I didn't say that or presume it. I'm not the wisest person, don't pretend to be and that's why I ask silly questions occasionally. Every now and then, against all odds, I might even ask a good question. :)
Thank you Fork for all the work you did on ren-c. Cleaning up is always tough work. Everyone wants to cook but no one wants to wash the pans.
I would like to ask you a question Fork. I think you would possibly know the answer right away from all the deletes of references to the X11 library in ren-c. Does the low level backend graphics library for Unixes run on X11 with AGG still present or is it just X11 using the X11 library primitives?
posted by: Sam 24-Jan-2017/11:43:36-8:00
> I didn't say that or presume it.
I was making fun of the idea because I think it's a terrible plan to make bootstrap a first target for a system--and a very bad strategy for Red.
> Does the low level backend graphics library for Unixes run on X11 with AGG still present
You'll have to ask @ShixinZeng about the specific dependencies. The idea is that it can target OpenGL for its drawing with a possible fallback to AGG. (I imagine you'd be able to make an OpenGL-only build.) But it would not be written to use an X11 framebuffer directly, no...that is a slower route than OpenGL on most of today's systems with graphics cards.
My understanding is that some amount of X11 is still involved in all common Unix desktops for basic windowing, and Red would be thus dependent if using Gtk or whatever. Maybe:
posted by: Fork 24-Jan-2017/13:15:56-8:00
Fork,"...My understanding is that some amount of X11 is still involved in all common Unix desktops...".
In my reading about X11 my understanding is that X11 is a very low level graphics library like AGG(yes it does way much more but only concerning the GUI part) and that all the desktop, window GUI's are built on top of X11 exactly like "view" is built on top of AGG.
Here's a wikipedia article on XCB which is a new library made to clean up some of the complexity of the Xlib(X11). If you look at the picture "Xlib and XCB in the X Window System graphics stack.svg" you see all the windows systems use X11. I also read this elsewhere but can't find the link offhand.
I had a thought that RED should use the Xlib instead of GTK because GTK is sort of like VID. A higher level library. Where Xlib is very much like AGG graphics library in terms of it's graphics functions. So Xlib would much lower level as a target for a graphics backend for RED in Unix type OS's. Also since X11 Xlib can be used anywhere, even windows, it would be a standard that could be used as backup or base.
I had an idea that if RED targeted X11 then RED, being so small, might become the standard software used to make GUI installers for all BSD and Unix platforms. The complexity of X11 I think is what makes GUI installers problematic and why there's no standard. They're all kind of hacked on. Now if RED with it's super easy graphics could be booted with a small X11 then installers would much easier and it would use a library frequently included. OpenBSD, NetBSD and DragonFlyBSD I believe all have X11 as part of the basic system included.
I looked at the source code for RED under
I'm not able to dis-concern what is going on. If I had a list of exactly what functions of RED "view" are and where they do
posted by: Sam 25-Jan-2017/20:40:48-8:00
I'm not able to disconcern what is going on. If I had a list of exactly what functions of RED "view" are and where they do
(oops "what they do")
then maybe I could somehow map them to call X11 or at least find the parts of X11 needed to be called. I'll keep looking at it maybe over time I can figure out. And maybe I can't :)
The basic idea is to expose Unix hackers to RED by making a part of the installation system. A foot in the door. Like product placement at the front of the book store or the super market. If the installation depends on it then it would be the first thing you see. This might get Unix hackers to use "our brand", RED. Now most software is not on Unix but I think it's fair to say that a lot of the hard core hackers use Unix and if your a programmer what do you want to be...hard core. You want to be seen as the coolest and Unix is still seen to be cool, even with all it's problems. People use all kinds of scripting BASH, Perl and python because...well it's in the base system and there to use.
posted by: Sam 25-Jan-2017/21:00:28-8:00
Doc needs every foot in the door possible, and goals like that are attainable :)
posted by: Nick 26-Jan-2017/7:42:44-8:00