When will Red become useable for Rebol users?
I'm hoping there are enough higher level rebol users who are following the red development arc to tentatively answer my question.
I understand red SYSTEM is already usable. I don't know if it is really as complete as the red roadmap seems to show but I gather the red interpreter is being written in it. I previously saw a simple game, written by hostile fork, ported from C to Red System. So, red system is apparently usable already.
But red system isn't really red, much less rebol. If I understand correctly is merely a C replacement which is more rebol-like in syntax but doesn't otherwise add any functionality versus C?
I go to the red-lang site pretty much daily. It is encouraging that new work and fixes are getting added at a much faster rate now than they were before the red funding announcement of Jan 17.
But - getting again to the heart of my question - what is still required for, at least, the rebol hotshots to BEGIN using red for at least SOME rebol-like programming? What are the crucial elements still missing and is there any room for an intelligent guess as to when the first, rough BETA will be ready for playing around for the rest of us?
Put a bit differently, there is the 'roadmap' on red-lang (http://www.red-lang.org/p/roadmap.html) but the needle really isn't moving perceptably on the components of the roadmap. The needle appears to have been completely stuck for six months or more (unless I have gotten fooled) at:
'Write Red runtime in Red/System
65 %
Memory allocator
90 %
Garbage collector
10%
Run-time lexical scanner
100%
Datatypes
52 %
Actions
65 %
Natives
55 %
Interpreter
100 %'
That's okay...'Rome wasn't built in a day'. But, it still begs questions such as WHAT few items would make at least a very limited - but still real - subset of the red interpreter approachable? I would think (perhaps naively) that if the memory allocator could just get from 90% to 100% there would be a playable subset. (That is, I'm thinking that the Garbage Collector could be forgone for a time ... at least until a simple application ran out of memory and crashed!
The Interpreter is supposedly ALREADY 100% complete (and has been for more than 6 months). So that would make at least red-runtime close enough for government work'? Couldn't non-systems rebol programmers begin to play then? Yes?... No? Couldn't at least some toy applications be coded without 100% on the natives and actions front?
And if not - because natives and actions really need to be at 100% or nothing - then wouldn't 'normal' rebol programmers at least be able to jump in and start porting/coding IN 'REBOL' the remaining natives and actions from Rebol 3??
I'm posting this question well knowing it is probably hopelessly ignorant in some regards. Perhaps more than some.
But I think it is a good question or, at least, a reasonable question.
I am hoping someone more connected to the red language development process and team might be able to venture a rough answer?
posted by: stever 11-Feb-2015/10:22:41-8:00
Since my pseudonym was mentioned, I will weigh in on this pertinent question.
Firstly, the dungeon.red "game" wasn't ported from anything. I was scanning and throwing out boxes of stuff, and found a thing I'd "designed" but never managed to write as a kid:
https://github.com/hostilefork/teenage-coding/tree/master/DUNGEON
Wanting a bit of closure, I thought I'd write an implementation. But if I was going to bother with such a task, I thought I'd make it a "less useless exercise". I picked to use it as a test of Red...vs. just doing it in Rebol and then "porting" it. I wanted to see "how bloody" the bleeding-edge was.
The most difficult thing about the process of relying on Red as the only tool was the terse and uninformative error messages. I'd add code, then get a new error...not knowing what line introduced the error. So it became a process-of-elimination; I'd remember what I'd added, comment out stuff, try and find what the complaint was about.
(Full disclosure, I did actually... at one point, break and cheat. Toward the end with a longish body of code, Red gave some error and I got impatient. I'd spent a while eyeballing it, but couldn't figure out what the complaint was. So I went through...removed all the return: stuff and other not-yet-Rebolisms, and ran it through Rebol to try and get a more meaningful error. Found it instantly, and moved on. So despite how it may appear, I do not let random thought experiments take up unbounded time.)
Compile-error-reverse-engineering easily took 30% or more of the time; I probably should have kept notes to make it more scientific. Also I had to add an input routine to Red as one did not exist then...it could output but not input. I would say offhand it took maybe 12-14 hours total?
( Code-wise I'll mention that though the task could be done much more easily than I wrote it. I knew that, but was trying to generalize it somewhat, as a poor-man's "rendering"...so you could "resize" the display and it would build the walls overlaid as you move from farther to "closer to the camera". Much easier solutions are possible if you use a "light up LCD segments on a watch" kind of fixpoint. Someone even pulled it off on a C64 when I framed it up as a puzzle, which was super cool...I love this "internet doing things for your amusement just because you asked" thing: http://codegolf.stackexchange.com/a/16165/57 )
At the time, I wanted to make a video, showing all the cross-compilation matrix working. So I wanted to build on each platform and show it targeting each other platform. A couple of them did not work; I don't recall exactly which at the time. Like Mac could build for Windows, and Mac could build for Mac, but the Linux executable wouldn't run on Mac. Something like 2 out of the 9 failed.
(If someone is motivated to check the build matrix today, it would be interesting to see what's what. I was waiting to go into it until there was an official answer about the input patch the program needed to run at all. That took time to happen, and by the time it did happen I was working on other things.)
Long story short: I think the usability story is not so much about missing features. Everything is missing features (as per "a stranger is just someone you don't know yet", a "feature is just code that hasn't been written yet"). The usability issues I found most difficult related to the cycle of development with errors and indicating line numbers or sources of problems while coding.
AFAIK this has not been a focus in the intervening time. So hopefully one of the new hires can become "usability czar", who undertakes tasks similar to dungeon.red and asks "what is it, exactly, that makes this so painful" and works to alleviate that pain.
posted by: Fork 11-Feb-2015/13:12:03-8:00
Steve, best is to go out and use Red. Discover what is and what is not already possible. I think you will find a lot of things that can be done already. By the time you have made the basics of your app, you can anticipate about the still missing parts programming thos parts as if they are done like in R2. Remember R2 is the example for Red. I do the same and my app has to wait at least till release 0.7.0 to be able to run. Or I could integrate one of the extensions that Kaj has contributed to provide missing functionality.
posted by: iRonald 12-Feb-2015/9:14:34-8:00
I'm waiting for GUI, I/O, and networking. Doc's goal is to have 50,000 Red users within 1 year from now. I can't imagine that 50,000 people will want to use Red without at least those features. So, if everything goes according to his plan, I'd expect to see those basics sometime well before that time period.
posted by: Nick 16-Feb-2015/9:35:20-8:00
is there a red documentation?
on the red site, I see only red/system documentation.
also when is red scheduled to reach version 1.0 ?
posted by: newuser 16-Feb-2015/14:12:25-8:00
Hi newuser,
Yes there is help for Red. It is in the console type help there. You can do this also via try.rebol.nl
If you tell us more about yourself, you could get a more specific answer.
Hopefully this year will see much progress toward 1.0 but it will be a long wait.
@Nick, 50.000 Red users? Wow, well to Chinese standards not many I guess. No progress in coming days, It will be newyear next thursday in China.
Everybody is waiting for the GUI, I/O, Networking AND full cross platform, not just 1(ok 2) like R3. But the team can't do magic, what they do they do pretty thorough.
posted by: iRonald 17-Feb-2015/2:34:45-8:00
IMO, Rebol3 devs should (*must*) join Red dev team, so to concentrate all the efforts on Red.
Presently, as I see it, Rebol 3 and Red are duplicate effort.
posted by: Jma 17-Feb-2015/5:19:14-8:00
There are a lot of things which aren't clear to me about the red project. This thread seems like a reasonable place to bring them up.
(1) What possible reason would their be to use Rebol 3.0 once Red 1.0 comes out and is solid? A number of posters - I think Nick amongst them? - have stated they each would have their niche. Please explain? Red will have an embedded interpreter and a REPL, too, so it isn't that....
(2) Is red 1.0 mostly going to look like rebol 2.0? Or 3.0? Or something in between (mostly likely, I gather) or really neither? Some answer to this, would help many of us better prepare. I would think this would be an open discussion and already well on the way to resolution. But it appears, instead, to be more like a classified secret? I've looked for comments from Doc or others on this sensible question but I've seen very little.
(3) I would have thought that the GUI dialect from Red 2.0 would have been nearly trivial to port to 3.0 and, even if imperfect, would have given a cross-platform GUI environment which would have been good enough for now until something better could be proven cross platform. But that "obvious" first step hasn't happened. Why not? Is there any reason to think red 1.0 will ship with at least a rebol 2.0 level GUI? I don't think the average programmer is likely to take any new language very seriously if it doesn't ship with at least basic graphics. I think that has been the curse of Rebol 3.0.
Hopefully all my questions are seen as constructive. I am trying to be constructive, that is for sure.
posted by: stever 17-Feb-2015/20:37:11-8:00
Ok. Dinking with red-0.5 right now. I would still appreciate a general answer to my questions, if they seem even half worthy, but "help" is giving me a list of implemented words which I can attempt to compare to r2 vs r3.
posted by: stever 17-Feb-2015/21:02:17-8:00
Yeah!!!! Look for GUI in Red 0.6!!!!!
https://trello.com/b/FlQ6pzdB/red-tasks-overview
Says so right there! I took a look at the red development room on stack overflow and it was like manna from heaven!
posted by: stever 17-Feb-2015/22:36:51-8:00
I've been told the GUI will be different for each platform. Using, subject to change, GTK for linux and different libraries for each platform. Also maybe there will be a new library like AGG that was used for rebol2. I hope they don't use different libraries for each platform because I believe the upkeep will gradually cause bit rot in the system. In other words it's not settled.
A thought it might be nice to use the libraries from Enlightenment desktop. Let's look at the "Edje" library. Quote,"... Edje is a meta-object design library that is somewhere between Flash, PSD, SVG and HTML+CSS. It separates design out from code and into a dynamically loaded data file. This file is compressed and loaded very quickly, along with being cached and shared betweeen instances.
This allows design to be provided at runtime by different design (EDJ) files, leaving the programmer to worry about overall application implementation and coarse grained UI as opposed to needing to worry about all the little details that the artists may vary even until the day before shipping the product...."
"Edje" keeps track of the various elements, buttons, whatever so the programmer doesn't have to. What would be the advantage. It's works on all platforms. It has lots styles and different skins. I think it also has OpenGL acceleration. I know it works with OpenGL.
https://www.enlightenment.org/p.php?p=about&l=en
https://trac.enlightenment.org/e/wiki/Edje
posted by: Sam 18-Feb-2015/1:26:27-8:00
Sam, Have you expressed your thought to Doc or whoever is taking the lead on the GUI? A decision on this is apparently coming up fast if it hasn't already been firmly decided.
I should think the #1 lesson of Rebol 3 would be taken to heart: Don't splinter the community on the basic GUI.
I work on a Mac. A "better" graphics engine than that in Rebol 2 doesn't interest me, at all, if it doesn't run on my Mac. And I doubt Nick has much interest in writing separate versions of his tutorials for each platform.
"The thing which matters most must not be at the mercy of the things which matter less." - Goethe
If some whiz-bang needs "better" graphics for a project or platform, that's fine; let him write it. But the learning community mustn't be splintered. The standard cross platform graphics of Java may not be technically impressive, but that stsndard is what ties the Java community together and keeps them a force to be reckoned with.
I've heard of enlightenment - and, instigated by your comment, just spent a few minutes reading about it. But I've not used it. If you have and think it is a good choice then please try to get the attention of the development team.
posted by: stever 18-Feb-2015/13:36:58-8:00
The choice for GUI will be the native solution of the platform. Least dependencies. I/O is planned for 0.7.
Things are heading in the right way. Steve, just start programming and you will notice the boundaries of the language, and you will be surprised how much is possible even at this stage.
posted by: iRonald 18-Feb-2015/15:24:59-8:00
iRonald, I have been playing with red-0.5 and, you're right, I have been surprised how much is already there! I won't claim I've been"programming" yet, however, as I'm pretty much on training wheels at this stage. (ADD, I'll claim...flipping between rebol, racket, haskell, python and r, rather than digging in to code until I'm half competent;-/
But commenting can be fun, too!
If you can carry one comment back to the guys in the creative coding trenches, it would be "Thank you!"
If you can carry back two, maybe ask them if they can do better than "*** Interpreter Error: missing argument..." which keeps crashing me out of the interpreter and back to the bourne shell.
Oh, and a question for you maybe? How do I call the system compiler from the interpreter, or are those completely separated at this stage?
posted by: stever 19-Feb-2015/0:34:20-8:00
You need to read the page here: https://github.com/red/red Under Making a Red "Hello World" there is point 6. Want to generate a compiled executable from that program?
Or you need a Rebol console to compile from source..
posted by: iRonald 19-Feb-2015/8:03:37-8:00
Stever,
1) Red will likely take Rebol's place in many areas, if it's successful. Because Rebol is written in C, though, there are probably still some categories where Rebol may still fit a niche. First, experienced C and C++ developers may prefer to extend and enhance Rebol - look at what Fork is doing with RenGarden. Also, Emscripten will allow Rebol to be ported to the browser - the same is true for any other new platforms in the future which support C compilation (likely everything). Doc intends to make an LLVM target, which should be portable to the browser, and hopefully other new platforms, but that's down the line a ways. So Rebol can exist immediately on new platforms which may take a while for the Red team to build an entirely new target from scratch. Other things like Rebol's existing graphic subsystem are already well established. We don't know when or how that will be implemented in Red.
2 and 3) The console will be just that, and the compiler will be a command line tool. There is no look for those things. There will be support tools such as a debugger which should make us of native user interface layouts. So I'll combine your questions 2 and 3 above. The Red GUI will be native to each platform, which is opposite Rebol's approach.
REBOL: Rebol's GUI tools are built upon its own lower level graphic system. Draw commands are interpreted by the /View subsystem, then rendered by AGG. VID, RebGUI and other GUI dialects are interpreted to compose lots of graphic View elements to form a user interface layout, to which event handling is added. When you see a button, for example, in a Rebol GUI, it's drawn on the screen according to a bunch predefined compositing guidelines defined entirely in Rebol View code. Those guidelines can be altered by anyone with visual design and coding talent (to create different skins, for example), and the event handling can be adjusted as needed too. If we want to port the Rebol GUIs to any other OS, all that needs to get converted is the very lowest level rendering commands which draw dots on the screen (handled by AGG in R2).
RED: Red's approach to GUIs will be totally different. It will use the native, built-in capabilities provided by each operating system to put, for example, a button on the screen. That will make Red GUIs look like those in any other native compiled app. It will also take a little longer to port to each OS, because different code will need to be written to interface with each platform. Also, because Red's GUI will not be built upon an internal set of Red drawing definitions, there will be less control over "skinning" and, more importantly, we may not get a draw dialect to do graphics initially (only the very high level GUI things like buttons and fields, provided by the OS). Doc has said that he may eventually support both options, as there are benefits and drawbacks to each. Either way, the GUI dialect code which allows developers to layout user interfaces, is expected to look a lot like R2's VID GUI dialect - and that dialect code should look (to the developer writing code to lay out GUI interfaces) basically the same on every platform.
posted by: Nick 19-Feb-2015/8:29:01-8:00
Nick, Thanks for the explanation (and lots of other things starting with your numerous tutorials and this site). With all your knowledge I'm surprised you aren't drafted on the development team...yet?
If I'm understanding you, I think they are making a mistake. Yes, I can understand the importance of being ABLE to present as a native app (especially as they are clearly making Android their #1 target for profit). But able shouldn't mean only - and it shouldn't be the default. The default should be that a developer on Windows, a developer on Mac, and a developer on Android should all be able to run the same code and see the same thing. THEN it should be possible to switch explicitly to a native presentation and tweak it.
Maybe I'm being unrealistic, although that's not clear to me. And, no, I'm not overlooking the added complexity of supporting both portable and native. But the rebol/red community is really small and will be for some time. Ghettoizing the community even further is deadly dangerous; and I really do think that has been rebol3's biggest mistake. Certainly that is why I don't use it at all....I want to be able to run example code and (eventually) ask for debugging help and sharing!
It would have been so much better if they just could have aimed implement something like the r2 graphics system for the initial release but done so in a way that the graphics an GUI were upgradeable at the choice of the programmer. I think that's comparable to what Sam was saying enlightenment aims to do: abstact the presentation from the layout.
Alternatives? Well, I guess we can all run emulators so I can emulate Android on my Mac in order to run a tutorial specific to Android? Or we can obviously go to the browser for all the default presentation. Maybe that is what they are thinking?
posted by: stever 19-Feb-2015/9:57:25-8:00
Nick,
Is it just mythology that Carl wrote the VID/GUI of rebol2 as only a hack example of what dialecting can do and he expected others to quickly supercede his hack??
If that's basically true then I really, really don't understand why somebody didn't quickly clone VID/View for the open-source Rebol3? Or is it not true, and Carl actually spent years writing VID/View?
posted by: stever 19-Feb-2015/10:11:28-8:00
Traditionally, native GUIs have a better chance of accepted being accepted by development communities. Developers don't want users on a Mac, for example, to have menus which don't look or work the way they expect. There's a perception that something weird is going on inside apps that look and act different than native (maybe that is perceived as ghetto, but with the pervasiveness of the web, ad hoc interfaces are more acceptable recently, but those trends change periodically). So Doc is hoping to cover the native base first, so that the overwhelming majority of developers don't say "what is this" and immediately dismiss it as something odd (as many I think did with R2). As I mentioned, Doc has said that both methods will likely be supported eventually, hopefully using the same high level GUI code.
Enlightenment, and any other third party library, is just an unnecessary third party layer. Tools like that are useful in environments which do not provide any high level access to GUI features. Anyone can be free to implement a wrapper for it, for example if they're porting an app from another development environment in which all the Enlightenment code is already written, but there will be no need to do that once a full featured GUI system has been completed for Red. Note that Kaj already did a port of GTK+ for Red/system, along with a high level VID-like dialect to control it.
posted by: Nick 19-Feb-2015/10:31:42-8:00
In response to the second message above,
The changes in R3-GUI (which is an evolution of VID) were intended to fix some of the issues people had experienced building GUI apps with VID over the years. Cyphre did port R3-GUI to Android over the period of a few weeks, including hooking up the whole /View system, Draw, etc. to an entirely different rendering back end (i.e., he couldn't use AGG on Android). Quite a feat, which demonstrates just how nicely designed the whole rendering, /View, Draw, GUI system is.
posted by: Nick 19-Feb-2015/10:38:49-8:00
"...Sam, Have you expressed your thought to Doc or whoever is taking the lead on the GUI?..."
Yes I have and he thought I was insulting him. It was about using browser libraries though. I wasn't insulting him. Wouldn't even think of it. So I'm a little hesitant to mention it anymore. Don't want to be a troll or be perceived as one.
The only reason I mentioned Enlightenment was it can be tweaked in so many ways that the interface would look the same as the target. I feel that if they use the libraries GTK and Windows, etc. that they will never get completely done because it's a moving target. People with less skill could tweak Enlightenment files but very few can write what are essentially drivers to interface view like commands with the operating system. Doc will eventually get sick of Red and bit rot will bring the whole thing down. If there was a library with "...that is somewhere between Flash, PSD, SVG and HTML+CSS..." combined with some kind of GUI interface tweak program then the underlying base could stay the same and it could be skinned for each platform. Enlightenment has transparency, motion effects, all kinds of stuff and it's fairly old so it's lightweight. Eventually the Enlightenment library could be rewritten in Red. Of course I could be wrong.
Here's some themes. I really like the first one.
http://e17-stuff.org/content/preview.php?preview=1&id=158766&file1=158766-1.png&file2=&file3=&name=KL4K
http://e17-stuff.org/content/preview.php?preview=1&id=63394&file1=63394-1.jpg&file2=63394-2.jpg&file3=&name=itask+ng
http://e17-stuff.org/content/preview.php?preview=1&id=95258&file1=95258-1.jpg&file2=95258-2.jpeg&file3=95258-3.jpeg&name=A-New-Angelic-0.17.1
http://e17-stuff.org/content/preview.php?preview=2&id=108719&file1=108719-1.png&file2=108719-2.jpeg&file3=&name=A-BlingBling+0.17.1
http://e17-stuff.org/content/preview.php?preview=1&id=115796&file1=115796-1.jpg&file2=&file3=&name=A-18-White
More
http://e17-stuff.org/index.php?xsortmode=high&page=0&xcontentmode=39x7000x7010x7020x7030x7040x7041x7050x7060x7070x7080x7090x7100x7110x7120x7130x7140x7150x7200x7210
I'll stop commenting on this as I believe they've made up their minds and I'll just annoy them and Nick :).
posted by: Sam 19-Feb-2015/21:19:25-8:00
"Wow, well to Chinese standards not many I guess. " Why China?
posted by: Rex 20-Feb-2015/2:41:43-8:00
Does this mean Red will try to get popularity in China? But it seems that its official website is not accessible (or at least not stable) in some parts of that country.
posted by: Rex 20-Feb-2015/6:37:43-8:00
OK guys, let me chime in a bit:
- as Forks post is quite recent, I would like to add, that the error/exception subsystem is point of upcoming release. In fact, as for 0.5.1, all features are done, Doc is right now debugging error subsystem on the ARM backend. I expect the release being done in 2 weeks max. As for stability of Red, Andreas implemented Travis CI interface - it means, that each PR (pull request) is automatically being regression tested and marked as corrent, if everything is OK. This alone improves the quality of the whole process ...
- my prediction for Red vs R3 - if R3 does not get active lead, it will die off imo. It is open sourced for quite some time already, and if there would not be Atronix + Saphirion, porting View to Linux etc., we would see only some small additions. But everything is open - Red still has some serious way to go, before being feature complete with R3. Other R3 advantage might be, that it is C, so it might be more interesting option to the C/C++ guys
- as for Red being more R2 than R3. I am not sure. Doc is clever enough to take inspiration from both. I know that he did not use R3 much, but as for Parse implementation for e.g., it is definitely closer to R3. And remember - Doc plans on strong concurrency, something R2 nor R3 have, so - let's expect Red goint its own direction in certain areas
- GUI - Doc has already some prototype VID like system, working natively on Android and Windows. We should see it rather soon. After 0.5.1., most probably the priority is going to be shifted in favour of Redbin (as it will greatly help to reduce the compilation time), then goes Android bridge update plus GUI. IO will follow.
If anyone is interested, I am in charge of the Facebook Red group, where I try to inform about in between the releases small news, so feel free to join, if you are not anti FB oriented :-)
Best regards,
Petr
posted by: -pekr- 21-Feb-2015/12:26:58-8:00
@Rex,
Red's lead developer is in China for over half a year now. He founded a company now from... well read the blogs if you like.
@Stever,
if you try your script on try.rebol.nl first it save a lot of restarting the console. I find it ideal, even longer scripts can be run there.
posted by: iRonald 22-Feb-2015/10:56:22-8:00
Okay, I see. Hope his company runs well, but also hopes he will keep Red free and open-sourced.
posted by: Rex 26-Feb-2015/6:39:47-8:00
Most actual answer to your question, this will be 'never': https://github.com/red/red/issues/1076
posted by: iArnold 31-Mar-2015/15:22:33-7:00
|