Comments on: Making R3 a 3.0

Rebol R3 has been a working prototype for quite some time. It's actually quite functional, and it runs most of my website related scripts, so it's fairly reliable and stable for such things. It's the main Rebol language I use these days.

Overall, R3 is a much better design that R2. As a language, it's more robust and powerful. However, as a "system" it lacks many of the features developers use in R2. Most of these are related to how R3 interfaces to the outside world. For example, launching a program with CALL needs to work more like R2. There are various other examples.

So, for R3 to move forward, we need to split it up. There's the R3 "core" itself, and then there are all the special features on top of that.

To make R3 core a 3.0 is not a big task. One of the main jobs left to be done is to make sure that none of the natives or mezzanines include refinements that are unused or unwanted.

It is certainly fine to release 3.0, then add to it. But, we cannot release 3.0 and subtract anything from it. So, this is more of an inspection process of the current "API". Once it looks ok, I think we can label it 3.0 and move forward from there.

What would be next after 3.0? It depends on how you use R3... so everyone has a different idea. There are a few improvements that can be made to some of the native functions. For example, I'd like FIND to be a bit more powerful for simple searches, even though we know that PARSE can do almost anything. It's just handy to have FIND for simple programs. There are other functions in that category also. So, those changes will roll it forward to 3.0.1 and beyond, and with open source, it need not take a lot of time to do so.

In the bigger picture, "the roadmap", we've all got different goals. Personally, I really want to see graphics running on more devices, and as a result R3 GUI. For me, this is just a practical thing. I need to be able to quickly build GUI's for tools and projects. Rebol has always been optimal for that.

When I say "running on more devices" I really mean my Android phone and various little Linux processors like Raspberry Pi. I'd also like to see it displaying on DirectFB. Many embedded devices don't use X windows.

Another feature I'd like is a VID-to-HTML converter. That is, I'd like to be able to build web interfaces with the same easy that I use for building VID interfaces. It's quite doable, and perhaps there's already a program available?

All these things are useful to me. Of course, you might have other interests. Perhaps you want better integration with a database or web server, etc. Certainly, those are possible too, but you'll need to get organized and make them happen. I'd be glad to offer advice.

One other thing I should mention... I don't want R3 to be just a computer science project. It certainly has some interesting scientific features, but in the end it needs to be best at rapidly creating reliable software. We should focus on what makes R3 useful to most of us and not overdo it on features that may be conceptually/mathematically cool, but rarely used.

110 Comments

Comments:

