 |
| the raod to Rebol 3.0 | |
| shadwolf | 24-Jan-2013/15:21:13+1:00 |
| For the one that don time to travel through the blogs I will concat the discussions around the 3.0 version of rebol 3 so the going out of the alpha stage. Happy reading floks... ----- shadwolf 17-Jan-2013 9:19:36 (at) Carl: so we are a month later the opensource release of rebol3. ANs I would like you to consider and eventually reply to those ask or preocupations I have. What is done to centralise working effort? What open discussion channels are offered? You talked about a need for a forum where is it ? I see the Gurus assembled in Saphirion but saphirion is intended to be more a separated branch of rebol over skilling the official branch than an effort to be a preview branch of what will be rebol3 official. My consern is that those same people more or less are the people in charge of maintaining the main branch + your opinion/veto. Don't you think that in a near future we will have a Saphirion r3 descendant evolving in its corner and a r3 official stuck in no evolution state until you decide to start coding to it? What interface is made betwin you, your needs, your plans, your wish for r3 official branch and the public needs vision plans for r3? the success should be in the road in betwin the thing people want to see in r3 and spend time designing coding and and the things you want to see in r3 that you spend time in coding and desining. So what interface is set to discuss those things. Will it be a king/ministry kind of talks where a set of selected people (miniter) will tell you in an appropriate channel and time what they want you to know. And will your vision of the public needs will be narrowed down by the filter of your ministers? What is the roadmap ? What is your plan for r3 to get out of the alpha stage? Alpha version along a product name is good when it comes to a game like Street Fighter II version alpha prime turbo plus plus but along a language it makes it just stamped with "pretty unstable do not use" Should alpha version be public? Don't you think that calling r3 alpha is a bad image for rebol? Rebol 3 is officially stamped 2.111.X.X but is that logical to have that link back to rebol 2 when at same time you tell the world that rebol 2 is dead and that rebol3 is a completly different brand ? Rebol3 is almost a decade long of life, a old thing so, in that time didn t you noticed, like you did for r2 that it was lacking in many core design area and that instead of trying to push to a release version of r3 alpha 10 years old you should promote the building a a r4 with a completly different design that will make it fast and stable? the more I m into r3 the more it looks like a light version of rebol2 ... So yes it is way easier to maintain, way faster, but it only does a 1/5 of what was doing rebol2... so isn t that better based on a heavy lack of funcionalities? Will rebol2 be opensourced one day? Brian Hawley 17-Jan-2013 14:23:12 Good post overall Shad. Minor fix: First work on R3 started in late 2006, so it's closer to 6 years old than it is to 10. We have a long time before we should talk about R4. --- In MAking 3 a 3,0 post on Carl's blog. Carl Sassenrath, CTO REBOL Technologies 21-Jan-2013 3:41 GMT Article #0527 Main page || Index || Prior Article [0526] || 24 Comments || Send feedback 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. 24 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. | |
|
Login required to Post. | |