http://www.rebol.com/cgi-bin/blog.r A few words from Carl Sassenrath, REBOL's inventor and leader of the X-Internet revolution. en-us Carl Sassenrath 2009 REBOL Messaging Language http://www.rebol.com/article/0413.html Carl Sassenrath <no-spam@rebol.com> Fri, 26 Jun 2009 11:56:21 -0700 To summarize recent development progress on REBOL 3.0, here is a chart of bug and wish tickets as posted to CureCode: =image photos/r3-tickets-0906.gif As you know, this is a non-trivial project, but progress is being made. I should also note that not all parts of R3 are represented by this chart. I would like to thank the members of the REBOL community for their active involvement in submitting high quality tickets and help with fixing these tickets. http://www.rebol.com/article/0412.html Carl Sassenrath <no-spam@rebol.com> Wed, 17 Jun 2009 21:54:09 -0700 Hopefully, a little captcha goes a long way. I've added a minimal method to this blog to help filter bogus comment postings. We'll see how smart the scrapers really are. We can always expand on it. It should be obvious what to do when you post. http://www.rebol.com/article/0411.html Carl Sassenrath <no-spam@rebol.com> Mon, 15 Jun 2009 12:41:24 -0700 Across the USA at midnight, the era of analog broadcast television ended. It lasted more than 60 years. Quite an achievement for any technology. I must admit, I have mixed feelings about this "advance" in technology. ---A bit nostalgic Sure, I'm somewhat nostalgic about the television business. I began working in TV at the age of 13, when I saw an announcement on a local PBS station (KEET 13), asking for volunteers. I rode my bicycle (because I was too young to drive) down to the TV station, and told the general manager, Don Telford, an older gentleman in his 60's, that I would like to work at the station. The manager looked at me over his eyeglasses, asked a few questions, then took a huge risk: he made me a "switcher" -- the person who runs the master control that puts programs on the air. He was a trusting man. It was a great job, and I loved doing it. After two weeks, he called me back into his office. "You are no longer a volunteer, " he said. "We are hiring you as an employee to run the master console every day." Two years later, at the age of 14, with the PBS experience as leverage, I managed to get a job at the ABC network station as a cameraman and film developer. And, thus began a passion for TV, including every facet of the business... from live news production, commercial production, film, video, engineering... I could not learn fast enough every job and opportunity at the station. A few years later, when I finally left to attend the university, I had worked my way up to the top production position at the station: director of the 6PM news, a live production that required fantastic concentration and timing. ---Understandable, therefore fixable One of the things I liked about those days is that you could learn, understand, participate, and contribute to every aspect of the technology and art. For example, when I was 14, working at PBS, the stations main color TV camera (large complex devices back then) stopped working, and had been pushed into the corner. The engineers told me something major was wrong, and it could not be fixed. Never being one to be discouraged, I worked on the camera during the less busy times of running the master console. Alone, using an oscilloscope, I worked on the camera for a several weeks, tracing the signals through the various subcomponents of its video circuitry. I finally discovered that the primary drive transistor for its cathode (the source of electrons for the beam that captures the image) was burnt out. A quick replacement, fixed the camera, and the station manager was delighted to have the color camera back on the air. (Rather than black and white). Anyway, I have a point here, beyond just the story. My point is, the technology, even in it's more complex domains (inside a TV camera) was understandable and workable. It wasn't beyond our grasp, as even demonstrated by a 14 year old boy. The same is not true for DTV. The modern digital world consists of several higher level components built on lower level technologies that are, frankly, extremely complex. While the complexity offers us nice features and capabilities, such as HDTV with Dolby 5.x sound... it removes us from the inner workings of the system itself. The result is, it becomes much more difficult to debug, and in some cases nearly impossible to work on. ---There is a hidden cost Sure, the DTV signal produces a great result; however, the cost of that result is that the signal and its processing is much more prone to ultimate failure. It's not a free advance. It comes at a cost -- one that's not so obvious. Some of you will challenge my statement, but I have a good example to prove my point. As a community service I volunteer a small amount of my time to help bring free over-the-air TV channels to the remote community where I live. On top of a nearby mountain we "capture" the distant signals from San Francisco and rebroadcast them to the town. The term is "translating". We run a series of "translators" that you can think of as repeaters or boosters. When TV was analog, these devices were fairly easy to understand and debug, but most importantly, they were robust. An analog signal consisted of three "carrier" frequencies that were modulated (AM and FM) with the content's video and audio. You could easily detect these signals, and if the signals degraded from interference or loss of signal strength, the content would still be "watchable". It might contain a bit of noise (static) or lines, but a viewer could still follow the program. Now, with DTV, you get either a perfect picture or not. It's either on or off. It works or it doesn't. And, what's worse, is that when it doesn't work, it can be quite difficult to figure out what's gone wrong. The signal can be too weak, too strong, distorted in some way (e.g. multipath), or interfered with (from some other signal). In addition, the DTV modulation itself is quite tricky to even detect with a simple device. If you look at a DTV signal with any analog device, you see noise. If you want to really examine the signal itself, you need an expensive device that is able to recognize the signal and help you debug what's going on. Of course, our small TV organization cannot afford the cost of such a device, so most of the time, we can only guess. ---Enslaving ourselves Although, I'm commenting here about DTV in general, what I'm saying applies to almost all modern technologies. It doesn't matter whether it's a DTV transmitter, enterprise server to run the local college, or even the metering device on your water line. We rarely stop to ask if the complexity involved is worth the benefit. In a very subtle way, we are enslaving ourselves to our technology. We are allowing layers and layers of additional complexity that far exceeds the abilities of most human "intuition" and "comprehension". Many years ago I predicted the economic collapse we are now experiencing worldwide. My prediction was not based on specific details of operation, but on the higher-level acceptance of complexity as "standard operating practice." When I saw friends graduating from MIT to work on Wall Street algorithms, I began feeling quite nervous about the future of our investment banking systems. Why? Because I knew that the executives and decision makers who ran these giant corporations would "blank out" and not understand, or even attempt to understand, how these systems work. And, as a result, without an engineer in the locomotive, we'd begin to see these trains begin to derail at every turn. When we separate ourselves from the systems that work on our behalf by adding layers and layers of complexity, we are ultimately doomed to fail. This applies to all domains, from insurance companies to medical systems to space vehicles to entire governments. The reason is quite clear. We (as humans) exist within a narrow band of comprehension and intuition. Once our systems grow too complex, we as humans no longer possess our essential "gut intuition" nor any idea at all how our monster system will react to unforeseen situations. Of course, this is one reason why I've taken a different direction in computing. But, you already know that. However, a lot more needs to be said about it. Anyway, enjoy DTV. It really is a nice picture. But, good luck figuring out that it is a harmonic mix from your neighbor's microwave oven that is glitching your HDTV football game or favorite movie. http://www.rebol.com/article/0410.html Carl Sassenrath <no-spam@rebol.com> Tue, 9 Jun 2009 15:05:25 -0700 Today I decided to try something new: To post some status notes on R3 chat, to help the developer base follow what's going on. (It's in 4474.) It was kind of an experiment. But, it soon became clear that these postings would create a lot of noise on the R3 Chat channels, which I value highly because they are zero noise. I keep R3 chat open at all times on all systems, and watch for anything important -- so keeping it low noise is critical (and ironically does not lead me to build a GUI for it any time soon.) A guess what I'm doing is really just tweeting (to use the current vernacular for this action.) It reminds me a lot like the old REBOL/IOS user status app that was useful for seeing what people were doing. I always thought that concept was useful, but I also thought I was the only one who thought that way. (Which is why it's so minimized in AltME.) Anyway... why not just open a twitter channel and keep the status noise off the R3 Chat? (Then magically within minutes, REBOLer Petr makes the same suggestion.) \note So, thus appears: twitter.com/rebol3 /note Well... it's really only for a few people anyway and maybe just for Petr. We will see. And, of course this is just experimental. So, no promises. Also, if anyone has a reblet that let's me directly post to my twitter channel, that would be very handy. I'm a little hyper about efficiency, so if I have to wait 10 seconds for a web page to open to post a tweet, I've already moved on to the next task. (That's why I was using R3, because it opens so quickly.) http://www.rebol.com/article/0409.html Carl Sassenrath <no-spam@rebol.com> Mon, 8 Jun 2009 14:21:17 -0700 ---During May: Progress on R3 jumped to a new level with five new releases and more than 100 bug and enhancement tickets fixed or implemented. This work was done with the dedication of the REBOL community, which has become much more active in R3 testing and the bug handling process. We would like to thank everyone who was involved. In addition, three of the main design components for plugins were implemented during the month. R3 is now loading DLLs (the mechanism used for plugins), scans for proper signature (REBOL header of specific type), and imports the plugin module specification (similar to normal modules). A new datatype was added that provides a special type of function used to interface between REBOL and plugin functions. As I mentioned in last month's report, it's been an interesting process. ---Goals for June It is essential to get the plugin system running this month. The priority of this task may not seem that obvious, so let me explain. I'm constantly thinking about how we can speed up the development process for R3. We need a greater level of parallel development of its features. Or, stated another way, I don't want to be the "bottleneck" for specific improvements (although I will continue to keep watch over all features, to be sure they adhere to the "REBOL way". Lean, but powerful.) Keep in mind that the plugin architecture enables more than just plugins. It also provides the interface mechanism for other features of the system, such as graphics, rich-text, networking, file I/O, codecs, encryption, and more. The same mechanism powers both external and internal components (but part of the open source host library), and that's what makes it such a high priority. We will also continue with bug fixing, but not at the same level of intensity as during May. For example, some improvements for math functions are already in the works, and other major bugs will get our attention. [Learn more about REBOL3] http://www.rebol.com/article/0408.html Carl Sassenrath <no-spam@rebol.com> Tue, 19 May 2009 11:38:39 -0700 That old expression, better late than never applies to this month's R3 progress report and plan. ---During April I'm not going to review the details of changes and enhancements made during April, because a full log can be found on the R3 Releases page. If you've not visited that page, it's worth looking at because you will see many advancements Be sure to note the major changes to the system object and in security. In this area, R3 has moved far beyond R2. In addition during April, we wrote and updated major sections of the new R3 Guide documentation, including the function sections. (But it goes without saying that much more is needed.) ---Goals for May First, we need to take some time out and catch up on bug fixes because the CureCode database is expanding rapidly. We need to "keep it sane" or "tame", whatever. The goal is to check-off 50-100 tickets a month in order to make decent progress. Of course, there are also "wish list" items, some of which we really need, and others that we must defer to later releases because we have more important, high priority items. Next, as some of you know, one of the top level goals has been to provide a greater level of external access from R3. That's mainly so you can contribute your own special features without us standing in your way. But, it's been taking some time to make this happen, and it's going to be necessary to divide it into a few stages. Here is the sequence I want to see happen: #Codec plugins - A subset of the plugin mechanism (below) that allows you to interface encoders and decoders. There's quite a lot you can do with these; however, they are a static model of plugins, with fewer design dependencies, so easier to release. #Plugins - These are full-capability plugins, meaning you can provide both lower level C functions as well as higher level REBOL functions, all within the same DLL module. This mechanism has been difficult to define because we want to provide proper isolation between the plugin and the kernel. Or, stated another way: if we do this wrong, we will end up with what is often called "DLL hell" where even minor changes in the kernel over time could "break" some or all of the plugins. I investigated using rebin (REBOL binary format) for the plugin interface; however, it's quite problematic. Rebin is an alternate lexical form for REBOL, good for data storage or exchange, but not efficient for in-memory structures where some degree of data sharing is desired. (For example, you don't want to clone an image each time you want to update it on a display.) The current solution appears to be a middle-ground, a mechanism I call commands that are similar to native functions, but produce a very specific interface frame (function args). If this works out, it may even be possible to replace the entire delect sub-language dialecting method with a more general mechanism that also includes embedded help, similar to functions. #Host-lib - These are the open-source modules included within R3. For example, the file, TCP/IP, event, and other devices (which support their respective port schemes) as well as the full graphics system. More than half the size of view.exe is within this code base and it provides the only path for good support over all target systems. #Host - The top level environment for R3, including its bootstrap, argument parsing, console handler, and more. This is also open source to allow us to add OS resource interfaces, build app wrappers/bundles, embedded boot code, to name a few of the possibilities. Not all of this can happen in May, but we need to make some level of progress on it in order to get the developer-base up to speed and moving forward in parallel to core-level development. [Learn more about REBOL3] http://www.rebol.com/article/0407.html Carl Sassenrath <no-spam@rebol.com> Fri, 10 Apr 2009 10:49:49 -0700 Sometimes I get so busy on design work that I don't take time to see other cool REBOL events and programs. Fortunately, my old friend Petr in Czech Republic will send me a note. Here's one he mentioned today. Here's a nice little syntax-coloring REBOL code viewer/editor that was posted recently on Google-sites by Steeve Logan: "Colorisation syntaxique" (Credit goes to Shadwolf and Steeve. Nicely done, but maybe needs a shorter name? For more, the project archive is hosted by Shadwolf at: my-trac.assembla.com/shadwolforge/wiki.) If you click on the link, you can see a few screen shots. And, the editor is only 50 KB (23 KB LMF, and only 7 KB MLFC!), so it's quick to download. Give it a try. I like the idea of REBOL-as-editor (as I'm sure I've said before.) Why in 2009 would I want that? Well, let's see... maybe I'm an idiot, but last time I tried to get Eclipse running, I gave up after... I'm not sure, maybe after the 40 MB Java engine update. I lost track and also lost interest. Many "modern" software developers and gurus think code editing systems (and IDEs) need to be large and complicated to get the job done. I do not. And, I think I'm not alone. (After all, how am I writing this blog? Is it with some fancy super-text-processor? No, in fact, it's a humble little HTML edit box. Really super-minimalist, but oh-so-convenient and gets the job done.) Anyway, when you integrate an editor with a language like REBOL, you can get some very productive results... with very little code. I think there's a lot we can do with it, because we bring the deep semantics of REBOL into play. When it's all done, yes, it might be 25 KB LMFC. A huge monster-of-a-program, no? And let's not forget, in theory, it will run across all major platforms. Where, I can install it in... what, 10 seconds? http://www.rebol.com/article/0406.html Carl Sassenrath <no-spam@rebol.com> Fri, 3 Apr 2009 13:08:22 -0700 First, let me say that we didn't follow the March plan that we outlined last month. ---Project review About mid-March we took a break and spent time on project management, reevaluating and reorganizing the detailed project list. What became obvious was that several lower level subsystems and functions should take priority over those I outlined in the March plan. For example, I've been very interested in seeing the next steps happen on the GUI system, but various sub-projects are necessary in order for that to happen. We needed proper support for decoders (codecs) for image loading, and module support for proper structure and isolation of the GUI's internal functions. (For example, the system/view object isn't supposed to be the global environment of the GUI system like it was in R2. The R3 GUI must exist in its own name space.) In addition there are subsystems like security that are rapidly growing in importance as more developers download R3 and try out scripts. So, together these create a development path that must be pushed to completion as quickly as possible, and that's really more of a focused goal now. ---During March: *Fixes to developer file-sharing overlapped into the first week of March, but we got it released! We uploaded source code modules for R3 mezzanines and the current R3 GUI system. It was encouraging to see developers download code, made useful changes and fixes, and submit them back into the system. All of that operating under REBOL scripts, with R3 processing it on the client side. *The submitted changes were integrated into new releases that were published toward the end of March. Sources within DevBase (RebDev) were accepted (tagged) to make them official, and the project is building momentum. *The module mechanism was released, including the new IMPORT function, proper isolation with changes to the RESOLVE function. The system object's module-path is now used for module searches, and programs loaded that contain NEEDS fields will preload their necessary modules, including version checks and SHA-1 hash validations of module contents. Finally, a modules section was added to the R3 Docs Concepts area. *A big milestone for us personally was running the first R3 CGI script on our main web server. This allows us to begin building backends now in R3, allowing us to build some testing time under those environments. *The R3 codecs (media decoders and encoders) subsystem was added and initial releases have been made with codecs for JPEG, GIF, PNG, and BMP. More work is still needed for optimizing and allowing special options and modes, but it's now at least something real. *The DECODE, ENCODE, and ENCODING? functions were added to support the interfaces into the codecs, and LOAD and SAVE were updated accordingly. You can once again LOAD a jpeg locally or over the net, and this is also important for the GUI and applications. *The ASSERT function was added, a very useful way to validate conditions and datatypes, and documentation for it was added. *Various important enhancements where made to LOAD, including loading of blocks and the /next feature, often used to translate REBOL in a stepwise fashion. Also, TRANSCODE was update to support these changes, with /next and /only refinements. *CONSTRUCT was improved to safely handle objects like REBOL/headers as well as to allow a raw mode via the /only refinement. *A better search mechanism was added to embedded HELP that gives users a better way to find related functions and features. The HELP /doc refinement was also added as a shortcut to the official online documentation pages. *Builds were made for R3 Core on OS X PPC and also changes were made to the default Linux builds. This change allowed us to run R3 now on all our primary servers. *More was done to improve the R3 documentation. Various sections were added, updated, and clarified. There's still a lot more to do. If you look at the timeline, the docs are by far the largest subproject remaining. ---Goals for April Right now, I have one primary goal for April: To get the detailed project list published, so you can review the list for yourself, make comments, and hopefully find ways to contribute toward its progress. At the top of that list is the project that I think must happen next: security. Although certainly many of developers know how to wrap R3 in a 3rd party sandbox for testing, it's not our intention that every user should need to do that. With more and more R3 programs, demos, and shared modules becoming available, the need to integrate security back in the core system has become even greater. This is a big step toward becoming Beta. http://www.rebol.com/article/0405.html Carl Sassenrath <no-spam@rebol.com> Tue, 31 Mar 2009 10:07:05 -0700 Whenever I hear about new computer viruses and worms on the attack, my mind drifts back a few decades... As a young OS kernel engineer at Hewlett Packard's Computer Systems Division, we had some core principles of computer science, known by all on the team, that we strictly applied to our operating system designs. For example, code, data, and stack segments where isolated; that is "firewalled". They were separate, hardware enforced areas of the memory map. You could not overflow a stack buffer into the code segment as a way to hijack the CPU. You'd segment fault first, and besides, the VM would not even let you map stack access into code segments. In addition, code segments were read-only. During execution, you didn't get to write into a code segment for any reason whatsoever. If you tried, the memory system would throw an exception faster than it could load the next instruction. (Only the highly privileged loader module could write a code segment, and while it did, it was just a data segment - you couldn't jump the CPU over to it.) ---That was 1980, folks. I can see some of you old-timers shaking your heads, "yep, that's how we did it." It didn't matter if you were an IBM-er, CDC-er, DEC-er, or Burroughs-er. You knew the principles. HP didn't invent most of those concepts. They were the well established, accepted design practices of the day. ---So, here we are 29 years later... And, we are all worried about the "conflicker worm"... in actuality, a threat that shouldn't even exist. And, what's the true danger here, is it really the worm? Companies, big and small, make a lot of money on these viruses and worms. OS companies, virus protection companies, computer system vendors, network operators and IT consultants... all win huge when a worm wrecks havoc on the net. Yes, I have to admit, I'm getting a bit jaded with age. You think there will be cure to the disease when patches make a lot more money? It's not just software. Do you think cancer will be cured when medicine makes billions on partial treatments? ---What's a computer user to do? Fortunately, there are alternatives, but you have to be willing to jump ship from your Windows insecurity blanket. I'm not concerned about conflicker affecting my Mac OS X or various Linux boxes. I think you guru folks know why. Although not perfect, those are more or less real operating systems built on some of those principles of the 1970's and 80's. (Old-timers: let's not debate here if Unix derivatives are real OSes... let's just admit that they are widespread now, ok?) Again, sorry if this sounds like I've spent too much time racking the wine barrels in the basement. Maybe it's all just par for the course these days... the way our technologies, industries, banks, and governments are headed. (Well, actually, they've pretty much already arrived.) Or, as I've learned long ago (from lawyers, if I dare say): It's not what you once knew to be the truth, it's what you pretend to know now that really matters. Well, personally, I don't buy that brand of dog food. But, the unaware eat it up. So, maybe I'm not the only one who's jaded?