MaxV 22-Jan-2013 1:27:13	Carl, I think that is better to know what will you do on Rebol and what not. Will you take care of graphic for the main OSes (Mac, Linux and Windows) or not? Please be clear about Rebol 3 future. Is there anything that you still want to publish about Rebol3 or not? (View, Graphic, audio, ...) This way community can organize itself. As you noted on GitHub community loves Rebol, but we feel stuck since we don't know what is your plan now. Moreover, you can avoid a lot of work to communiity if you publish View code (or a sketch or a guide), this way we know what path to follow for building the VID code infrastructure.
DideC 22-Jan-2013 1:57:27	To resume, there is 2 projects : "R3 Core" and "other features". 1) We need to precisely define what is "Core" level and what is "feature" level! Ie: in witch is bound HTTP, SMTP or POP schemes, images loader/saver... ? Then, "Core" development can be split in 2 sequences, "3.0" then "3.0+" : 2) We need to define precisely what must be done to finnish it and reach the 3.0 level. Witch function must be inspected/have been inspected. 3) We also need to define witch one must be enhanced/has been enhanced for 3.0+... Maybe it can be done in a wiki so you (Carl) and us (the community) can add to it and make it follow the developments progress. Some have point to Pivotaltracker for this kind of things. Anyway, we need to define the way to work with each other. 4) Then there is the big picture, the "features". Again, we need to list what belongs to this level. What is the best way to include the feature (scheme, media loader, functions...). We need modules here, so the module functions in "Core" must be finnished. Organize, organize! So how do we organize?!
Luis. 22-Jan-2013 2:24:43	To bring functionality up I would suggest getting the Schemes and the Datatypes sorted out for R3. That will make it a more useful base to start from. The GUI layer should be something that works from the ground up with as many systems without modification and map out how that will layer onto other technologies, such as HTML, SVG, OpenGL, etc. Will there be a need for an R3 'server' version to parse R3 to HTML? This should also apply to Audio, Gestures and other input methods. Should R3 be a two part system (or at least the option to be able to be split?): Would this make maintenance easier by keeping the Core separate to the Server? (If such an approach were to be undertaken). The 'Server' could be hosted on the device or run from a server, depending on needs/use. Barring device capabilities, R3 should be self contained and as platform independent as possible. That's what R2 promised and what R3 should deliver. Cheers, Luis.
DideC 22-Jan-2013 3:21:29	About tools to organize, there is already WIP wiki 3.0. I think, actually, only Carl can use it. But would it be difficult to open it to "some rank level" of DevBase/r3chat users? It probably need mechanism to manage versionning or concurent editing, but maybe it's already there? Carl tell us! So, the community, can start using it to : organize roadmap/feature list/devlopment progress. enhanced the content of the R3 documentation as many functions pages have no doc inside (ie: http://www.rebol.com/r3/docs/functions/reflect.html ).
Andreas 22-Jan-2013 4:13:32	Carl, thanks for the update on your current view of the way forward. (at) MaxV: "Moreover, you can avoid a lot of work to communiity if you publish View code" That /View code has already been published with the hostkits before. It's just a matter of taking those pieces from the hostkit and reintegrating them with the full open source codebase. There's absolutely no need to wait for Carl to do that or feel "stuck" regarding /View in any way.
Steven White 22-Jan-2013 6:25	This is another area where I am not qualified to comment (much), but I just came back from a week of C-sharp Visual Studio training, and now I am reading a cringely.com article about Apple with the comment of, "...as products and underlying technologies mature it becomes harder and harder to be obviously better," so I do have one thing to throw out. After all the organization of the various modules is finished, I hope I still can do with R3 what I can do with R2, namely, go to rebol.com, download it, and run it. That alone makes REBOL obviously better, in my opinion.
Nick 22-Jan-2013 6:38:39	Use R2 as a model for required features. Check off everything that can currently be done with R2, and R3 will be off to a great start. Add some built-in multimedia protocols and codecs (mp3, video, RTMP) and a few useful multi-platform multimedia functions like "capture-image". All the built in functions and protocols in R2 make it really attractive to new users. We have REBOL/Core, REBOL/View, REBOL/Command, Etc. REBOL/Multimedia would be a fantastic goal to attract the interest of new users.
Steven White 22-Jan-2013 6:55:19	Graphics on the clipboard.
AdrianS 22-Jan-2013 7:33:19	Carl, as we move to Rebol 3, could you clarify a couple of things for the community? One, will you make available the chat (devbase) server source? It looks like people are about to duplicate a significant amount of its functionality. Second, will you take into consideration the changes that have been done to R3-GUI by Saphirion (Robert Muench's company) and integrate them into what you intend to release, or will you stick with what you had originally released (i.e. will there be a branch in this GUI code right from the start)?
Carl Sassenrath 22-Jan-2013 10:00:38	First, I noticed the chat message that R3 is on Android now! That's excellent. Congratulations and thanks to Cyphre (and anyone else, if I missed some names, sorry.) I hope any necessary revisions will be posted to github for that. So... I see there are several other questions for me here. There's never a shortage on questions. Perhaps the most essential question is what will I be working on, and what would I expect to see from others, and how much of other projects would we integrate? I don't have the time right now to reply in detail, but I'll post more about it this weekend. However... what Andreas pointed out above is absolutely true: there's no reason to feel "stuck" regarding R3 code itself. You can make additions and submit them to github for others to try out, and for Andreas or others to integrate. Regarding forum and wiki, there are some good solutions for that, and they don't require a lot of work. But, more soon. And... please keep those ideas an suggestions coming. It's good to have this discussion.
Brian Hawley 22-Jan-2013 11:43:23	We need to cut down on what is considered core Rebol. The core should focus on stuff that is reasonably cross-platform. This will give us a clean base for our scripts, and makes for a useful limit on the work we need to do, so we aren't bogged down by featuritis. Everything beyond that can be developed separately as add-ons. Things that don't need to be in core: GUIs, though gob-level graphics support should be OK to include as long as it doesn't require the graphics subsystem on platforms that might not have that installed, like Windows, Linux or Unix. If the low-level support allows a GUI to be included on platforms that have GUIs, that would be a nice bonus. Clipboards, which may not exist on server platforms and many phone or embedded platforms. Since it's a scheme, it should be able to be defined in an extension, even if that extension is embedded. If that requires us to have device extensions to do this, then we should implement this in an extension on principle just to make sure that we can. Multimedia. Remember, "not in the core" doesn't mean "doesn't exist". For stuff that is actually core, we need to have a discussion of the low-level security model (binding visibility and modification) and tasking model. Even if we don't actually implement the tasking model, we need to have a plan for what intend to implement because it affects the semantic model of scripts and modules. And the protect and protect/hide security model needs a rethink because it isn't secure enough as-is, and would be too difficult to manage if the missing parts were added. Having the ability to make device extensions would also allow us to make more stuff external as well.
Scot 22-Jan-2013 18:31:22	The GUI is the place I always start. I agree that the R3/Core architecture does not need a GUI, but there needs to be a cross-platform R3/View that accompanies every distribution for platforms that support user interfaces. I think this includes a standard VID that with small screen displays and gestures and touch events for handheld devices as well as the more tradition View/VID we all know and love. I always design servers, services, networking and such after I have a good idea how the user will be interacting with technology, even when there are different apps and interfaces that use the same services. So without a GUI REBOL is pretty useless to me.
Fork 23-Jan-2013 1:16:28	No GUI in /Core. But there must be consensus on a /View repository, get it started as soon as possible with /Core as a sub-project. Consistent makefiles, and have the rebolsource build farm run GUI testing on pull requests so regressions caused by changes to core are detected. Remove user-exposed tasking objective from /Core. It's not a good practical goal in the scheme of things, and Rebol's main competitors don't really do this either. Leave it to Red and its desire to appeal to a wider audience, including systems-level programmers. Speaking of which: I think it's a top priority to engage Red strongly to ensure 100% compatible parsers. I'm talking about things like having the same definition of what are legal characters in WORD!. I am porting Red to R3--and while I won't claim I'm "almost done", I will say I've made significant progress. Red/System now builds a working hello.reds under both R3 and R2.
deglingo 23-Jan-2013 4:02:50	Isn't it annoying to have a CORE that doesn't handle multi-tasking/concurrency ? (compared to other langages) It can limit its adoption/usage. Lots of people won't even look at it for that reason. Concerning networking, does R3 include full proxy support right now ? Thanks.
-pekr- 23-Jan-2013 4:24:51	Deglingo - it is a long time ago, since I wrote down a suggestion, of what makes good beta. And you are right - R3 is not on par with R2 in that regard - the console is ugly, much less functional, CALL is semi-functional, and default R3 distro contains only http scheme IIRC. Some other schemes were dony by Graham, but not yet integrated, or via Curl binding. So imo yes, Core should contain all basic infrastructure functionality, including tasking in the longer horizont ...
tombon 23-Jan-2013 5:52:46	the core should be isolated completely from *any* scheme. then debug/finish all cross-platform features including tasks to make the core rock solid. all other features are better as individual embedded or external extensions, loadable from a central R3 extension repository like a linux packet-manager.
MaxV 23-Jan-2013 7:01:06	+1 for Fork, Fork, why don't you call your repository Rebol 3 united? It already has the rebol 3 wiki, and we can put all community ideas in it...
Andreas 23-Jan-2013 7:29:33	"No GUI in /Core." If we stick to R2-style products, then an "R3/Core" certainly won't have a GUI. "But there must be consensus on a /View repository" There is, already. The repository is rebol/r3 on Github. /Core and /View are just different build types (products), which we have come to know from R2. They are built from the same code base, so there's no need to separate /View (or any other set of configurable features) into its own repository. Think: "different make targets". And as I said before: most parts for a /View build are in fact already there, in the same repository as the rest of the open source code base.
Brian Hawley 23-Jan-2013 8:54:54	Fork, if we decide to remove task! from R3, which means going with a full process model for multitasking since multitasking is going to happen whether you want it to or not, then that affects the system model. If we are going to make that choice then we need to make that choice now even if we don't plan to implement that change now, because even that choice would affect the semantic model of modules and scripts. The current system model of R3 is built around managing the state of tasks. There are missing parts in the actual system implementation, but the module/script model is built around that plan. Most of the core differences between R2 and R3 come from this. The current model is that task! is a thread (currently an OS thread rather than a green thread), which means a shared process space with global and task-specific contexts, the need for synchronization (which we don't have yet), and concurrent running of globally defined functions with task-specific stacks (which we do have). Regular modules are (supposed to be) used to manage shared memory, and scripts are (supposed to be) run in task-local contexts (system/contexts/user is supposed to be task-local, and is treated as such, even though this is not yet implemented). If we switch to a green or full process model for multitasking then we would need to restructure the system around passing state between processes, maybe CSP or some other model. That would affect the way programs are written so thoroughly that it would almost be like switching languages. If we are going to choose to do that eventually, we are going to need to make that choice now so we can structure the system accordingly, so when we eventually implement it our users won't have to rewrite all of their scripts and modules. If you "remove user-exposed tasking" from /Core then that means going with the full process model of multitasking, since only some embedded systems aren't multitasking even when they're single core. That would need a different module/script/system model which we would need to start working on right away. As a downside, it would make it difficult to integrate into some operating systems like Windows (any recent version), Android, Haiku/BeOS, or anything designed for multi-core computers. A green/full process model with CSP works great for servers, but tends to not work well on resource-constrained clients - it's a trade-off. In any case, we can put off implementing the concurrency model, but we can't put off deciding it.
Fork 23-Jan-2013 13:10:54	BrianH: if much-heavier-than-Rebol Chrome can have a process per browser tab, then Rebol can certainly use a process per "task!" Can Rebol let OS-threads go?
oser 23-Jan-2013 13:23:22	Don't get confused between threads (r3 tasks) and processes. They serve different purposes. We will need both.
DideC 24-Jan-2013 0:47:34	task!: design choices have already been made, years ago. Usually, Carl does not make this choice without wondering deeply. And BrianH and others have already discussed this with him at this time, I guess. So I don't see the point to discussed it again! Fork: you jumped on the bandwagon, so you probably missed this discussion part. There so much other things to think about, is it really needed to rethink everything again and again?
MaxV 24-Jan-2013 3:47:01	I think that it's missing a public place to talk about Rebol, so I just created the: http://rebol.informe.com/portal.html It's a community about rebol, it has a forum, a blog, a WIKI and a Gallery. And it's free. Feel free to contact me to become moderators, administrators, editors... or posting your opinions about it.
Luis 24-Jan-2013 6:11:56	Scot +1 Concurrency issues need to be considered. If /Core and /View are separated then even more so, preferably without the need to affect /View. Akin to maintaining a /Core /View API. Cheers, Luis.
Brian Hawley 24-Jan-2013 9:25:09	Fork, one of the reasons Chrome is much heavier than Rebol is that process-per-tab architecture. And the reason it uses that architecture is to separate its tasks from each other, so interprocess communication is not as big of a problem. It makes sense to allow massive memory use when your goal is to safely run code that is actively trying to kill you. R3's tasks would be cooperating with each other more, so it would be better to compare to Go or Erlang if you are going with a shared-nothing approach. One notable downside of going that route is that we don't have a simple, efficient IPC mechanism yet. Another is that even when we would have IPC, that model would be more resource-intensive than a partial-sharing approach. CSP and other process approaches trade resources for stability, which is why they're used for servers more than clients. If we went that route, we'd be excluding ourselves from the most popular new platforms, which are all resource-constrained. DideC, the task! model is incomplete. The design decisions that we've made so far were made years ago, and Carl and I have already implemented most of the system model and module/script model around it, but we still need some help hammering out the remaining details. In particular, we really could use some input from Doc and Maxim, who weren't actively working on the project when we were working on this; their experience in such matters would be valuable. It would be nice if the existing model would work for us, once the details are thought through. It's not a bad model as far as we've been able to tell, and we have a lot of working or nearly working code written to implement it. However, if it turns out to be a bad approach for reasons we haven't foreseen, we'll just have to adjust and that's OK. If that's going to happen though, it is better for us to know sooner rather than later because a change in models would affect user code in significant ways.
Graham 24-Jan-2013 10:25:20	(at)Carl, it might speed things up if you were to consider releasing the source to any R2 components that you feel no longer have any commercial value. I believe you mentioned the console, and also odbc in the past. Maybe Fast-cgi.
Fork 24-Jan-2013 11:12:17	I've done a fair amount of work in parallelism. And honestly, I do not see the level of care and caution within the Rebol C sources to deal with the *countless* issues that multithreaded codebases have. The rigor is not there. I'm not saying this in a derogatory sense, I'm just saying that's clearly not what it was designed to do. Stepping beyond the C, there are mezzanine routines that just stick things onto the end of series temporarily...and then pull them off before returning. Trying to make that sort of stuff thread-safe is a wild goose chase, and does not play to Rebol's true strong suits. (Meanwhile Node.JS gains international fame...hanging by a single thread...) Code pages are read-only...loaded once and locked no matter how many instances you spawn. So how much does a new Rebol instance *really* cost? It's a messaging language after all...so your "IPC" is MOLD and LOAD. If Rebol were a person I'd say "just be yourself"...flaunt what you've got. I know the idea of Rebol on constrained devices is getting people excited right now. But shouldn't the focus be on dialects that expose the functions of that weird hardware conveniently? Why try to out-parallelize functional languages designed for that purpose?
Brian Hawley 24-Jan-2013 12:30:04	Fork, most of the mezz stuff is task-safe (don't know about the GUI stuff, and I haven't gone over the schemes). Stacks are task-local, so stack-rooted data structures are as well, as long as they're not referenced by multiple concurrent stacks or globals. The only stuff that isn't task-safe (that I've worked on) needs those missing parts to make it so, but can be changed easily once those exist. I don't know about the C sources (haven't checked) but I know of stuff that you can tell from external behavior doesn't work (error handling, for instance). Nonetheless, you're trying to judge the design solely based on an incomplete implementation, which doesn't include all of the design. It was not planned to have proper multitasking implemented by 3.0 - all we need at this point is to decide on the rest of the model. If we get it implemented by 3.0, that would be nice (if unexpected). The memory use of the stuff in the code pages is really minimal. Most of the runtime resource use is in mezzanine and other similar code, and the cost to construct that at start up is pretty significant too (though not at Java levels). Remember, only compiled native code goes into code pages, and read-only shared data pages won't have bindings because those are created at runtime. Code page sharing won't buy us much. And mold and load serialization doesn't cover enough of Rebol semantics, so we'd need another serialization syntax (not a big deal, we planned to do that eventually). Still, serialization and deserialization IPC will always have a lot of overhead that would need to be justified before we decide to go that route. If we did decide to switch to a process model then we would have to change the system model before R3, since the current system model is designed around tasks. We wouldn't need to actually implement the multi-process model before 3.0, just like we don't plan to actually implement the thread-like model the system design calls for now. But we would need to change the system and module model now, so that when we implement multi-processing/tasking later on we won't invalidate all R3 apps after 3.0 comes out. The current state of the C code doesn't really matter for the model, unless the model would require something that would be impossible to implement. We aren't going to implement the underlying code before 3.0, but we do need the system model designed around it to be in place before 3.0, so if there are going to be architectural problems that will be impossible to resolve eventually in our model, we need to know now so we can switch models. Glad to hear that you are familiar with parallelizing C code. That could come in handy. We still need some help from people familiar with parallelizing Rebol code though. We'd have to do the same work to make sure that the new async port model works too.
bitsoma 24-Jan-2013 13:03:35	Making R3 a 3.0 The most important thing imho is to have a central place that bundles the development. Where less experienced programmers can ask questions related to the current version, submit bug reports, make suggestions etc. Currently there's the source at githup, binaries at rebolsources.net, documentation (outdated?) at Rebol.com, you have Curecode, GoogleGroups, Altme worlds, chat and what not. Where to get involved? So working with the current Alpha I feel pretty helpless. When something doesn't seem to work I don't know whether it's not yet (fully) implemented, incomplete or a bug and I don't know where to ask and thus my (little) potential feedback is wasted. I am sure there are more people like me eager to help make 3.0.
shadwolf 24-Jan-2013 14:20:17	(at)Carl: First of all I would like to thank you to take the time to read my conserns and try to reply to some. CALL difference and lack of rafinements was exposed here http://www.digicamsoft.com/cgi-bin/rebelBB.cgi?thread=%3C8Jan2013134507148152100%3E To this I proposed a way in my eyes the call function should work. But it is just opening for reflexion and gathering ideas on a crucial point. I would like to bring more and more to the lack of functionality topic. But that can wait until r3 is 3.0 Too many questions is the best sign of the interrest we have in rebol and the importance we place in your opinions sir. You should start to worry when no more questions or rant will be done. R3 has to be 3.0 the faster possible. Thank your for your replies and concerns
Andreas 24-Jan-2013 15:28:32	(at)bitsoma: use whatever channel you like. if something doesn't work, you can directly go to curecode to look for yourself if what you discovered is already known. or you can just chat on altme, or google groups, or ... in most places helpful people hang out and will be happy to direct you further or at least know how to channel your feedback.
MaxV 25-Jan-2013 1:33:43	at bitosoma: try http://rebol.informe.com :-)
shadwolf 25-Jan-2013 6:45:07	(at)Carl: I like your vision of making VID dialect output adaptable. You know VID was, is, and will ever be my favorite part of rebol. And when it comes to VID what I would like it to be able to use VID everywhere obviously ! One thinking item to consider is that http://lunduke.com/?page_id=3454 illumination software creator is what could be rebol in a near futur the backend of ISC is python ...
shadwolf 25-Jan-2013 14:20:51	For the topic VID and portability maybe we should seek in the XML description of windows and widgets of libraries GTK+, QT, wxwindows. Instead of trying to integrate and shape rebol to handle libraries not made in the Keep it Simple spirit maybe the path to take for rebol specific ways is to do a VID output to XML adapted. but then we loose the best point in VID the draw dialect. VID is yet never achieve and seen anywhere else at the widget level but VID/draw AGG is uniq and so flexible that 3d video game or even video rendering could be writen based on a default face with a draw block. if flash can do that then VID can too... and way easyly.
shadwolf 26-Jan-2013 6:28:03	(at) BrianH: ... What? rebol isn't a ressource ogre? In what dimension is it a reality? ARE YOU KIDDING ME? Fact and truth are that you need in rebol2 25 Mo of memory to edit a 700 lines script with area-tc and the rendering is trimmed down artificially with the "I render only what you see" politic... the script weight the amazing weight of 256Ko and only in action rendering it cost 20Mo nothing else than 100 times is initial size !!! more you scroll up and down along your syntax colored text and more the memory is eaten. As for R3 do it have that behavior? I don't know after 3 years in the making there is no actual GUI able to allow me to write something similar to area-tc. But since the fact remains that it is impossible to easyly distinguish in rebol betwin a pointer and the raw data and avoid data endless replication in memory without thinking it hard and using linguistic tricks known by at most 4 people in rebol community (excluding me). And since it is impossible to free replicated memory easyly since recycle don't work because at some point the garbage collector still consider data to be used so it never free them. Is that the class of heavy thinking and heavy work you speak about? because if that is the point then sorry but it is to complitly rethink that system. A programmer needs to know where it's raw data are loaded and then to create only pointer to those data to not replicate that data in memory every time he needs to make a change. In the particular case I shown you and after some limited tracking with a debugger I could scope that what eaten memories was the drawn pages that where never kicked out from the memory since it is a rebol deep mechanism and since the user have no control upon that. the only way to have some control upon that black box and reduce memory waste would be to have a splited rendering engine one part should be a first script that prepare draw data write down a second script and load a subprocess with a whole new VM rebol which only goal is to actually paint in your screen the windows and its elements plus the draw instruction then captures input output notifies to the first scrip that some changes have been made and quit then the first script prepare again a second script with the draw instruction to be shown. I know it because I tryed it and from a 20Mo data use we have a stable 8Mo of data use. But it is a pain in the neck to see a windows flashing along our eyes each time we scroll the text or each time we insert a caracter... Sure you still can say I don't know how to program efficiently in rebol but neither you do and none of those Gurus of you took 5 minutes to write a high level memory management in rebol guide, to allow other people to reach the understanding of particular memory management rebol ways. Ressource memory management in rebol is exactly this: A blind guy since birth trying to understand the color concepts. My goal here is not to throw a tantrum but to show that yes for ponctual actions rebol is perfect. But for continous action rebol is not fantastic. This is a truth and it is so much true that at the server or service level like Cheyenne you have to split your server or service in tiny itty bitty actions that will work in async mode.
shadwolf 26-Jan-2013 6:28:37	lets take another concrete example, for the workI had to do a script generator to test if ip are alive and then write down a script in another language then run a software able to interprete that other language script lets say it is a macro. So I said hey I will do it in r3 !! Because I like it and it is 10 lines of code at most! But then here are the problems and you will see that it is ressource management related. And for the record that was with the official r3 2.111 version for linux 32bits and it was the past week. So first issue, I need to do a ping. R3 don't have an ICMP layer Why it doesn't have it? since 2002 I ask that question to this community noone ever dared to reply. SO I have to use call ! but call in r3 don't allow to store command results in memory so I use a file ! I did something like this call rejoin [ "ping -c1 " theip " > ipout.txt". Then to analyse the result of that command I have to read the file ipout.txt and analyse its content with a neat parse wrapper called find. Then I have to store in memory the adapted to my ip alive bunch of macro script and there is what emerge in my brain. If I store in the same memory location the assembly of macro bunch from A to D in a consecutives call then my memory will look like this A + (A B) + (A B C) + (A B C D) so A bunch will exists 4 times in physical memory B three time, C two time and D one time ! SO I choosed to write down to a file each bunch after creation (slow poke rules) therefor I got in memory only A then B then C then D each existing one time in their physicall memory bubles. So in conclusion (yes!! at least he gets to the point) that tiny rebol scipt of 5 lines and 4 concrete actions is slow because it has to constantly deal with the hard drive to avoid the memory ogre mechanism ! this is a perfect example of ressources waste.
shadwolf 26-Jan-2013 7:02:42	the concatenate would have been to do a thing like that: myscript: "" myscript: rejoin [ myscript " the macro " newip " the macro " newip " then last part of the macro"] In order to write down the resulting string! in myscript variable to a file. this makes me think that I hate join and rejoin and that I prefere the shell way of having one string! and embeded the variables in it like myscript: "some text $ip some more text $ip text to the end" or something like that I m not found of this neither myscript: "some text" + ip + "some more text" + ip + "text etc end" and obvously this is not cool: char * myscript; char *ip; myscript = strcat ("some text", ip); myscript = strcat (myscript, "some text"); myscript = strcat (myscript, ip ); myscript = strcat (myscript, "some more text");
shadwolf 26-Jan-2013 7:17:02	last thing is why in rebol I need memory management and not in shellscript? shellscript are based on the run then die ideology so it is obvious I don 't care about memory waste in that mind set. but rebol allows me to do more than what a shell script can do and therefore I need strict memory control. how is the memory control in perl, tcl/tk, python, ruby, ? well its a mess but is it because the others have a bad way to do that you have to try to mimic them trying to make better a phylosophy that is bad? not telling that you that those other language or don't do GUI layer or delegate to heavy graphical libs that duty (which in genral are writen in C with destructive capabilities like get_destroy(*GTK_WIDGET) for example. So python etc don't really manage the memory in harsh way but the GUI external part does. is this applicable to VID I don't know... but at some point I would like that if I change the color of a button it doesn t mean that the button of the previous color remains in a memory bubble waiting for the garbage collector to notice it and blow it ... if a change the color of a button a thousand time because I want to do a blinking effect I don't want a thousant buttons of the same colors to exists in their memory bubles along with their bitmap result to be displayed on screen.)
shadwolf 26-Jan-2013 7:40:44	lets retake my example of the macro genrator what I would have liked to achive for the A to D bunch concat would have been finalscrip: [] myscript: rejoin [ "text 1" ip "text 2"] append finalscript clone myscript ; after that point myscript physically exists twice in memory free myscript ; only the instance of myscript cloned to finalscript still exists so we repeat this X time and finally to write down the file with the successive shapes of myscript I do a forall finalscript [ write/append %macro_file.txt ] ; then do I care to free finalscript from memory ? hum nope since after that the script end the vm r3 close and the OS does the work of freeing the memory that finalscript was wasting :)) in my view I use a block to store the concecutive script bunch because I see it as an implicite chained list where every new element is added without replicating the past elements which will not be the case if I was working with a string!. So in the end in memory I have ( (a) (b) (c) (d)) and not (a) (ab) (abc) (abcd)
shadwolf 26-Jan-2013 7:49:31	(at) bitsoma: initially it was the role of altme... and others forums. the everyone focused on altme then the community died, so noone cared about forms or altme or rebol anymore and now we are in a renewal era. and we try to avoid repeating the same errors that led to easyly of having only 5 people actively interrested in rebol. On the memory management topic one thing amaze me is that the specialists of that area that made GC in python, ruby, etc os and spend years of their life trying to write a coherent and consistant predictive garbage collecting system never gathered to exchange point of views or never tryed to look at how rebol handle things to comment it. It's like having brain surgeons that works on their own surgery without never doing conference to expose their discoveries... Weird..
shadwolf 26-Jan-2013 7:57:51	can a predictive system be more efficient than "destroy that bunch of data in memory because I know what I do" ? Well if you are a microsft coder writing windows 98 usb interface I would say hum ... nope! but are we intended to write an OS able to handle hotplug in rebol? it appears to me that the main reason the garbage collection is so weak when it comes to the GUI layer is that GUI has that circular nature (event loop where drawing elements to the screen is just one aspect of that loop). So in that area you can understand that destroying to fast a data can lead to a segfault.
Shadwolf 26-Jan-2013 8:16:59	to illustrate the loop event leading to segfault lets take an example. a user clic 3 times on the next button of a form that button is supposed to provoke the store of the collected data and then destroy the widgets displayed in the form then draw the in their place the next set of widgets. there is in the event pile 3 click button action the button is part of the set of widget to be destroy. the event loop take the first click event of that button and relate it to a callback to be executed. Then what happends to the next click event still in the event pile. Well since the button that emited that event is gone and since the event loop needs to have a source widget to find the related callback and since that source widget is gone bang ! program crash ! of course you can say what dumb guys if a widget is destroy then all the events of that widgets have to be cleared from the event stack... Or they have to limit that button to emit only one event! Ok but if in the mean time the event was redraw the button that you just happend to destroy because this wasn't a source widget event but a target widget event? hehehe...
Brian Hawley 26-Jan-2013 8:39:27	Shad, pardon the brevity of my answers, we're getting out of my areas of interest and into the stuff I just remember. Others can answer in more detail. Graphics and overhead: R3's graphics model was completely redesigned back in 2008 specifically to solve issues like the ones you mention. The gob! model deals with most of the memory issues, by replacing most faces (heavy-weight Rebol objects) with gobs (tiny native structures). Most things that needed to be faces in R2 simply don't in R3. Also, the face/style model was redesigned to get rid of those rebound functions that were created with every face, the source of that overhead, so the remaining faces aren't as heavy-weight. And there's a built-in native rich-text gob type which might cut down on most of what area-tc has to do, though I wouldn't be able to tell you how well it works. The R3 GUI built on this model has been refined over the years by the Cyphre and the rest of the Saphiron guys, and they say it's pretty enterprise-ready. I haven't used it since I don't do GUI stuff, but they're already selling products written with it. Memory management: For the non-graphical, mezzanine-level stuff I do, I actually do know how to implement things efficiently. I even made sure to promote language features to lower overhead, such as the /into option, apply, expanded select support, rebalanced none propagation, ajoin and more. We even got some of this backported to R2. For lowering graphics overhead, I'd prefer that Maxim and Cyphre do it, since that hasn't been my area. String joining and interpolation: I tend to use ajoin for concatenation, it's more efficient than join and rejoin. But if you want interpolation, try reword - we would love some usability feedback on it. It's mezzanine now, but once we get a consensus on the API we can make it native to make it more efficient. ICMP: What part of "alpha" are you having trouble understanding? We didn't need ICMP when we were (and still are) in the development phase. If you're going to criticize R3's networking, start with HTTP, which we actually did need during development. Or better yet, look over the code. Native stuff (that's what the rest of your complaints were about): We're working on it. We weren't able to work on core bugs before, only Carl could, but there was only so much Carl to go around and he had design issues to deal with. The external stuff like the GUI and mezzanines have been more thoroughly refined because we could work on that stuff, so they're in much better shape. Now that R3 is open source, we've been fixing native bugs rather quickly. Still more work to do! From what I gather from Maxim's stories, doing GUI stuff in R2 efficiently can be rough. I'm sorry to hear it's caused you so much pain. Hopefully R3 will be better for you.
Scot 26-Jan-2013 14:11:35	I become seriously concerned when people suggest changing the task! model of Rebol. Carl invented task interrupt multitasking. With it he created a full functional multitasking multiprocessor OS in 1984 that ran comfortably in 256K memory. The fundamental architecture of REBOL is a far more advanced version of those ideas. Changing task! means it is no longer Rebol, and no longer the work of Carl. The worst consequence of open sourcing Rebol would be the desire to be like everybody else driving our development decisions. Rebol makes a difference precisely because it is soooo different, in the most practical ways. The influence of Rebol is everywhere from JSON to DSLs to event driven architectures. But nobody else has it all in one place. My approach with Rebol can be summarized like this: "If I can do it easily in Rebol it means I understand the problem and how Rebol addresses the problem. If it becomes hard it I assume that I a) don't understand the problem well enough b) I don't understand how Rebol addresses the problem c) I don't understand Rebol well enough. So rarely has the problem been with Rebol itself that I assume the problem to lie with me. I can trust Rebol in a way that I can trust no other architecture. Being like everybody else means living with a ton of things that don't work and are not consistent in their design and implementation. It is also why I am never in favor of open source. Since we have already jumped off that cliff, I suggest that we focus our attention on building a technology that is so different, so powerful, and so useful that everyone wants to emulate it.
Andreas 26-Jan-2013 17:09:58	(at)shadwolf: "R3 don't have an ICMP layer Why it doesn't have it? since 2002 I ask that question to this community noone ever dared to reply." The answer was and always will be the same: 1. Nobody has implemented it. 2. Even if someone did, you probably wouldn't find it useful. But maybe a single line of Unix permissions tells more than a thousand words: $ ls -lah `which ping` -rwxr-xr-x 1 root root 40K Nov 26 17:22 /usr/bin/ping
Andreas 26-Jan-2013 17:17:13	PS: With R3, we are now of course free to implement an ICMP scheme. Maybe you want to do that and share with the community (both the implementation, and your experiences whether you actually found it useful for your purposes).
Andreas 26-Jan-2013 19:33:42	Bah, shouldn't post anymore when I botch even the simplest things thereby completely destroying the point I was trying to make. That's what you get by blindly copy/pasting from a capabilities-enabled system. So let's try again, with output from a more typical system: $ ls -lah `which ping` -rwsr-xr-x 1 root root 35K Nov 8 2011 /bin/ping
shadwolf 28-Jan-2013 13:21:13	BrianH thank you for your reply. The ICMP protocol topic is a old topic I asked in 2002 in rebol 2.X and that no one ever consider as usefull for rebol. I know too well that r3 is in alpha ... but still there is no plan to consider ICMP as a futur addition. Which leads to the need to use external tools if any is available. Which result only can be store at the shell level into a file with I/O redirections if any available. My point is maybe instead of spending ton of man hours trying to make Call a better thing linked with task! module it would be faster to insert icmp capabilities in rebol that would give a result we could store in rebol memory and manage as usual... CAll needs to be a better thing sure but before that maybe of some I.T regular stuff like monitoring etc we could have use of a ICMP layer. Andreas ... hum as state if you have to check if your network is alive and that network have a hundred machines then systematically calling ping and storing its result into a file and then reading that result file to interprete it and decide the action to be done slows alot rebol.. when I says a lot it means a task that should take less than a minutes takes like 4 minutes to complete. Andreas ok and what guarantee I have my work will be retaken into rebol official? If I spend time on stuff and take time to publish them I suppose that it will interrest more than me. Andreas it is not because I watch the TV that I want to be in it :). First of all I have absolutly no idea of where I should start that kind of work. how to make it rebolish enought to be usefull. Andreas but sure I should propose writing ICMP layer as a small project to understand and document "how to add something to rebol in a rebolish way". Not sure though I will get any support of any kind. Thank you for pointing to reword I will try it. Bryan for the GUI and I haven t told yet about the font rendering in rebol 2 which was a true nightmare.... :)
Brian Hawley 28-Jan-2013 14:30:57	You might consider trying to implement ICMP in an extension. This isn't R2 - you don't have to implement everything in the core. As Andreas said (I think), on many platforms you have to have root or admin privileges to use ICMP directly, though some let you just call the ping command if you're not root. Given that and how rare it is that people would need it, this seems like a good candidate for external code. Just make sure that the extension can be included in the host if necessary. I've heard stories about R2 font rendering, with problems on non-Windows platforms, or on Windows for that matter when you have ClearType turned on. You can see it in AltME (the only Rebol GUI app I use regularly anymore). Hopefully R3 can be improved in that respect.
-pekr- 28-Jan-2013 23:46:24	Shadwolf, back at those times, as far as I remember, RT refused to add ICMP protocol, because it could be considered a security issue by some ppl judging the tool. Well, generally I am not against adding it, working with Wireshark, I would even add working with ethernet frames :-) As for calling external lib or using CALL, I am not sure it is necessarily much slower, than having it included. But - generally there does not seem to be much consensus on adding ICMP. So you either do it yourself, or you sponsor development. I do the latter, as I am not skilled developer, so I sponsor Red, and I also donated to R3 and R3 GUI projects. Maybe we need some bounty system, where ppl could submit some amount of money to certain feautureset?
Kaj 30-Jan-2013 5:50:23	Scot, I understand your feelings, but Carl did not invent multitasking. What he did was bring it from mainframes to home computers. Also, Amiga OS now has a rewritten kernel that supports SMP as far as the Amiga API allows it, but the original Amiga kernel written by Carl was not multi-processor, and ever since, the API design blocked implementing it. A similar thing goes for REBOL. REBOL 1 and 2 were not multitasking at all, and the design, especially of functions, prevented implementing it. Even the implementation of asynchronous I/O was so problematic that it failed. Only in R3 is there a new design that should be prepared for multitasking, but it hasn't been implemented yet, so we don't know how well it would work.
MaxV 1-Feb-2013 4:14:48	http://rebol2.blogspot.it/2013/01/community-portal.html
shadwolf 2-Feb-2013 14:06:55	Kaj on the multi tasking topic back in 2004 when uniserv was done and rebservice stuff was the hot topic Carl made pretty clear he disliked multitasking though using multi-threads. He said something like thread are a lame limited design made for dummies that have no imagination. I think Carl even made post here to explain his position on async process.
shadwolf 2-Feb-2013 14:16:51	http://www.rebol.com/article/0050.html for the async port pledge
shadwolf 2-Feb-2013 15:05:14	for the icmp protocol http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/net/ipv4/icmp.c piece of cake isn't it? ... how we integrate that in rebol and how to transform the use of this in a rebol coherent dialect? Saying "just do it!" is the sign of your impossibility to do it yourself... I prefer saying "I don 't know how to do it neither you do but together we can acheive it!"...
Brian Hawley 2-Feb-2013 17:13:41	Shad, it's not a good bet that the people here who have been saying "just do it" aren't able to do this themselves. It's a much better bet that they (we? I don't know if I was included) don't need such functionality ourselves, and thus it's not worth it for us to work on it. Insulting people is not a good way to get them to help you, especially on something that that you need and they don't.
CCX 2-Feb-2013 20:23:30	>>trim " x ^/" == "x x^/" My (first) grain in clearing the alpha stigma. I fixed this trim bug! Lets see if my github's pull request passes...
shadwolf 7-Feb-2013 11:21:45	BrianH you see insults where there is none. Saying you don t do something because you don t know how to do it is not something you should be shamefull. By the way I have no idea how to integrate ICMP into rebol the rebolish way and I m don't feel insulted the least... So in one hand we have those who could do it because they know how to do it, but won't do it because they don't see any interrest in it. And in the other hand we have those who have interrest in that functionality, that would galdly spend some hours implementing it, but don't know how to proceed. So how we get out that lock ? My proposition is that those that knows how to do use a concrete example like ICMP for example and gather with the motivated people that need that feature to write an complete proceedure on how concretly add a new feature to rebol. How to trim down the C code for the feature? How to insert it in r3 ? How to make it portable? How to make it a mezzanine rebol dialect that you can use from your rebol script and which result will feat hour needs? this is what anyone pretending to add things to rebol will have to know... communication language without being able to distinguish from a service faillure and a machine faillure I don't know what class of messaging language rebol is. not having use of it .... ICMP is the best way to know if your rebol app is stuck because it crashed or if it is stuck because the hardware failled somewhere betwin you and your server. sure you always can use external tools but then you make rebol impossible But probably staying put in our corners trying to know who insults who is a better occupation.
shadwolf 7-Feb-2013 11:33:15	CCX -> Well done ! Congratulations!
Nick 11-Feb-2013 12:40:03	Carl, Have you considered selling a port of R2 to Android and Apple iOS? I'd be really happy to pay for that, and I bet there are others...
Steven White 12-Feb-2013 8:31:21	It might be fun if things could be set up in such a way that an ordinary person could program his own tablet without hosing up the system; in a sandbox so to speak. By "ordinary," I mean someone programming in REBOL and running his own program on his own device, not someone programming in Objective C who can run his own program on his own device only by going through the some app store. And then ultimately we would want Carl to get a royalty for every tablet sold.
MaxV 13-Feb-2013 3:04:14	http://rebol2.blogspot.it/2013/02/rebol3-is-dead-long-live-to-rebol3bazaar.html
bitsoma 14-Feb-2013 0:05:36	(at) MaxV: Exactly, I can only agree. Judging from the activity on rebol/r3 · GitHub, CureCode and Rebol GoogleGroups it looks like R3 is pretty much dead (I don't know what's happening on AltMe though), I am sad to say. Maybe a central official place can resurrect interest.
Andreas 14-Feb-2013 5:13:11	(at)bitsoma: I'd say it is far from dead, but YMMV. (I'm sorry that we couldn't help you with your 1&1-related crash so far.) If you wanna chat, we'd be more than happy to see you around on SO Chat: http://chat.stackoverflow.com/rooms/291/rebol-and-red If you feel more comfortable with good old email, fire away at the Google Groups mailing list. Just because there's currently little activity on the mailing list, that doesn't mean that there won't be many people listening in there, happy to help you with problems or questions.
bitsoma 14-Feb-2013 11:02:37	(at) Andreas: Actually I didn't expect the crash to be fixed any time soon. That's not the problem. The lack of visible activity with R3 is my concern. Once again there should be a central place to access all R3 activity from. Currently I am not aware of any such place. R3 chat on SO is yet another channel.
Steven White 14-Feb-2013 12:57:23	I suppose that things are different with Carl out of active development. In the past we thought that some activity might be taking place because we figured Carl was working on it. Now we know for sure that he is not, so it's theoretically possible that nobody is. Therefore, it would be nice if anybody who is working on anything would announce that he is doing so. For example, if someone is working on VID and announced it, then we would have some hope that at some point we would have R3/View. Without an announcement, then for all anyone knows, VID will NEVER exist and we should move on to some other language. Is it the plan that Carl will review developments to keep R3 in line with his vision? Would there be any benefit in him directing development in some way? As a casual R2 user, I would not expect to be "kept in the loop" on anything, but, as a casual user I do have an interest in knowing if R2 is the end of the line, or if at some point I will be happily porting my applications to R3.
Andreas 14-Feb-2013 14:19:11	(at)bitsoma: Understood. R3-related activity I know of is currently happening mainly across 4 channels: GitHub, CureCode, AltME, and SO Chat. A group of people interested in R3 (myself included) are working on unifying the community efforts we know of under a common umbrella. This won't happen over night, but we sure hope it will happen. If you want to participate or stay in the loop, SO Chat is a good (but quite active) place to start. If you want a little more quiet and structure, I fear jumping through the hoops to get on AltME is currently the best bet. (at)Steven White: R3/View already exists; as does R3-GUI, a VID-inspired GUI framework for R3. Both are available from Saphirion's Rebol pages at http://development.saphirion.com/. The plan is to re-integrate the GUI stuff into mainline as well. Will also take a bit of time, but first efforts in that direction are already underway. "Is it the plan that Carl will review developments to keep R3 in line with his vision? Would there be any benefit in him directing development in some way?" Only Carl can speak to that (and you can review his previous statements regarding the above right here on this blog). Carl's (directing) involvement would certainly be beneficial, but it's a decision (and, more importantly, commitment) Carl has to make, we cannot make it for him.
Arnold 15-Feb-2013 1:23:47	With Red development I can assure that there is a lot going on. The website may not show that to the passer-by. Adding stuff to the website costs time too, and in the case of Red I know that that time is now spent on the development itself. Each time I see the website updated I have this mixed feeling about that :) For R3 development it would be something if the source maintainers got an introduction on this blog and the development is shown off to the public. Personally, if it was not for Red, I would have given up on R2 and R3 by now.
Nick 19-Feb-2013 20:03:37	R3 work by Saphirion is the thing to watch, along with Red. R3 console is already working on Android OS, and they are moving towards delivering a full GUI for Android soon. Once that's done, porting to other operating systems will be easier. It may appear quiet, but key people are making progress. Let them spend their precious time working, instead of fighting flame wars online. The REBOL community has been very quite for the past 1.5 years, and no one seems to have much interest in preaching to outsiders. If you really want to keep up, using AltME is necessary.
-pekr- 20-Feb-2013 3:25:52	Or StackOverflow Chat, but you need to raise 20 points in order to be able to chat - http://chat.stackoverflow.com/rooms/291/rebol-and-red
MaxV 21-Feb-2013 5:10:28	http://rebol2.blogspot.it/2013/02/rebol-3-bazaar-evolution.html Thank you all for your support.
Luis. 25-Feb-2013 3:59:48	If they don't fight the flames, people will just drift away and leave. Cheers, Luis.
shadwolf 25-Feb-2013 18:18:08	(at)Nick unfortunatly I think you are passing through another one very, very, long, classic tunnel where Carl totally lost receptions on his antenas... R3gui spahirion ... amazing sorry I doubt they can do that and truely they proven me right those past years. the whole actual r3gui is based on carl initial work which is a deadend since not portable... (at) MaxV your fork have this great quality already it is not saphirion :). best luck best wish I will prob contribute to it in a way someday.
shadwolf 25-Feb-2013 18:23:26	(at) Nick: if you take the rebol community in it's 2003 form which involved more than 300 people active. rebol community has been quiet since 2006 which is the moment we see a big lost of interrest in rebol. We always see around the bunch of 30 people and some time one old fan drop by to see if the song is better... as for r3gui saphirion ... portability will not be brought by them it is clear. they will not achieve to port it because they have a too narrow view.
shadwolf 25-Feb-2013 18:32:44	(at) steeve white: sir, I m sorry but carl lacking implication was highly predictable. That was why we tryed so hard to convince him to change his licence. that is why we trust more in forks than in r3 master branch. Will carl integrate and lead the r3 master branch to make it on pare with the new things on the forks? I doubt it ... /me takes his crystal ball so please has it is a rare moment of pure happyness take good notes. Eventually in 3 to 4 years carl will reboot rebol project doing a R4 that will be his master piece.
shadwolf 25-Feb-2013 18:44:31	(at) Louis: I know too much this ommunity to know that all the effort on R" will sease the split second Carl will announce another reboot of rebol in the form of a mix rebol2 / rebol3 which will be rebol 4. rebol 3 never get out or alpha stage .. and the plan to do a rebol 3.0 is quite simplistic... "DO IT YOURSELF AND STFU" It lacks my interest... first because I don't consider R2 deprecated and borring ... R3 is like a rebol2 extrem lite version. It is not flamme it is commenting what I see and judging what happends having in mind the long history of rebol
-perk- 26-Feb-2013 2:12:24	Shadwolf, you better start to live some reality :-) As for Carl, you are most probably absolutly right. But as for Saphirion or other folks, you sound like a broken machine. While you rant, Cyphre is doing nice progress on Android, and the GUI is coming. As for their GUI being based upon Carl's work - who cares, if it actually works? Why don't you just join e.g. StackOverflow, all participate on the forks? It is now open-source, which means, you are getting for free, you are giving for free. As I can't code myself, I at least sponsor Red. There is so much roles, and so much of work needed, so while you just don't join us on any front? And really - don't expect Carl coming with REBOL4.
--- 26-Feb-2013 22:19:32	Does anybody besides Mr. Carl Sassenrath (apparently M.I.A.) have the authority to accept/merge pull requests? Updates have piled up at github/rebol/r3 for 2 months! Kind of depressing... Maybe its time for the curecode guy and the other active developers to part from Carl and begin FreeREBOL. Mr. Sasserath stated he would not be much active. Thanks for the source code, but, Hey! It feels like waiting for him is strangling the community effort.
Brian Hawley 27-Feb-2013 20:17:32	In response to the above question: Sure, everyone. We're using a distributed version control system, not a centralized one. Anyone can fork and merge to their heart's content. We haven't been blocked by those pull requests not being merged in that particular repo. Development continues, and there's a lot of it. We mostly put the pull requests in the rebol/r3 repo to make them available to the community and to get community feedback - we have a lot of smart people, not just Carl. It seems like a nice place to have these discussions. When Carl reviews them and puts his own opinions in, he can merge, but we resolve a lot of the potential problems before he even has to chime in. And it's not like there's anything blocking any qualified person from doing their own merges in their own repos. We don't want to put everything on Carl, or any one person, because that's how the old project failed. Instead, we have a lot of people working on this; perhaps you've seen some of them posting. We like Carl, we value his insight, and we value his code, but we're not waiting for him. That would be a bad way to make use of community resources, and Carl for that matter. It's better when he's around because he's exceedingly good at this stuff, but we're not stopping in any way on those occasions when he's not. Synchronous development processes are overrated. We don't need a "FreeREBOL", it's already free. Didn't you catch the open source announcement, or the Github publishing? I do new R3 builds fairly often, and so can you.
--- 28-Feb-2013 19:39:20	Brian Hawley, Thanks for taking time to reply to my concerns. I see your point about REBOL being free. "Anyone can fork and merge to their heart's content." I agree. But here is what bugs me... try answering these questions: Where can I get an official, cured, up-to-date version of the REBOL source code with all valid pull requests merged and all invalid pull requests purged? Who does review and decide if a pull request is valid or invalid? (Mr. Sassenrath decides?) Where is that cured up-to-date repo? I may be wrong, but I cannot find any cured up-to-date repo of REBOL. As I see it, everybody is forced to review and decide about all pull request before merging. That cannot be good. (You don't blindly merge unreviewed updates, do you?) I'm not trying to start a war, but nothing seems official (reviewed and declared as valid or invalid) until Mr. Sassenrath says it is, and stamps his click-of-approval on a pull request. Maybe having one central, community cured, up-to-date repo is not that bad idea after all.
bitsoma 28-Feb-2013 23:55:13	(at)--- exactly!
Chcken Little 1-Mar-2013 2:43:42	Now - Rebol: Putting the "f" "u" in "disfunctional" languages... Future? - Rebol: Putting the "fun" in "functional" languages... Let's hope for the future!
Brian Hawley 1-Mar-2013 14:24:41	Well ---, please don't take any of this in offence, but R3 has never been a one-man project. On the previous semi-closed-source R3 project I was the main official reviewer, along with Ladislav handling most of the tricky numeric stuff. Ladislav, earl (his name is Andreas), Cyphre, Henrik and I (and some others) have been working on the open portions of the codebase since 2007. We had the role before of reviewing things so Carl didn't have to do as much work, and we are still doing that in the new project - perhaps you've seen our posts. I know that to many people new to R3 it can look like it sprang forth fully grown from Carl like Athena from the head of Zeus, but R3 has been a collaborative community project nearly from the start. Carl had the vision, and did most but not all of the closed-source work, but he wasn't alone in this endeavor. Most of the mezzanine code was written or rewritten by other people. Most of the design changes were the result of a lot of community debate and consensus, including the changes we're implementing right now. For that matter, most of the bugs we're fixing right now have been on the list for a long time, and the behavior in the fixes was also decided by community consensus and reviewers who followed Carl's vision. So you might be a little off in thinking that only Carl's opinion is "official", but (not knowing your name) it could be understandable. No offence taken :) Otherwise, good point. We need a central place to have these community discussions and expert reviews. As we said above, we're working on it.
--- 1-Mar-2013 16:34:14	Well, that explains a lot, thanks for the background info Brian Hawley. (I'm new to github and the REBOL community.) Then the reason why there is no central, cured, up-to-date repository is because you (Brian Hawley, Ladislav, Earl, Cyphre and [?] HostileFork) trust each other. No need for reviews or a central repo. You just merge into your personals' repo. But for an outsider that is not evident. I think it would be a lot easier for outsiders if there was one official up-to-date source code branch. Why not the Master Branch itself? If you 5 are so close, ask Mr. Sassenrath for the github privileges. •CCX•
Brian Hawley 2-Mar-2013 18:42:04	Now we're on the same page CCX. More than you think, since most of us are new to Github too (me especially). And that, more than trust, is the problem we have here. Over the course of the R3 project we have adapted to some excellent development processes and tools, and there is a lot of information that those tools have already accumulated. Adapting to new (to us) tools like git and Github is taking a bit of time, and more importantly adapting those tools to our needs is taking a bit of time too. And while many of us use Rebol in our day jobs, there aren't many of us for whom developing R3 itself is our day job (yet). So, we're setting things up but it's not an instant process. Even given that, you are overestimating how much trust is a factor here. A more central factor is tests. We have a test suite that we are improving all the time, and which we test against new builds. As we find more bugs we add them to the tests, often before we do the bug fixes. And we have people reviewing the tests to make sure that they are testing for what they should be - they're curated. On the other hand, the new tools like Github give us some advantages. One of the most important advantages is that we don't have to be any more centralized than we need to be to get the job done. Since we don't have to have one central repo, we can evaluate other options. There are some advantages to having the official repo not be the central repo, to having more than one center. Being new to the Rebol community, you might not know how thoroughly we debate the finer points of its syntax and semantics, to make sure that what we make is the best solution, the most optimal, the most Rebol-like. These debates are mostly philosophical and pragmatic, and can get fairly involved. Part of the advantage of our community so far has been the extent to which we disagree, because when people as opposite in views as Ladislav, Fork and myself manage to come to a consensus through logical argument, it often ends up being a better solution than anyone would have come up with on their own. It's not trust, it's logic. We need a central, neutral place to build that consensus, to try out different approaches and see which one wins, to argue and be ruthless in our cuts. But the "official" repo may not be the best place for that, because pre-consensus code and debates can be a bit of a mess. It can be a good idea to keep the official repo a bit cleaner, to only get code after it's been rigorously tested and screened. This implies that a two-center solution might be better, rebolsource/r3 as the community center, and rebol/r3 for the clean official code. That would make it easier for Carl to review stuff too, if others resolve differences before it even touches the pull request list of rebol/r3. We need to not screw this up though. Slight delays are nothing compared to messing up setting up the community site. And that is why it isn't there already. We need to, among other things, get the link between CureCode and Github issues working, because most of the project info could be lost in the transition otherwise. There have been some advantages to switching to new tools, but if the switch causes a massive setback then we might as well just give up on them. We have a lot of momentum, we don't want to lose that. Rebol 3 is a work in process, as the subject of this blog post would imply. We are trying to get through the last of the major design discussions and get them implemented before 3.0 goes final. Anyone can get involved, The main advantage that the people I've mentioned have is how far we are into the discussion. It's not privileges, it's knowledge, and anyone can get more of that and join in on the fun. Does that make the situation more clear?
-pekr- 4-Mar-2013 0:42:35	Carl seems to be alive with some plans for R3 continuation again - https://github.com/rebol/r3/issues/96
--- 6-Mar-2013 18:47	Thanks Brian Hawley, it is good to know what is being tried to achieve. The rebolsource/r3 vs. rebol/r3 idea makes a lot of sense. I know some of these things take time... I just hope it doesn't take years. •CCX•
jasonic 10-Mar-2013 14:32:54	"What would be next after 3.0?" First take a good long look at Clojure ..then try to deliver an R3-LightTable, what I always hoped R2+VID would naturally become {perhaps talk with Chris Granger ?} http://www.chris-granger.com/ 'LightTable' presentation http://vimeo.com/40281991 http://www.kickstarter.com/projects/ibdknox/light-table
MaxV 19-Mar-2013 8:03:41	http://rebol2.blogspot.it/2013/03/rebol-3-bazaar-updates.html The Rebol 3 B status
Arie van Wingerden 20-Mar-2013 5:38:16	Hi, today it is almost impossible to find on the web where the Rebol community can be reached. I found this site http://rebol.informe.com/portal.html but nobody seems to hangout there yet. Any ideas or plans to make the community reachable? Thx, Arie
Arnold 20-Mar-2013 6:01:50	Arie, Download AltME program from altme.com and visit REBOL-Gate world using guest as user and pwd, then file a request to join rebol4 world giving your wanted username and your email. See you overthere. Alternatively join the Red mailinglist first: find this via red-lang.org
-pekr- 22-Mar-2013 6:19:19	Some ppl are active on the SO (StackOverflow) site, but there's some stupid limit of reaching 20 points by asking/answering questions, before anyone can post. Reaching those points might not be so difficult as it might see at first sight ... http://chat.stackoverflow.com/rooms/291/rebol-and-red
is not a dick right? 25-Mar-2013 9:27:11	From: reddit post Please, tell my why I care. Tell me why either REBOL or Red is a good idea. This isn't to be a dick; I see no need for this language and would like to see an argument for its use explained. http://www.reddit.com/r/programming/comments/1awkcm/red_programming_language_version_032_released/
shadwolf 25-Mar-2013 16:34:52	Above ... well you totally are a dick ... but so what? If we shoudn speak with dicks we who speak with noone ... why are you interested in red or rebol well ... to this only you have the answer. I already did a list of things that I hate and like in rebol and the sourounding community... ... To be clear whatever fork of rebol or even r3 still todate there is no concrete plans. r3 official is alpha and we don't know if Carl will do a merge of the code sources proposed in github or not. I remember to the folks that it was none other than Carl that wanted to keep control and diffuse the most enhancement he could in rebol3 I will point to the endless licence discussion to prouve that point. Sapphirion is progressing? hum I don't think so they still try to enhance an win32 VID-lame engine... No plans for linux or mac OS X this as much is clear. As to know where they are going it is more than fuzzy. The other forks are lacking in the same dimension. It is incredible that at the moment that Carl start speaking about a way out of the alpha for r3 he suddently disapear and none of the fork takes really the lead with solid plans toward the futur. As a matter of fact I can do 200 version of r3 just changing the text of the boot message will that make of my fork a fantastic product? Most here wanted to be able to sell their fork of rebol. well I'm commercially not interrested by anything proposed. Because the question is what is proposed?
shadwolf 25-Mar-2013 18:06	rebol bazaar seems to be going to a better way than saphirion. At least they show easyly their changelog and their known bugs list... but before looking for the bugs in saphirion or rebazaar can't we have a focus on solving the gazillions bugs of the r3 listed in curecode ?
Shadwolf 25-Mar-2013 18:07:19	rebazaar for the gui can we have anothe color than greyish borring grey like saphirion? 32 billion colors and we are stuck on grey ....
shadwolf 25-Mar-2013 18:20:35	I don't see the interrest of rebazaar it is saphirion with the same guys less robert münch and with the same r3gui without widgets. We have the same direction and what is done in saphirion is brought to bazaar and vise and versa. Probably rebazaar is more open and community oriented than saphirion but what is the interest if they copy each other ? Vampirising rebol3 wasn't now the forks vampirise themselves... as for the changes actually the bigest one I noticed in bazaar was the integration of the dtoa code ... sorry I don't see the frenetic community bringing thousand of lines of codes that was promised by the opensourcing of rebol3.
shadwolf 25-Mar-2013 18:30:13	at BrianH > For me so far on the lower ground of the design for the r3 evolution and portability the discussion is non existant. Doing r3GUI for win32 in the era microsoft announces that they will trash win32 and enjoy Metro UI isn't it lacking connection with the reality?. So far what exists in nothing more than what carl initially wrote with some debugging but that's all. there is no ground level discussion no decision taken toward using graphical library that are portable on macosx on linux and on windows as it and that are not dead like AGG that had it's last release in 2005...(who said like rebol?...)
shadwolf 25-Mar-2013 18:40:07	Saddly that topic has no real solutions. the graphical libs that exists are too big to be applyed in rebol context. if rebol weight less than a mega I don't see any justification to download GTK+ or QT that weight more than 10 megas if rebol doesn't use any of the widgets and capabilities of those libraries apart the ground level widget decoration and Event capture... What about OPENGL ? on linux it is a nightmare because you have to pass through x11R6 to show opengl content. What about SDL? sdl is more prometing but can say it is often updated. What is the solution? Well we can strip gtk+ from anything else than the lower ground windows management / event handling but this is like cuting down a forest one tree at a time ... Long, hard, complicate and in the end you have a mess of a muddy land! We can see if SDL could fit the need. or if glut the utility window management portable toolkit of opengl could help some how... etc... but this means working on the topic not trying to make a glory from Carl's done work(like saphirion).
Arnold 26-Mar-2013 1:15:34	If only it was to break loose of the GNU C toolchain, that alone would be a good reason to choose Red over any other language out there. If you do not care about bloatware, where ever faster cpu's are necessary to get the same job done as say 20 years ago, only now using many more Giga's Tera's or Peta's of instructions to process, you have nothing to look for in REBOL or Red. You will find your happiness in ever slowing hardware and larger harddisks. For the rest of us that do understand what Carl is talking about on his pages elsewhere on this site and blog, Red and R3 are worthwhile, even if we have to be more patient. The work of Saphirion is hard to judge from outside, Shadwolfs critique is valid in that sense, being for Win only its progress is not accessible/testable if you are on mac or linux. And is is a mix of public and business effort. Besides having R3 source open is good, but it is a lot of work to become really acquinted with all of it, so the development is done within a small group of guru's atm. I need to say Carl promised to spend more time on R3 as of next month. The lead programmer of Red is making excellent progress, remember to support him!
-pekr- 26-Mar-2013 19:34	Arnold - no, Shadwolf is imo not right, he is just a bit ignorant to participate on anything, that is happening in any related community. Anyone can join Stack Overflow to have a chat and to get an idea, of where we are going. The point of ignorance is, that mostly anyone who cares knows, that Cyphre is overhauling View engine, to allow it to use another backend, which would allow eg. HW acceleration (not sure what engines are going to be supported). And also - Win32-only argument is flawed - everyone who cares knows, that Android GUI is underway. Also - there are some devcons underway, called ReCon. One will happen in Canada, and Carl should be present there too. The other ones are scheduled for Montenegro and/or Vienna. What is shadwolf right in, is, that some general direction consensus is currently lacking, but that's what we have to live with, unless another Carl appears. Red has some advantage here, as Doc is being its master designer, but even in the case of R3, ppl start to get organised in that regard. The progress just might be slower, than we all would wish for ...
shadwolf 27-Mar-2013 4:52:55	-pekr- sorry but I don't chat I see concrete result and judge upon that... Look at the rebazaar commited list and compare it to any other project you will see what means a project actively developed. -pekr- once again you are speaking about me having a narrow view upon what? your tiny circle of friend on stackover flow... Same people that you can find anywhere else in the rebol community tools(forums, altme, this blog etc..). As a matter of fact I'm pretty sure that rebol is a hudge hit somewhere in an alternate reality of a parallel universe But as for here and now it doesn't. -pekr- you discovered stackover flow past month... Everyone knows that stackover flow was a hudge libre information source some years ago and now they are just deprecated. -pekr- Everyone who knows what? where can you see that news show me because none of the active forums or public groups of altme rebol4 speaks about that! Pekr if you want so much that I get well informed and speak having all the cards in hand first you should have participate to the campaign to ban me from altme don't you think? Perk ... rebol on android ok but to do what? Sorry but I don't see r3droid being able to produce a game like angry bird I don't even see Cyphre capable of porting AGG to android ... If that is to make a tiny ugly app on android I can already use Illumination Software Creator. Since you are all over speaking about things knowing what you are talking about perk give a try to ISC and then cry ... Do the world need rebol? I though so during some years but all that I can do in rebol I can do them in other languages and most of the things I can do in other languages I can't do them in rebol or not without invoving me in a NASA style pharaonical project that means thousand of men work hours and that in the end will produce something I will be the only one to use and know about like for example... AREA-TC or VIVA-REBOL or reb3d-lib, etc... As for altme sorry but you should see the stats on rebol.org those doesn't show a vivid active spreading community it's 6 public group and always the 7 same people talking which represent 59% of the overall posts on those 6 public groups. Sure you can say that this doesn't reflect the overall use of altme in rebol world 4 but hey I didn't do the stats and I judge according the informations I have access to. As for this topic of this post so WHAT IS THE PLAN SAMN IT! WHERE IS CARL AND CAN WE GRAB HIS ATTENTION MORE THAN 2 HOURS EVERY YEAR TO HAVE TO DISCUSSION ABOUT THIS POST? I remember having laughed pretty hard when some month ago I saw Carl promising to dedicate 2 hours per week to rebol...
shadwolf 27-Mar-2013 4:58:57	As I said if I participe to rebazaar to enhance the r3 gui that will profit to the RMA spahirion lazy code guru toying with android that will then claim my work as their own more or less like they do with r3gui and Carl's work. r3gui in today 90% based on Carl's work Cyphre and Henrik can say what they want all they did was patching bugs and replacing yellow background by grey-ugly background ... But yeah keep trying to sell yourselves as code amazing wizard while the rest of the world laugh at your pathetic faces.
--- 28-Mar-2013 22:30:46	"[...] You'll need to get organized and make [things] happen. I'd be glad to offer advice." --Carl Sassenrath Mr. Sassenrath clearly said he won't be actively developing Rebol. It is time for this community to grow. But, like a child, this community is afraid to walk alone. Carl will be glad to offer advice. Stop sitting around him waiting for his approval! Will this community wait for Carl to die to start making decisions? I rather have his advice now. Thanks Carl for the source code, and move on! It is time for the 5 (6?) main Rebol's developers to accept Carl's decision and take charge, make a community fork and manage it. Stop the community from bleeding to death. •CCX•
-pekr- 29-Mar-2013 9:00:50	Shadwold - I know Stack Overflow for years, I just was never active there :-) And their chat has even bigger entry barrier to enter than Altme - you need to gains some 20 points in order to being able to chat actually. As for your ban on Altme, if I remember correctly, I was the one against it. I was also agains banning Terry or anyone else ... Cyphre's message was actually posted on a public forum - Rebool Google forum. You can check it yourself here - https://groups.google.com/forum/#!topic/rebol/6MMlv-E3j-E And shadwolf - we all would like to see Carl coming back. It is actually not our fault, that he is not interested or just pressed for the time. Everyone is trying to do as much as free time allows and while the progress might be slow, some things are a bit progressing - still better than situation one year ago ...
--- 30-Mar-2013 22:12:01	JUST A QUICK NOTE Are these actions related to my previous post here? https://github.com/rebol/r3/pull/111 https://github.com/rebol/r3/pull/76#issuecomment-15679612 I can't see the evil in accepting Carl as an advisor and not as a developer (His idea, anyway.) Does anybody really expect Mr. Sassenrath to evaluate months (soon 4) of pull request (35 at the moment) in a quick glance? Looks like its Mr. Sassenrath who will need advice deciding what to accept and what to reject... •CCX•
(at)CCX: 8-Apr-2013 10:28:13	well you can extract what you want from the Carl's saying. As he tends to say everything and it's contrary you can mold your opinion really focusing on the bunch you like. to illustrate that point as a side note of what you quoted I can too quote this http://www.rebol.com/article/0512.html Which shows that Carl forsee an active role for him more than a I watch over you and comment what you do... I remember have seen carl saying he will make a weekly overview of the community works. and do comments. AS a matter of fact we had a 2 month blank time in which Carl was doing something else. As for this topic we don't have any closure. Put appart perk's trolling or mine (if you considere that my conserns are trolling ...) and still noone gives us a reply about this topic ... and more generally where will go rebol3, what are the priorities, etc..? It is better to start another topic about r3 graphics which is a so vast and tendencious subject that since 2005 we don't have a concrete debate on it...
shadwolf 8-Apr-2013 10:45:45	previous comment is mine too...
shadwolf 8-Apr-2013 11:03:51	if we really on Cyphre well r3 will go to android... is there a true interrest in there? is it better to focus on finishing r3 for the 3 main workstation/server OS? who knows? who cares? the doers already decided and there is no way to make them do anything else.
android 6-May-2013 14:43:04	Shadwolf,try googling android agg,been around for a year at least code.google.com/p/agglib-for-android/ Of we should also look at what's coming from arm and their internal 1 Tb/s conherant bus on their a15 and all the new code being optimased and back ported to linux etc

Post a Comment:

You can post a comment here. Keep it on-topic.

Updated 10-Jun-2023   -   Copyright Carl Sassenrath   -   WWW.REBOL.COM   -   Edit   -   Blogger Source Code