Comments on: R3.0 Plan for August 2009
Major enhancements and bug fixes were made during July, with 11 new releases published, many of them containing major changes, including solving a variety of language consistency issues. (And I'd like to thank all those who were involved in that effort.)
- Many security related changes were made, including adding file sandboxes and new security policies, limits, and tests. The SECURE function documentation was substantially updated.
- The user program context was split off from the system context, a major change to the runtime global environment. Scripts run in their own context, with their own copies global variables, including all functions.
- The TRACE function was expanded to provide backtracing, an important feature for debugging crashes after they happen.
- Dates were converted to consistently use UTF internally, with conversions to local timezones as needed at the interfaces. New refinements were added to related functions.
- Finally, toward the end of the month, releases slowed down while major work was done to provide extensions (previously called plugins). This work lapped over into August.
See the R3 Releases change log for full details.
Goals for August
Resume with unfinished items outline earlier. Mainly:
- Release of the extension mechanism, including documentation and numerous examples.
- Text handling for READ and WRITE functions (auto-UTF and line feed conversions.) This change makes scripts easier to write.
- Basic support for file modes.
- Continued bug fixes and minor enhancements as listed on CureCode.
Very nice. But what about the console?
For many if not all users it might be the main tool for testing, learning, programming.
Working with the console in R2 is a pleasure, in R3 (for Windoze) it's just a mess. C&P for example is nearly impossible.
I agree, and I've even written about this as a general issue with languages under Windows. I wasn't specifically thinking of REBOL; I didn't know the console had been ditched.
Ratio - I too, can't get used to crappy Windows console. It sucks big way. But - we should probably distinguish - we need two console versions - the windows one, mainly for admin purposes, where no GUI is available, and then some graphical one, for the sanity of common user :-)
I think, that we might get one as a View based app, not a native one. It is possible to do - go to R2 Desktop/Public/Sites/Cyphre, and there is vconsole script.
But maybe RT will decide to put back R2 native console. After all - that part will be open-source host code, so it is just question of time ...
August is short, so for the September, I think we might think about implementation of some of parse REPs. We need to proceed with networking protocols (and other schemes), and I think it would be nice to have parse already enhanced. Just my tip for September. Well, would like to see also some GUI work restarted :-)|
On console: I would like that as well.
There are several ways to approach it. What we need is to determine which direction we want to go. (It would be open source.)
For example, should it be written in REBOL or C? Custom or packaged? How much IDE capability should it have?
Pekr: I agree with your notes.
I'm quite happy with the R2 console and do not think there is much more to do about it (which in any case could be added later, or not?).
Never used and certainly will never use any IDE's. And why should the console suddenly be open source? Cannot understand that. All I know is that I'm missing in R3 a very important, efficient tool!
Wouldn't it be enough just to "copy" the R2 console to R3 ?
Would be great to have this good console in R3 as soon as possible available, too.
Thanks a lot!
Why not have the console rudiments coded in C, wrapped up in Rebol mezzanines for various feature groupings? This way, underlying capabilities can be exposed with symbols gaining first-class Rebol usage where efficient or necessary, and IDE functionality can be optional but available immediately at hand.
A console could be initiated with minimal features, basic text-handling functions such as C & P, undo, etc. or a full-fledged IDE. Since optimal IDE configurations and features sets are also debatable, it would be possible to have 'light' and 'heavy' IDEs, as well.
This one area has so much potential to support and promote further trial and adoption of Rebol amongst programmers. So many expect at least some IDE functions as being readily accessible, when considering a new computer language. Presenting new users with their choice of three or four possible editing arrangements shows awareness of this issue, and is an opportunity to demonstrate more robust programmer support.
As with other critical areas for R3, now is the best time to make these decisions.
As for console, I almost forgot, what we had available - http://www.rebolforces.com/articles/tui-dialect/|
pritty simple kingCon and intigrated GUI requestfile, requestChoice, etc at the VEry least.|
Most of the people who are in the flower business and the delivery of flowers at leat would say it and admit that this is a bit different than it looks like. And to be honest no one wants to say how things will look like in the future in this niche at least. Also more and more people would say that this is az true as it gets. So no more for me and for them.This is what separates them from the others. And Even KSD Games and https://www.console-world.eu gaming have talked about it in the recent months|
Post a Comment:
You can post a comment here. Keep it on-topic.