Comments on: R3.0 Plan for September 2009
During August
It was a busy month. A lot happened in August:
- The extension mechanism was finally released, along with documentation and examples. The mechanism is quite easy to use, and it did not take long for developers to report successful interfaces. There is, of course, more to do to make it fully capable, but now we have a reference frame for such enhancements.
- Automatic text conversion has been added for READ and WRITE. You no longer need to use TO-STRING when reading a file... simply use the /string refinement. And, to WRITE, the UTF-8 encoding conversion happens automatically for string arguments.
- The COPY and MAKE object functions where revised based on a clear definition for what deep copy means. It's easier to remember now: basically, strings and blocks are deep copied - but, nothing else is unless you specify it. Also, you can specify what types you want copied. Quite useful.
- More security has been added and sandboxes were put into operation. This is both good and bad. It's good because your system is more protected, but it's a bit annoying to see errors from security violations, now that we've been using R3 to run various scripts.
- The SYSTEM object is now protected. But, this has been a lot more difficult than anticipated because various subsystems modify the system object.
- Numerous other bug fixes and enhancements where added.
Goals for September
It's time for some major decisions. Here's what's going on:
- We need to move to beta. And, we really need your help to do that.
- Just like R2, we need to split R3 into a "core" (for servers and scripts) and a "view" (for GUI's and apps.) Doing this allows us to finalize the R3 kernel and move it into beta, and that allows users to put it to work on servers, websites, CGI, etc.
- We need a "hit list" of remaining tasks, and you need to make sure that anything critical is listed. There is actually a draft of such a list, and it gets updated about each week. It's at this location on the doc wiki, for your reference.
- The CureCode database is the other "hit list" of things to do. As you can see, a large number (935) tickets have been processed and completed. There are 172 open tickets, and 78 that are in "waiting". Some of these things are essential, but others will need to wait for a subsequent release. Certainly, serious bugs must be fixed.
- The REBOL 3 Documentation needs your help. I think maybe it's time to come up with a more detailed plan of action. This is a wiki for a reason. If you're not able to edit it, but you want to, please post a note on R3 Chat. (That system controls user access to the wiki.)
- It's time for changes to the main RT website and how we market and promote REBOL. Plans are being made. Your input is appreciated.
Many of the remaining tasks for beta release require your inputs and/or code contributions in order to finalize the design.
29 Comments Comments:
-pekr-
9-Sep-2009 11:06:25 |
We should not release as beta, unless it reaches at least completness of R2 equivalent = we have to fix 'call, add 'cgi mode with all supporting funcs that were part of R2. Those two are missing in the prepared list and I also wonder about networking protocols being a low priority? Maybe because they can be done by the community? | Maxim Olivier-Adlhoch
9-Sep-2009 12:00:31 |
IMHO, extensions must be extended a bit and these enhancements must be part of the beta spec.
They will allow you to focus on other things and allow us to become self-sufficient for a vast array of tools which are just asking to be done with R3 :-)
Stuff which isn't finished or even addressed in R3, yet, can be temporarily handled via extensions while you work out how they can be integrated as a standard component.
Extensions even allow us to test a lot of binary stuff to see how they can be used before trying to integrate them into the core or view, they allow us move along with you in parallel.
Extensions also allow R3 to be more than R2, they force us to use R3 more, since not having extentions, we can't fallback to R2. | Brian Hawley
9-Sep-2009 13:15:33 |
I would like to see device extensions on that list :)
Also, there are PROTECT changes waiting in CureCode, and security fixes waiting for them. Finishing PROTECT needs to go on the list too. | Ben
9-Sep-2009 15:10:41 |
I agree with -pekr-. fwiw - stay in Alpha until everyone 'thinks' its ready for beta and sure no errors exist. Only then going to beta will drive useage up and expose more bugs. | Alan
9-Sep-2009 17:09:42 |
I agree with Maxim in that it should not go beta until there are distinct advantages over R2 to entice us to use it. A major enticement for me would be a stable VID.
Or...as you are proposing a separate Core and View versions a Core version could go beta much earlier. | Jerry Tsai
9-Sep-2009 18:42:59 |
Don't just think about ourselves, think about those outsiders.
This alpha phase (since 2007-7-1) has been so long that some outsiders without faith might think that the 3.0 release date will never come. We see new alphas coming out every week, but this wo'nt make them excited anymore. For them to get excited, a "Beta" or some cocain might do the trick. They need a "Beta" label to believe that REBOL 3.0 is right around the corner, and this is the right time to try it. And I need the "Beta" label to persuade my boss to let me use R3 in server development. | Jerry Tsai
9-Sep-2009 18:52:50 |
Download "REBOL Brainwasher.pptx" (PowerPoint 2007)
http://sites.google.com/site/cnrebol/home/xia-zai-lie-biao/REBOLBrainwasher.pptx?attredirects=0
I used it to brainwash Alibaba.com. | Jerry Tsai
9-Sep-2009 23:36:54 |
"task!" should be in the list of remaining tasks. Multi-tasking is very important in many applications. | -pekr-
10-Sep-2009 0:43:46 |
Jerry, I raised the concurrency question in R3 Chat few days ago. No reply yet, but indeed the topic is interesting and might be important, because if we go for beta with only Core, guys like DocKimbel might be interested to start porting of Cheyenne. Without the concurrency topic covered, it will not imo happen.I think that task!s, as those are in R3 recently, are due for an overhaul. Some ppl were studying Erlan msg passing based principles. We will see, what Carl comes up with, but I am not sure tasks will make it for 3.0 ... | Claude Breton
10-Sep-2009 1:36:52 |
Just the best 09/09/09 piece of news to hear that R3 is coming nearer and nearer to completion ... good luck with what remains to be done ! | DocKimbel
10-Sep-2009 5:50:28 |
Pekr: "We will see, what Carl comes up with, but I am not sure tasks will make it for 3.0 ..."
Waouh, it's more important to have a new View/VID3 in R3 than support for multithreading? I guess that all the other programming language designers that have included multithreading support from the beginning must have lost their time...Looks like "Bob the artist" finally won... | -pekr-
10-Sep-2009 6:35:06 |
Doc - I respect your professional opinion, but this time, please - try to do a bit of a homework, right? :-D
Have you looked into beta list? You can find it linked directly in this blog post. Can you see there any mention of VID? Because I can't.
So - why have you raised your question at all? I am known proponent of View/VID, but I also referred to my comments in - http://www.rebol.com/cgi-bin/blog.r?view=0424#comments - can you see there any mention of View/VID?
All I am saying is, that even if we think "core" only, Carl still might think into splitting it into 3.0 and 3.1 release. At least I remember, that it was some topic some time ago. Just few days ago, I was privatelly lobbing for adressing tasking/threading, because that topic was not adressed at all. And I was lobbying because of Cheyenne ;-) .... | Pavel
10-Sep-2009 7:00:20 |
I vote for REBin + REBstorage (or whatever is the real name for RIF now) | DocKimbel
10-Sep-2009 9:11:20 |
Pekr: I didn't followed closely all the latest changes about R3. I'm glad if improving View/VID is no more a high priority in R3 project. IMO, View2 was enough for R3.0 (I'm still selling View2 based apps, it's far from been dead), View3 could have waited R3.1.
I was surprised by reading that there's a risk that threading would not make it in 3.0 (confirmed by reading the beta list). In that case, I would really be very deceived, because months have been spent by Carl on View/VID instead of working on features that only him can implement because of the closed nature of Core. | -pekr-
10-Sep-2009 9:25:33 |
Doc, imo the problem with concurrency in R3 is, that we might aim for more powerfull solution, than what was originally thought and maybe even partially implemented. Actually I can spawn tasks in R3 for few years, but dunno what was plan for inter-process communication, I do remember that some kind of xxx:// scheme.
There was also lots of talk about making it really robust, Erlang level or so, and so my uneducated estimate is, that tasks probably need a complete rethinking and overhaul, but I might as well be mistaken and maybe it takes Carl few days to finish them. If so, I am fully for having them for beta, as well as user-types. That way, we will get Core mostly finished (well, Rebin is missing, but that can wait for 3.1 imo). | -pekr-
10-Sep-2009 9:35:53 |
Carl, what about blogging a bit about those features, which users/developers consider being crucial enough, and are not covered by your beta plan? Namely:
- tasking/threading - concurrency plans in R3 in general
- Rebin
- user-types
- Unicode (collation) aware sorting
- Callbacks for Extensions
etc.
| Peter Wood
10-Sep-2009 16:55:01 |
I think it needs to be clearly stated that the /string refinement of the read function only supports utf-8 or plain ASCII text files.
>> print read/string %macroman.txt
This is a sentence including the euro sign �
>> print read/string %windowslatin1.txt
This is a sentence including the euro sign €
>> print read/string %utf8.txt
This is a sentence including the euro sign €
>> print read/string %utf8nobom.txt
This is a sentence including the euro sign €
>> print read/string %latin1.txt
This is a sentence including an a with an acute accent �.
>> print read/string %windowslatin1.txt
This is a sentence including the euro sign € and an a with an acute accent �.
The above samples were run in a UTF-8 terminal window. | Carl Read
11-Sep-2009 1:10:18 |
To my mind, beta has always meant feature-complete, bar for user-testing. So I'd call it a beta when all the features of R2 Core are present, (excepting those which are being discarded), plus enough of the new stuff that's working well.
What you DON'T want to do is release something that's of less use to some users because you haven't got around to including something which was in the earlier version. It's annoying, not to mention bad advertising, since it's what the annoyed will mention first.
| Maxim Olivier-Adlhoch
11-Sep-2009 9:43:09 |
I can live with R3 having a bit less stuff in it, but not having what is there half-done (independently of bugs, which can be expected in beta).
If threads make the cut, then they HAVE to support thread safety in extensions for example, including stack coherency when doing callbacks... before going to beta.
These issues are VERY tricky to debug completely by one person and WILL definitely crash an application when an even slight issue occurs.
I think what should be done is a two-tier release model.
---
tier one:
R3/experimental where features come and go, change considerably between releases, and let Carl not have to break his mind about finding the perfect solution the first time. *there could be several different experimental versions tackling separate issues individually, to reduce interference*.
R3/alpha once those new things have reached a feature lock stage, and are ready to be integrated in the main core.
----
tier two:
R3/beta once the alpha stuff is tested externally and reaches a point where maturity/stability are acceptible.
R3/release once the beta is fully debugged and beta features have no more CureCode issues at time of release.
----
Basically, all four versions would live concurrently in my mind, and it would allow people to start using R3 for some projects, knowing that a part of R3 IS ready.
As the new capabilities trickle down, more and more people start projects based on what is now working.
Trying to release a single version with all features at once will delay R3 indefinitely IMHO. | Maxim Olivier-Adlhoch
11-Sep-2009 10:00:20 |
Right now there are still some very basic things which are still at an almost experimental stage like the 'PROTECT and system context.
Until the very low-level core stops changing, there is no point into going beta... scripts will be breaking within weeks if not days.
I'm not complaining, I know its a lot of work and these decisions have dire consequences (R2 being the lesson), and must reflect all the debugging and testing going on, which is very much alive at this point. If the alpha hadn't gone on as long as it is right now... modules wouldn't have been able to get the overhaul they needed, Extensions would be bloated and buggy. Things that you cannot go back and fix easily once a lot of lasting code exists... The worst thing that can happen to R3 is for R3.1 to make scripts incompatible again... so let's make sure that all the core stuff is up to snuff before it gets out!
IMHO, in R1/2 the alpha stage didn't discover many of the shortcomings which later plagued the language for its entire existence.
Pre-production doesn't make a release longer, it prevents the release from being irrecoverable later on. | deglingo
11-Sep-2009 14:23:12 |
Just a humble remark from someone very respectful for somebody that has created such a great language (and for the community that contributes to it) :
From time to time, I follow R3 progress. And, as a few people here, I'm surprised that there is a kind of "black-out" about R3 multi-tasking part (task!, concurrency, synchronization, inter-processus communication...) on this blog, not much information. And it seems that it won't be in beta version. I know it's a very very complex subject, and there has been a huge amount of work done on R3 so far on other areas. But, Carl designed one of the first multi-tasking OS (Amiga OS) in 1983, almost 30 years ago. So, it can seem surprising that there is no news on this area on R3 blog. Maybe different times, OS, computers..
By the way, I have a question : implementing/finalizing multi-tasking doesn't have an impact on R3 overall design ? Can it be totally separated from the rest, and be finalized after going to beta version ?
It would be interesting to have an article presenting Carl's vision on this interesting topic, on the "light tasks" model that he prefers rather than the "JAVA threads" one.
Thank you so much for REBOL, this amazing language, that can be a little difficult to learn (my case 1st time), but once you jump into it, brings creativity, productivity with dialects, contexts...
| -pekr-
11-Sep-2009 20:20:14 |
Deglingo - as far as my understanding goes, R3 interpreter is implemented in form of DLL, so that you can call it or even include in your app. It mostly contains structures to be filled-in from Host code section, which is supposed to be open-sourced.
Stating above, I think that even thing like tasking/threading will be part of Host code implementation, and hence community can try various strategies in the future. Of course we are all interested in that topic, from various reasons - one of them being Carl designing multitasking king of the past - AmigaOS, and the other one being - we want REBOL to be excellent. Some guys were studying e.g. Erlang style tasking, as Erlang is being highly acclaimed in the area of high performance concurrency area ... | deglingo
13-Sep-2009 14:49:01 |
Thanks pekr for this information. Rebol 3 current features + kind of "erlang tasking capability" could be great. I've heard of Erlang language being a killer in the multi-tasking/concurrency area too. I'm maybe wrong, but I think multi-tasking/concurrency design in Erlang seems not that far from Carl's vision, OS-independent light processes (instead of native threads) communicating fast between themselves through messages, but sharing no resources...
I know that Carl is more than busy right now, but sometimes an article making a status on this big subject could be nice and interesting to read...just a question of time !
As you say, people fond of Rebol want it to be excellent ! That's true ! And, I think Carl is the first...
| shadwolf
14-Sep-2009 19:42:56 |
for once no comment that passionated discution gived me a headache.
| Johnny Reb
1-Oct-2009 0:29:08 |
Here's how NOT to market REBOL R3:
REBOL is a faster, easier, better (Java, C++, Python, Ruby, Javascript, XML) that lets you work smarter.
Here are some ways of marketing REBOL R3:
1. [a] Show how to make games with R3, fast and easy
[b] Create a games hub website for games made with R3
2. [a] Show how to make web site and desktop "Web 3.0 WIDGETS" with R3, fast and easy
[b] Create a "Web 3.0 Widgets" hub website for widgets made with R3
Stop and then start to think about some of the most successful languages of all-time: xBase in dBase II and the declarative formula language in LOTUS 1-2-3.
Come to see the alikeness between REBOL, dBase and LOTUS 1-2-3.
dBase II and LOTUS had "engines" (interpreters) that laymen and mere mortals could manipulate.
dBase II let everyday business workers, albeit smarter ones, model their own business processes and then manipulate the models using scripts.
The TARGET for REBOL should be the tech savvy business worker AND NEVER the all-too-often narrow-minded, nose-picking, propeller-head programmer with his useless computer science degree. That kind of fellow knows nothing about business and cannot affect change in businesses. Often, he knows even less about living and life.
"Selling" against Java, C#, C++, Visual Basic, Python, Ruby, XML shall keep REBOL right where it is -- among the obscurity.
REBOL is so beautiful, like a FORTH and LOGO mash-up with some SNOBOL pattern-matching thrown in for good measure. Yet, most would never connect these to REBOL or even know what those things are.
A frontal attack against the Corporate World shall end up fruitless.
Yet, infecting the many through practical and fun ways shall spread REBOL R3 far and wide. This is the way of Google, of dBASE II, of LOTUS 1-2-3, of Twitter, of Facebook, of DOOM, of Myst, of more.
Oh, and you're welcome.
| Kaj
1-Oct-2009 10:09:21 |
A bit confrontational, but nevertheless, well said. :-) | Lloyd
9-Oct-2009 6:41:49 |
How we market and promote REBOL?
REBOL Card Anyone?
If the objective is to connect with the general public's interest in be creative with their PC then there needs to be a shift from a very technical marketing approach.
I think Apple's HyperCard success in creating a new generation of programmers was the result of a programming environment that allowed you create useful applications with very little coding and still do a deep dive when you mastered the language.
REBOL needs to provide a similar experience to “Hook” the next new generation of programmers.
1. From REBOL’s website, a users should be able to click on a link to download a “REBOL Application” that was smart enough to check to see if the user had the REBOL Runtime (Core/View) installed and ask the user to confirm a download install of the correct version of the runtime before opening the “REBOL Application” (today’s REBOL scripts). I use the term “REBOL Application” because the vast majority of people are not comfortable writing scripts in a text editor. If they were than all the other scripting languages would be running the world.
2. Hosting “REBOL Applications” provides a marketplace like Apple’s ITunes App Store. New developers become interested in creating for a profit.
3. I think the current REBOL View should become the new concept of a HyperCard Home stack allowing a person to manage his application collection like ITunes or flip into developer mode to edit/create new scripts/applications. How cool would it be if you could drag a button onto a window and add script to it to produce a REBOL application by a new programmer?
4. Remember that HyperCard became an educational tool in public schools and nothing has replaced it. With all the REBOL has to offer in power, features and innovations why not empower America’s next generation! | Johnny Reb
14-Oct-2009 16:55:17 |
(at) Lloyd ... Great that you brought up Hypercard. Excellent example!
(at) Kaj ... yes, and thank you! | WhatNo-IPV6
26-Oct-2009 14:03:30 |
Wow , Just WOW, in all this time not one single one of you long time Rebol developers have mentioned the NEED for Generic Ipv6 in Rebol in the Year 2009+
your not seening wood for the trees it seems.
The One Claim To Fame for R2 and the newest R3 Being...
it uses "relative expressions" (lean, domain-specific languages) to create a powerful new method of creating Internet programs, scripts, and applications
your going to get ripped apart or werse Ignored and labeled as not werth our time or effort, if you dont have basic IPV4 AND IPv6 networking capability down pat on any beta...
remember the http://www.rebol.com/what-rebol.html page has been telling people that "REBOL 3.0 now is in development. With release expected autumn of 2009." and "REBOL was created by Carl Sassenrath.
The system designer known for bringing multitasking to personal computers." For a VERY LONG TIME, so its got to have the basic multitasking/threading capabilitys too
|
Post a Comment:
You can post a comment here. Keep it on-topic.
|
