REBOL 3.0 Front Line

REBOL 3.0 Front Line http://www.rebol.net/cgi-bin/r3blog.r A place for publishing comments and discussions about REBOL 3.0. en-us Carl Sassenrath 2013 REBOL Language Relative speeds from compiler optimizations http://www.rebol.net/r3blogs/0352.html http://www.rebol.net/r3blogs/0352.html no-spam@rebol.com (Carl Sassenrath) Sun, 20 Feb 2011 14:29:10 -0500 As an experiment for A111, I compared various compiler optimizations using the simple technique shown in this line: r3 --do "print [size? system/options/boot speed?]" Here are the results for different optimizations: optexe-sizeinterpnativememorydisk none5195125855245993137 -Os36340455444132116164 -O141678471504098104169 -O245774483484112114171 -O356014482154208117168 You can see that the default -O2 used for releases produces a good blend of results. Measurements taken on a mid-priced CPU: Intel i5-2500 CPU @ 3.30GHz (quad core.) Is Git working ok for R3? http://www.rebol.net/r3blogs/0351.html http://www.rebol.net/r3blogs/0351.html no-spam@rebol.com (Carl Sassenrath) Sat, 12 Feb 2011 13:31:08 -0500 A few months back we set-up Git for the R3 Host Kit source code control. This was a suggestion from a REBOL user for tracking releases and changes. We picked Git for the reasons listed in the above link. It has come time to release R3 A111, and I'm looking at Git for source submissions. On github, I see changes from Oldes. That's great, thanks Oldes. So, are there any other change submissions? If so, where might they be posted? The purpose of github was to use a well-supported central source management service. But, if Oldes and I are the only github users, I'm not sure it's worth the effort. It's easier for me to use R3 devbase to fetch and post source code changes, and it works on every target platform, and I've got the full power of R3 scripting behind it. Perhaps that's what I should use, and someone else can become a "gateway" back and forth to github. Also, I will admit that these days I'm very busy with special projects that I don't have time to follow various discussions and message threads. But, I check in with BrianH, Cyphre, Ladislav, RobertM, Henrik, Gregg, and DocKimbel on a regular basis. If you need to reach me, contacting one of them might be the best path. Anyway... R3 A111 is ready for release. If I can find any other changes this weekend, I will merge them. Otherwise, A111 will be released as is, and we can merge other changes into A112. The SPEC-OF an Object http://www.rebol.net/r3blogs/0350.html http://www.rebol.net/r3blogs/0350.html no-spam@rebol.com (Carl Sassenrath) Fri, 12 Nov 2010 00:31:34 -0500 In R3, functions have "specs". These are interface and operational specifications. For example, arguments passed to a function, help strings, return values, exception handling, trace/profile controls, etc. It is intended for objects (hence modules) to also accept a spec. This is one way to provide help strings for an object, enforce typing of the object's fields, along with other features. The problem is: what should be done with specs when a sub-object is made. If we keep the spec, it would be nice to make it a reference, not a copy. Then, there's the issue of mold: would all sub-objects mold the spec back or not? So, it's not well defined. It may need to wait for post 3.0.0. Host-kit Source Control http://www.rebol.net/r3blogs/0349.html http://www.rebol.net/r3blogs/0349.html no-spam@rebol.com (Carl Sassenrath) Thu, 28 Oct 2010 22:58:13 -0400 It's about time we move the host-kit files to a location that provides better source control and developer access. Andreas Bolka has already setup an unofficial area on github.com/rebolsource/r3-hostkit, and we'd like your comments on it. If there are no strong objections, we'll make that the official location. I should note that this is experimental, and we'll see how it works out for the REBOL community. Idioms Wanted http://www.rebol.net/r3blogs/0348.html http://www.rebol.net/r3blogs/0348.html no-spam@rebol.com (Carl Sassenrath) Thu, 28 Oct 2010 17:31:10 -0400 Just a cross link: I've posted Bring Out Your Idioms for R3 on the main blog... because I want to get as many user ideas, suggestions, contributions as possible. Remember help lib, sys, and self http://www.rebol.net/r3blogs/0347.html http://www.rebol.net/r3blogs/0347.html no-spam@rebol.com (Carl Sassenrath) Sat, 23 Oct 2010 03:53:33 -0400 Just a reminder... beginning in A109 these three lines are useful. Run R3 and type: ? self ? lib ? sys Gives you an idea of how the main contexts are set up. Here's a description: :self - is your user context, where your main script lives. If you didn't provide a script, it's mostly empty. :lib - is the export library, and contains all the main functions of the system, as well as any exported module functions. :sys - is the private system context. What used to be intrinsics now live here. Note that words of value 'done indicate functions that concluded their operation (and are being recycled.) A109 Host Kit Status http://www.rebol.net/r3blogs/0346.html http://www.rebol.net/r3blogs/0346.html no-spam@rebol.com (Carl Sassenrath) Sat, 23 Oct 2010 03:10:24 -0400 There's an unofficial draft version of the A109 host-kit on the site. I say "draft" because it's not tested at all. The focus of A108-A109 is on the core and its contexts, not the host-kit. However, if you do try it, remember that modules have changed; therefore, extension modules have changed! However, the /Core release includes the minimal xtest extension, which seems to work ok, so you can have some degree of confidence. However, your extension module header should look like this now: REBOL [ title: "My extension" type: module options: [extension] ... ] A number of other options are available. (See Brian Hawley's notes if you need more info.) Amiga A109 Uploaded http://www.rebol.net/r3blogs/0345.html http://www.rebol.net/r3blogs/0345.html no-spam@rebol.com (Carl Sassenrath) Sat, 23 Oct 2010 03:04:27 -0400 You will notice in the REBOL 3 downloads area a preliminary release of R3 A109 for Amiga OS4 on PPC. I need to emphasize "preliminary". When a build runs well enough to pass the basic tests, run the R3 chat reblet, and upload itself to the REBOL.com website, then it gets to be released for further community testing. And, besides, tomorrow is AmiWest, and "I promised." Example of a minimal module http://www.rebol.net/r3blogs/0344.html http://www.rebol.net/r3blogs/0344.html no-spam@rebol.com (Carl Sassenrath) Fri, 22 Oct 2010 20:52:37 -0400 Ok, you've heard about REBOL modules, and we've made a lot of changes recently... but, you're not really sure how to make one. Here's an example. It's very simple. First, create a module file. This one is saved as simple.reb: REBOL [ title: "Simple module" type: module ] export num: 1234 export sum: func ["Example" val] [val + num] Notice it look like a normal script, but we specify the type module and the word export is used to indicate exported words. Now, in your program, you can either import the module: import %simple.reb Or, another way is to specify it in the header of your program: REBOL [ title: "Main program" needs: %simple.reb ] Then you can easily access the exported functions and data of the module: print num == 1234 sum 1000 == 2234 Of course, this is just scratching the surface of what modules can do. But, I wanted to start with a simple example to show how easy it is to get going. It's that easy. A109 Released http://www.rebol.net/r3blogs/0343.html http://www.rebol.net/r3blogs/0343.html no-spam@rebol.com (Carl Sassenrath) Wed, 20 Oct 2010 20:32:34 -0400 Ok, so as you may have noticed A108 was pretty rough around the edges. So, we've released A109 with a number of fixes that make it work a lot better, and it also adds major improvements to the module system, thanks to the efforts of Brian Hawley. Of course, we've created a documentation nightmare for ourselves... there's quite a lot to do now to update it. I'm pretty sure you'll find the changes were worth it. RFC: A108 LOAD/SAVE support changes http://www.rebol.net/r3blogs/0342.html http://www.rebol.net/r3blogs/0342.html no-spam@rebol.com (Carl Sassenrath) Mon, 18 Oct 2010 15:35:49 -0400 This is a very quick request for comments on some changes that will be made to get the new LOAD/SAVE code working the way we want in A108. I think most of these are obvious, but if you have some insights, post them. *CHECKSUM/part will be added *DECOMPRESS/part will be added If possible, also: *Better validation of compress header before memory allocation is attempted. *MOLD/options [base: 64] (to replace system/options/binary-base usage for SAVE/LOAD operations.) *APPEND object options (TBD) using refinements to allow features like a block of words and words-in-contexts. (More to be said on this later.) If you add your comment in the next couple hours we'll check for it prior to A108 release. About /local words http://www.rebol.net/r3blogs/0341.html http://www.rebol.net/r3blogs/0341.html no-spam@rebol.com (Carl Sassenrath) Wed, 13 Oct 2010 12:51:49 -0400 There's been some consternation regarding the use of the /local refinement for passing initial values to internal variables. I'd have to admit that I didn't think this was an important issue... because all good functions initialize critical locals. However, that's not true, is it? That's the old C programmer in me thinking in that way. Most of us REBOLers know that locals are initialized to NONE, so we depend on that fact. The problem occurs when we use such uninitialized NONE values to produce important effects within our code. I'm very much against requiring programmers to write code like this: doit: func [arg1 /local loc1 loc2][ loc1: loc2: none ... ] So, although the REBOL interpreter has no internal recognition of the /local refinement, perhaps it should. Of course, any such change has a minor impact on performance, although it should be unnoticeable. It might also be possible to compensate for the extra check by using /local to terminate the function arg parse. In other words, /local must be the last refinement within the function spec. Any other's that follow it will be ignored. Post your comments. We need to address this issue immediately. So, do you want RESET? http://www.rebol.net/r3blogs/0340.html http://www.rebol.net/r3blogs/0340.html no-spam@rebol.com (Carl Sassenrath) Sun, 10 Oct 2010 20:35:01 -0400 Long ago, in what seems like a galaxy far far away, REBOL had a reset function... it was a sort of warm-reboot that restarted REBOL without requiring the exe to be reloaded. This function was added because Jeff Kreis created an Apache web server module for REBOL, and it needed to run "fresh" for each new server request. Quite handy. Although I'm not considering adding such a function this week (there are higher priorities), I want you to think about it a little... and some of you guru's will recognize that such a function is actually on the road to multi-tasked REBOL environments. To add a function like reset we need to define the baseline to which the system resets. Then, everything below the baseline must be protected (immutable). Of course, some values, like the system object can be mutable and just get rebuilt as part of the reset. One method would be to use a checkpoint function that would clone a copy of the lib context and protect the entire base. The checkpoint allows you to import various modules and get things setup for your baseline, then mark that for rolling back to later. When the reset occurs, the user context would get cleared and the lib context would be reset to the check-pointed values. That way you have a fresh environment setup exactly how you want it. Of course, all data and functions below the checkpoint would need to be protected (made immutable), but the entire algorithm could probably be implemented in about a dozen lines of gurumezz code. In addition, we'd want the mutable parts of the system object to be rebuilt, but that's not difficult. So... the hard part is designing the base to be immutable. That is, functions and objects must not store state. But, wait... now you found me out! That's the same requirement needed for R3's lightweight multitasking model, isn't it? In essence, if we do one, we get the other (mostly) for free. Ok, why do I mention any of this? Because to move to beta, this is one big old check-box we need to mark off. The time is near. Keep it simple and clear. (Sorry... the Cabernet fermentation fumes must be getting to my head.) Battling the Module Monster, Again http://www.rebol.net/r3blogs/0339.html http://www.rebol.net/r3blogs/0339.html no-spam@rebol.com (Carl Sassenrath) Tue, 5 Oct 2010 09:47:36 -0400 Once again the R3 module subsystem has gotten between me and the next release -- specifically the A108 release. This has happened a couple times before on R3. Development becomes a fight... a fight between simplicity and complexity, between maintainability and chaos, between elegance and ugliness. So many operating systems and languages get it wrong. We don't want that here. Earlier prototypes worked well. They were functional, clean, and simple. Understandable. Some of you may be saying "Carl, we don't care." Yes, I know, I've heard that before. But, (if I had a Yoda voice, I'd use it here) you will care. You just don't know it yet. That's always what a good system designer struggles with -- anticipating the future. Anyway... I just wanted to give you an update on progress. A108 contains many fixes, and I didn't want it to be delayed much longer. However, with the split out of the system context, I want the module system to move into its final form. Also, as you know, Brian H has submitted some changes to help support delay modules, better versioning, mix-ins, etc. I'll keep hammering away on this... and see if we can get A108 released over the next few days.