Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Introducing REBOL/Base - FAQ

 [1/48] from: carl:s:rebol at: 28-Sep-2002 14:31


For those of you who are interested in trying new REBOL kernels... here's something to test out. It's the Alpha release of REBOL/Base. Q: What is REBOL/Base? A: REBOL/Base is a reduction of REBOL/Core trimmed down to the essential native and mezzanine functions and schemes. All protocols, help information, and functions are stripped, but can be added back on an individual basis. Q: Why would REBOL Tech build such a thing? A: REBOL/Base is designed for developers who want to create minimal REBOL environments and precisely control what functions they initialize. For instance, if you only need SMTP or HTTP, why take the time and space to boot all the other protocols? Q: Why are we releasing an Alpha test version? A: The idea of a REBOL subset is new and contrary to our rule that REBOL executables must include everything. We want to see what developers think of this idea. Q: Does REBOL/Base startup faster? A: Yes, because it has fewer mezzanine functions and schemes, it starts faster (good for stuff like CGI, etc.). Q: Does it take less memory? A: Yes, if you RECYCLE after booting, then type STATS you'll see that it takes about 0.578 MB. Most of this space is used by internal buffers, function spec blocks, critical mezz functions, and the word table. The executable file is 235 KB. Q: Does /Base include graphics functions? A: No. But, there will be a similar version of REBOL/View (as of yet unnamed, got any ideas?). Q: How can I see what's in it? A: Open REBOL/Core and type SOURCE WHAT. Cut and paste it into the REBOL/Base console, and type WHAT. Q: Where do I get source code for the missing modules, such as the TCP protocols? A: Currently, you can obtain the source from other versions of REBOL, although that may not be optimal in many cases. Later this Fall (2002) we will be announcing another product to help answer this question. But, that's all we can say right now. Q: Can I create stand alone executables with it? A: No. For that you need to purchase REBOL/Encap that includes /Base. All developers who have purchased Encap within the last 6 months will receive a free upgrade, including several new tools and modules. Q: Does REBOL/Base have any other changes? A: Other changes are related to boot memory usage. In addition, the STATS function now accurately reports REBOL memory in use, and MOLD now has a /FLAT refinement that removes indentation (handy for smaller messaging and encapsulation). Q: Why does it boot with a version of 2.6.0? A: To keep existing scripts that check the version number from stopping. Q: Where can I download REBOL/Base? A: If you agree to abide by the /Core license, you can download the /Base Alpha version from http://www.reboltech.com/downloads/ If you do not agree, then do not download it. Q: Where do I report bugs? A: http://www.rebol.com/feedback.html - please make a note that you are using REBOL/Base. Submit any other questions to http://www.rebol.com/feedback.html. ###

 [2/48] from: carl:cybercraft at: 29-Sep-2002 10:25


On 29-Sep-02, Carl at REBOL wrote:
> A: The idea of a REBOL subset is new and contrary to our rule that > REBOL executables must include everything. We want to see what > developers think of this idea.
Of the top of my head, I think this is a very good idea. Smaller and faster will always have a place.
> Q: Does /Base include graphics functions? > A: No. But, there will be a similar version of REBOL/View (as of yet > unnamed, got any ideas?).
REBOL/RGB - the base colors? -- Carl Read

 [3/48] from: tim:johnsons-web at: 28-Sep-2002 16:23


Hello All: * Carl Read <[carl--cybercraft--co--nz]> [020928 14:52]:
> On 29-Sep-02, Carl at REBOL wrote: > > > A: The idea of a REBOL subset is new and contrary to our rule that > > REBOL executables must include everything. We want to see what > > developers think of this idea. > > Of the top of my head, I think this is a very good idea. Smaller and > faster will always have a place.
Amen to Carl R. Now I know that Carl S. has a fantastic vision in rebol (and rebol is his baby and his creation). But as a programmer, who is interested in interoperability and who has partners who aren't that interested in the rebol vision, the concept of a lightweight interpreter has great merit with me and being interoperable with a minumum of fuss with things like MySQL,TK, gzip protocols, etc will have great merit with my partners. I'm not certain what that contrarian vision of a "rebol" subset would be, but from my isolated perch at the top of the world, those further south of me are saying that small devices will grow in implementation. Does that constitute a place for a "subset" of rebol? Here's a thought that occurs to me: My partner programs in perl. He's followed my interest in rebol and is of the opinion that rebol's built-in tcp has some merit in comparison to the external perl modules. I think that he would find some appeal in a rebol "subset" that would handle some of his tcp needs if the interface was simple. That way he wouldn't have to learn rebol... And he has seen what rebol sockets can do with MySQL.... thanks to DocKimbel.
> > Q: Does /Base include graphics functions? > > A: No. But, there will be a similar version of REBOL/View (as of yet
<<quoted lines omitted: 6>>
> [rebol-request--rebol--com] with "unsubscribe" in the > subject, without the quotes.
-- Tim Johnson <[tim--johnsons-web--com]> http://www.alaska-internet-solutions.com http://www.johnsons-web.com

 [4/48] from: chalz:earthlink at: 28-Sep-2002 20:46


> Q: Why would REBOL Tech build such a thing?
I smell "Dr. Strangelove" in that question ;) Sorry. Feel free to return to topic.

 [5/48] from: brett:codeconscious at: 29-Sep-2002 11:56


> For those of you who are interested in trying new REBOL kernels... here's
something to test out. It's the Alpha release of REBOL/Base. Thanks Carl!
> A: REBOL/Base is a reduction of REBOL/Core trimmed down to the essential
native and mezzanine functions and schemes. All protocols, help information, and functions are stripped, but can be added back on an individual basis. A few unsets have been trimmed too.
> A: REBOL/Base is designed for developers who want to create minimal REBOL
environments and precisely control what functions they initialize. For instance, if you only need SMTP or HTTP, why take the time and space to boot all the other protocols? An excellent idea. On my very specific measure of start up time, it takes roughly half the time of Core which takes half the time View. Regards, Brett

 [6/48] from: anton::lexicon::net at: 29-Sep-2002 12:00

REBOL/Eye - was: Introducing REBOL/Base - FAQ


How about REBOL/Eye, sort of... "one-eyed view", as opposed to the stero vision we have with the full view. Anton.

 [7/48] from: james:mustard at: 29-Sep-2002 14:29


> How about REBOL/Eye, sort of... "one-eyed view", > as opposed to the stero vision we have with the > full view. >
How about REBOL/Glance ? A Quick View? :-) James.

 [8/48] from: laurencegiddings::mac::com at: 29-Sep-2002 11:13

Re: Introducing REBOL/Base - FAQ


On Sunday, Sep 29, 2002, at 07:31 Australia/Melbourne, Carl at REBOL wrote:
> Q: Does /Base include graphics functions? > > A: No. But, there will be a similar version of REBOL/View (as of yet > unnamed, got any ideas?).
REBOL/Baseview might be a good name..... it would certainly identify/associate the minimalist functionality of the two code sets, to avoid confusion.

 [9/48] from: anton:lexicon at: 29-Sep-2002 13:31

Re: REBOL/Eye - was: Introducing REBOL/Base - FAQ


Yeah, I like Glance better than Eye. Eye is shorter, though... Anton.

 [10/48] from: tomc:darkwing:uoregon at: 29-Sep-2002 0:58

Re: Introducing REBOL/Base - FAQ


On Sat, 28 Sep 2002, Carl at REBOL wrote:
> Q: Does /Base include graphics functions? > > A: No. But, there will be a similar version of REBOL/View (as of yet unnamed, got any ideas?).
REBOL/Squint

 [11/48] from: tomc:darkwing:uoregon at: 29-Sep-2002 1:10


On Sat, 28 Sep 2002, Carl at REBOL wrote:
> Q: Does /Base include graphics functions? > > A: No. But, there will be a similar version of REBOL/View (as of yet unnamed, got any ideas?).
REBOL/Spy

 [12/48] from: anton:lexicon at: 29-Sep-2002 18:34


REBOL/Photon Anton.

 [13/48] from: anton:lexicon at: 29-Sep-2002 18:40


REBOL/Focus ... err, sounds like a magazine, maybe REBOL/Focal REBOL/Compound - like an insect's compound eye, and like a rebol military base ! REBOL/Diamond or REBOL/Gem - small and pretty to look at REBOL/Glitter Anton.

 [14/48] from: al:bri:xtra at: 29-Sep-2002 21:03


Carl wrote:
> We want to see what developers think of this idea.
I think it's a great idea for CGI programs. Just tried it out on my Wiki, and it's noticably quicker to deliver pages to the browser. Andrew Martin ICQ: 26227169 http://valley.150m.com/

 [15/48] from: al:bri:xtra at: 29-Sep-2002 21:01


> A: No. But, there will be a similar version of REBOL/View (as of yet
unnamed, got any ideas?). Rebol/Light Andrew Martin ICQ: 26227169 http://valley.150m.com/

 [16/48] from: al:bri:xtra at: 29-Sep-2002 20:54


> A: No. But, there will be a similar version of REBOL/View (as of yet
unnamed, got any ideas?). Rebol/Window :) Andrew Martin ICQ: 26227169 http://valley.150m.com/

 [17/48] from: anton:lexicon at: 29-Sep-2002 19:49


REBOL/Shades :) or /Shards :D Anton.

 [18/48] from: chris:ross-gill at: 29-Sep-2002 6:35


REBOL/Canvas REBOL/Paper REBOL/Base/View REBOL/Idea REBOL/Blocks REBOL/Face
> Q: Does /Base include graphics functions? > > A: No. But, there will be a similar version of REBOL/View (as of yet
unnamed, got any ideas?). - Chris

 [19/48] from: rebol:compkarori at: 29-Sep-2002 5:56


-- Unable to decode HTML file!! --

 [20/48] from: joel:neely:fedex at: 29-Sep-2002 7:56


IIRC Photon is the name of the GUI environment for QNX. -jn- Anton wrote:
> REBOL/Photon > Anton.
<<quoted lines omitted: 11>>
> [rebol-request--rebol--com] with "unsubscribe" in the > subject, without the quotes.
-- ; Joel Neely joeldotneelyatfedexdotcom REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] { | e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]

 [21/48] from: petr:krenzelok:trz:cz at: 29-Sep-2002 16:03

even further ... Re: Introducing REBOL/Base - FAQ


Hello CArl, Carl at REBOL wrote:
>For those of you who are interested in trying new REBOL kernels... here's something to test out. It's the Alpha release of REBOL/Base. > >Q: What is REBOL/Base? > >A: REBOL/Base is a reduction of REBOL/Core trimmed down to the essential native and mezzanine functions and schemes. All protocols, help information, and functions are stripped, but can be added back on an individual basis. > >Q: Why would REBOL Tech build such a thing? > >A: REBOL/Base is designed for developers who want to create minimal REBOL environments and precisely control what functions they initialize. For instance, if you only need SMTP or HTTP, why take the time and space to boot all the other protocols? >
Why would that be needed? CGI? CGI is outdated anyway ;-) What else ... PDAs, set-top-boxes, simply devices with limited resources? If so, sounds interesting ....
>Q: Why are we releasing an Alpha test version? > >A: The idea of a REBOL subset is new and contrary to our rule that REBOL executables must include everything. We want to see what developers think of this idea. >
Are you sure the idea is new? :-) I would even go further, stating that REBOL/Base should become real kernel, even for native mode stuff. Rebol components - not quite an new idea - we talked about it here several times already. I think that having everything in one .exe is not maintainable for Rebol future direction. What if there is need for .mp3 or .divx support? What if such support would require 300kb space? Will RT add it, or will RT say that it will not be added, as it would add significant increase to executable size? The problem becomes more evident with stuff like Rebol/player ... simply e.g. browser-plug-in like product. RT will release update (or just patch some bugs) - will clients be pushed to download whole new rebol.exe because of that? With current model - they will, and that's wrong aproach. Maybe not nowadays for 56k modem connection, but if you think of your mobile device and rebol.exe of some 1.5mb size - then it is. If I understand it correctly, rebol components as can be seen in system structure, are separated already ... what if I am not interested in /odbc, /library, /sound, etc? Why should those be in my rebol.exe and push my clients to download them if not needed? OTOH there should be some option to specify something like: if not component? 'sound [go-download-it!] Such aproach would even imo better allow RT to structure sales, prices, create some package combinations etc. If there is still someone scared of so called .dll hell, so RT introduced Rebol preprocessor to us. Simply put - create package of stuff you need and distribute as one file, if you need ... Carl, I would like to know your opinion on that, as that is the future of Rebol as I can see it. We can't refuse to support new technologies forever, just because it would add some space to our rebol.exe ;-) What do others think about it?
>A: No. But, there will be a similar version of REBOL/View (as of yet unnamed, got any ideas?). >
as above - go further - isolate View and other components of Rebol/Base and create real plug-in component architecture. Add ability to create packages for those who are scared of rebol being scattered over their hd ;-) -pekr-

 [22/48] from: g:santilli:tiscalinet:it at: 29-Sep-2002 16:30

Re: Introducing REBOL/Base - FAQ


Hi Joel, On Sunday, September 29, 2002, 2:56:30 PM, you wrote: JN> IIRC Photon is the name of the GUI environment for QNX. Indeed. Probably the best option is REBOL/Faces, since it will lack VID etc. and will only have raw faces to play with. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [23/48] from: greggirwin:mindspring at: 29-Sep-2002 12:28

Re: even further ... Re: Introducing REBOL/Base - FAQ


Hi Pekr, I'm not scared of DLL Hell, I'm *terrified* of it. :) << Carl, I would like to know your opinion on that, as that is the future of Rebol as I can see it. We can't refuse to support new technologies forever, just because it would add some space to our rebol.exe ;-) What do others think about it? >> I think there are a number of issues that RT has to wrestle with regarding this topic. I certainly believe in the value of libraries (i.e. precompiled components) but one of the best things about REBOL is the ability to distribute a single EXE with no other dependencies. DLLs and shared components can be both a blessing and a curse. In a controlled environment, where you have a team building a large system, using libraries is enormously beneficial, IMO. OTOH, I can't tell you how much time I, and people I know, have wasted on DLL/OCX compatibility issues. It's kind of like the arguments for, and against, open source in some ways. If you write software that has to work across multiple versions of components/OSs, just checking what's there becomes a big task in itself. QuickBASIC/BasicPDS supported a thing called a "Quick Library" (.QLB). It was a compiled set of procedures that was like a static LIB, but had some extra info so it could be loaded into the QBX (their name for the IDE) where you could see all the routine names, etc. just as if they were included as source. You couldn't see the source for them because they were compiled. The compiler would create a LIB file at the same time as the QLB, so you could compile your app for deployment as a standalone EXE. Unfortunately, there's a whole range of desires and requirements that change along with the size and intended use of a product (read project). How do you keep things simple for the guy who wants to write shareware games but also allow the government, NASA, big commercial software vendors, etc. to construct large, complex systems that are life and mission critical? Can it run on everything from a PDA to a clustered supercomputer? Will it still be portable? What are the features that are most important? I'm digressing a bit :), but I guess my thinking is that we all have a different set of needs and desires. Can it still be simple, support all of them, and still retain all the attributes that make it special today? I think Carl and RT probably have a lot of things mapped out about how this all fits into their vision, and maybe some stuff doesn't. I believe they know how important it is to balance the development and deployment aspects, based on how REBOL works today. What I hope for is a compact kernel, like today, that you can easily build upon to incorporate the feature set you need in a consistent manner. I think that's how they build Core, View, Command, IOS/Serve, and IOS/Link today. Having an option to release, or even just use, precompiled libraries is not much different than LOADing and DOing external scripts today. What I hope doesn't happen is for REBOL to become like some other languages that are really only good for programmers because it just requires too much effort to set them up, use them, and learn about how things work. --Gregg

 [24/48] from: gscottjones:mchsi at: 29-Sep-2002 13:44


From: "Gregg Irwin"
<snip> > What I hope doesn't happen is for REBOL to become like > some other languages that are really only good for > programmers because it just requires too much effort to set > them up, use them, and learn about how things work.
I'll make that a "motion," and second it! :-) --Scott Jones

 [25/48] from: greggirwin:mindspring at: 29-Sep-2002 13:14

Re: Introducing REBOL/Base - FAQ


<< A: No. But, there will be a similar version of REBOL/View (as of yet unnamed, got any ideas?). >> FACE - pretty obvious DASH - move quickly, a small amount, haberdash (as in "to clothe") Other words I thought about, like FACIA, FACADE, COAT, COVER, LOOK, SEE, VISAGE, FORE, and FRONT, just didn't sound like good product names when I said them out loud. --Gregg

 [26/48] from: tomc:darkwing:uoregon at: 29-Sep-2002 13:50


(after a bit of much needed sleep) REBOL/Scene REBOL/Vision REBOL/Sight REBOL/Recon Rebol/Survey REBOL/Vista REBOL/Peek On Sun, 29 Sep 2002, Tom Conlin wrote:

 [27/48] from: bmuangkhot:ya:hoo at: 29-Sep-2002 22:58


Hi Gregg et Al, < A: No. But, there will be a similar version of REBOL/View (as of yet
> unnamed, got any ideas?). >> > FACE - pretty obvious
<<quoted lines omitted: 3>>
> said them out loud. > --Gregg
What's about Rebol/Beam (like Energy's beam from Rebol/base ;-)) Brice.

 [28/48] from: gchiu:compkarori at: 30-Sep-2002 10:03


On Sun, 29 Sep 2002 16:30:28 +0200 Gabriele Santilli <[g--santilli--tiscalinet--it]> wrote:
>Indeed. Probably the best option is REBOL/Faces, >since it will >lack VID etc. and will only have raw faces to play with.
Hi Gabriele, Why not REBOL/raw then ? At present the other suggestions don't convey the message to the uninitiated that this is a cut down offering like /raw does. And in going with the rebol theme ... raw == raw recruit -- Graham Chiu

 [29/48] from: gchiu:compkarori at: 30-Sep-2002 10:07

Re: even further ... Re: Introducing REBOL/Base - FAQ


On Sun, 29 Sep 2002 16:03:49 +0200 Petr Krenzelok <[petr--krenzelok--trz--cz]> wrote:
>Are you sure the idea is new? :-) I would even go >further, stating that REBOL/Base should become real >kernel, even for native mode stuff. Rebol components -
I'd vote for that. -- Graham Chiu

 [30/48] from: anton::lexicon::net at: 30-Sep-2002 8:51

REBOL/Beam - RE: Re: Introducing REBOL/Base - FAQ


Yep, I like that. REBOL/Beam - short and sweet. Anton.

 [31/48] from: carl:cybercraft at: 30-Sep-2002 11:13

Re: Introducing REBOL/Base - FAQ


On 30-Sep-02, Gabriele Santilli wrote:
> Hi Joel, > On Sunday, September 29, 2002, 2:56:30 PM, you wrote: >> IIRC Photon is the name of the GUI environment for QNX. > Indeed. Probably the best option is REBOL/Faces, since it will > lack VID etc. and will only have raw faces to play with.
Yes, or REBOL/Face as Gregg suggests. And Face rhymes with Base, whereas Faces doesn't, and could be mistaken for another word if said or listened to lazily. (; I second "REBOL/Face". -- Carl Read

 [32/48] from: mh983:attbi at: 29-Sep-2002 18:32

Re: even further ... Re: Introducing REBOL/Base - FAQ


Why not have one version but allow for removing components? Then the average user just has one downlad and no work to do, but 'power' users can customize their install to trim it for their specific purposes. At least you'd know that most people could run your script without additional effort. And the assumption would be if you knew enough to remove a component, then you'd know enough to put it back if you wanted to run a script that required it. 9/29/2002 1:44:05 PM, "G. Scott Jones" <[gscottjones--mchsi--com]> wrote:

 [33/48] from: carl:cybercraft at: 30-Sep-2002 17:17


On 30-Sep-02, Mike Hansen wrote:
> Why not have one version but allow for removing > components? Then the average user just has one
<<quoted lines omitted: 6>>
> to put it back if you wanted to run a script that > required it.
That's the nicest idea I've heard so far. Just have the executable accept two optional arguments, the first to tell it to run in lite mode and the second being a list of the components to load. -- Carl Read

 [34/48] from: petr:krenzelok:trz:cz at: 30-Sep-2002 7:35


Carl Read wrote:
>On 30-Sep-02, Mike Hansen wrote: >>Why not have one version but allow for removing
<<quoted lines omitted: 12>>
>accept two optional arguments, the first to tell it to run in lite >mode and the second being a list of the components to load.
it can be nice idea, but the purpose is as follows - I want to have an option to download e.g. Sound 1.2.3 component upgrade, I use my cell phone connected to my PDA and I am not interested in downloading whole Rebol just because some bug was fixed in Sound component. So - one file? Good, but there would have to be the option to replace rebol.exe's Sound component by new one :-) -pekr-

 [35/48] from: carl:cybercraft at: 30-Sep-2002 20:47


On 30-Sep-02, Petr Krenzelok wrote:
> Carl Read wrote: >> On 30-Sep-02, Mike Hansen wrote:
<<quoted lines omitted: 21>>
> component. So - one file? Good, but there would have to be the > option to replace rebol.exe's Sound component by new one :-)
And a full-featured REBOL/View exe may get quite large over the years and require a few megs of disk-space. But Mike's idea would be an option for those who don't have space worries but still need to run a lite-version of REBOL now and then. And you can run Base (or Face or Beam or whatever) on your cell-phone - since it's here now anyway. (: -- Carl Read

 [36/48] from: petr:krenzelok:trz:cz at: 30-Sep-2002 11:17


Carl Read wrote:
>On 30-Sep-02, Petr Krenzelok wrote: >>Carl Read wrote:
<<quoted lines omitted: 5>>
>lite-version of REBOL now and then. And you can run Base (or Face or >Beam or whatever) on your cell-phone - since it's here now anyway. (:
In few years, native to mezzanine level ratio will be 90:10 imo .... once we get all those .mp3, .avi, etc support - there will be just few mezzanine level functions to support those, while the rest will be present in native mode in .exe itself. So, we will talk about it once again as you will be pushed to download 2meg new rebol.exe, just because of one of components, which just takes some 100kb or so .... I am not pushing RT to do it right now. Rebol/base is good indication they do care about efficiency. We mostly can't run Rebol on most of current mobile devices, but once the time will come, better granularity is always a win, if done in a clever way ... -pekr- -pekr-

 [37/48] from: gchiu:compkarori at: 30-Sep-2002 23:17


On Mon, 30 Sep 2002 11:17:50 +0200 Petr Krenzelok <[petr--krenzelok--trz--cz]> wrote:
>I am not pushing RT to do it right now. Rebol/base is >good indication they do care about efficiency. We mostly
I wonder if it will get small enough to allow a Palm port. -- Graham Chiu

 [38/48] from: kemp:extelligence at: 30-Sep-2002 9:53


I would normally agree with the statements below as well, except that 'REBOL is not C'. By that I mean that REBOL is more of a platform or environment than simply a language, and I believe that RT's approach of 'chunky' releases better suits the platform approach. You can depend on certain features ALWAYS being in certain releases. Additionally, just how much optimization do you want - REBOL is only 500K, unheard of these days.
> > cell phone connected to my PDA and I am not interested in > > downloading whole Rebol just because some bug was fixed in Sound > > component. So - one file? Good, but there would have to be the > > option to replace rebol.exe's Sound component by new one :-)
I think for most people that downloading and installing ALL of REBOL will take vastly less time than downloading a one-liner and replacing it in a given environment. :0 For embedded and dedicated apps, /Encap should strip out unused code and minimize size, not the /releases themselves. /Face Kemp

 [39/48] from: greggirwin::mindspring::com at: 30-Sep-2002 9:32


<< I wonder if it will get small enough to allow a Palm port. >> Probably not unless Palm OS allows more memory for applications. I think they said once that it only gives them something like 96K to work in. Does anyone know of other interpreters that run on Palm for comparison? --Gregg

 [40/48] from: gscottjones:mchsi at: 30-Sep-2002 9:41


From: "Kemp Watson"
> For embedded and dedicated apps, /Encap should strip out > unused code and minimize size, not the /releases themselves.
I would encourage you to send that clever idea to feedback!!! Wouldn't want it to get lost in the sea of other naming choices. Good going, Kemp! --Scott Jones

 [41/48] from: gscottjones:mchsi at: 30-Sep-2002 11:12


From: "Graham Chiu"
> << I wonder if it will get small enough to allow a Palm port. >>
From: "Gregg Irwin"
> Probably not unless Palm OS allows more memory for applications. I think > they said once that it only gives them something like 96K to work in. > > Does anyone know of other interpreters that run on Palm for comparison?
An older version of Tcl (7.6) has apparently been ported to Palm. http://palm-tcl.sourceforge.net/ which is curious, given that base Tcl is larger than REBOL. My guess is that REBOL "expands" into the memory space far more than this older Tcl version, but I do not know the actual facts. Apparently, it avoids Tk, and uses the Palm OS "forms" for its gui stuff. Since I had the documentation open, I copied the following for the curious about what this looks like. Of, Course, I am wondering if a stripped REBOL, only essentials added back, could do a similar thing. Here is a prototype resource file for a form. FORM ID 500 AT (0 0 160 160) MENUID 550 NOFRAME BEGIN TITLE "Palm TCL Demonstration" FIELD ID 501 AT (10 20 140 80) FONT 0 NONEDITABLE MULTIPLELINES SCROLLBAR ID 502 AT (150 20 7 80) VALUE 0 MIN 0 MAX 0 PAGESIZE 0 BUTTON "User Interface Demo" ID 503 AT (40 120 AUTO AUTO) FONT 0 BUTTON "Address Book Demo" ID 504 AT (40 140 AUTO AUTO) FONT 0 END And here is the Tcl script that loads, unloads, and displays the form: set form [form load 500 -menucmd {menuproc %W %S}] $form set 501 {This is a simple demo} $form itemconfig 503 -command {%W unload; loadnextform} $form display Interesting! REBOL/Base/Palm or REBOL/Palm --Scott Jones

 [42/48] from: gerardcote:sympatico:ca at: 30-Sep-2002 13:54

Re: Introducing REBOL/Base - FAQ


Hi List,
> Gabriele Santilli <[g--santilli--tiscalinet--it]> wrote: > > > >Indeed. Probably the best option is REBOL/Faces, > >since it will > >lack VID etc. and will only have raw faces to play with. >
----- Replied Message ----- From: "Graham Chiu" <[gchiu--compkarori--co--nz]> To: <[rebol-list--rebol--com]> Sent: Sunday, September 29, 2002 6:03 PM Subject: [REBOL] Re: Introducing REBOL/Base - FAQ
> At present the other suggestions don't convey the message > to the uninitiated that this is a cut down offering like ...
I must agree with this pov, since like everybody I always want to limit the search for what is the meaning of some new product when I can do something more obvious, that is reuse some old good scheme/name that already exists: This is why I agree with other suggestions already done or suggest some myself that go in this way : Since the original product are named respectively : REBOL/Core and REBOL/View Why don't we simply use them like adding some prefix or suffix to them (like Light or Base) instead of reinventing the wheel. this could give us some easy to remember and short things to use ( for refs. too if we only keep the initials) : So the use of any of the following suggested names for the new REBOL/Core diminutive (even instead of REBOL/Base) would be better for me : REBOL/LightCore (REBOL/LC) or * REBOL/CoreLight (REBOL/CL) or * preferred for myself but looks like some commercial ad for ============= the "Coors Light" Beer sold here in Canada. Huh! REBOL/BaseCore (REBOL/BC) or REBOL/CoreBase (REBOL/CB) or * another acceptable alternative... * REBOL/SmallCore (REBOL/SV) or * another of my preferred - retained for consistency matter with ============= the following /SmallView one. REBOL/CoreSmall (REBOL/CS) or in an ultimate renaming try may be I could find "REBOL/Native" as acceptable as is the new REBOL/Base appellation suggested by Carl. ========== And the same vein, the use of any of the following suggested names for the new REBOL/View diminutive would be better for me : REBOL/LightView (REBOL/LV) or * REBOL/ViewLight (REBOL/VL) or * not my preferred one but retained for consistency matter with ============= the above /CoreLight one. REBOL/BaseView (REBOL/BV) or REBOL/ViewBase (REBOL/VB) or * an acceptable alternative but this time it looks like another add for the Microsoft's VB concurrent . Huh! Huh! * REBOL/SmallView (REBOL/SV) or * preferred for myself but looks like some commercial ad for another ============= VISUAL something contender REBOL/ViewSmall (REBOL/VS) * not my preferred one but retained for consistency matter with the above /CoreLight one. or in an ultimate renaming try may be I could find "REBOL/NativeView" or the suggested name of REBOL/Faces ============== ========== as acceptables ones to me. but final choice is Carl's privilege I think ! Sorry for the lengthy process ... Regards, Gerard

 [43/48] from: atruter:hih:au at: 1-Oct-2002 9:36

Re: even further ... Re: Introducing REBOL/Base - FAQ


> For embedded and dedicated apps, /Encap should strip out unused code and
minimize size, not the /releases themselves. Could not agree more. Leaving the naming issues aside, it seems that three broad "flavours" of REBOL are being discussed: 1. code writers - Full development environment 2. reblet users - Expandable "player" 3. app users - Binary produced by 1) or an addition to 1) (aka Encap) I don't consider Encap a "version" of REBOL per se as it is not a stand-alone environment. It instead takes the output of 1) to create 3). Regards, Ashley

 [44/48] from: zokie:libero:it at: 2-Oct-2002 22:08


Hello Gregg On 29-Set-02, Gregg Irwin wrote:
> Hi Pekr, > > I'm not scared of DLL Hell, I'm *terrified* of it. :)
Carl is AmigaOS' main designer, and AmigaOS is heavly based on "dynamic linked library", and none has encountered trouble with them. M$ is another thing! Rebol yet today is modular, even if it is stuffed into one executable. Untill today Rebol/Core was the little brick to build a big environment, now RT has introduced Rebol/Base and a set of external module, which together make Rebol/Core, but they release only Rebol/Base and we must add external module if needed, I think it is uncomfortable. I like Petr's idea to make them downloadable if needed, all we need is to setup a new directory to use as a buffer, i.e. plugins, and a special command to check if the module is yet loaded or not. Before to download plugin command checks plugins diretory to find if it is present a local copy and if it has the rigth version tuple elsewere dowloads it from specified URL. Time ago, I had done something similar to autoupdate a program of mine. For example a Rebol script may be like this: REBOL [] plugin http://www.rebol.com/downloads/view.r 1.2.0 ; We need at least 1.2.0 plugin http://www.rebol.com/downloads/smtp.r ; We need any SMTP protocol version plugin/platform http://www.xyz.com/mp3decoder platform? ; We need any version for platform on which script is running ... We may use recursion to make life easy :) So if View module needs Core module it will be automaticaly downloaded: REBOL [] plugin http://www.rebol.com/downloads/core.r 1.0.0 ; We need at least 1.0.0 and so on...
> DLLs and shared components can be both a blessing and a curse. In a > controlled environment, where you have a team building a large system, > using libraries is enormously beneficial, IMO. OTOH, I can't tell you how > much time I, and people I know, have wasted on DLL/OCX compatibility
Amiga's libraries adopt this trick: if version 1.0 has these procedure: a, b, c The next library version MUST have old a, b, c procedure and add newest ones. A, b, c may be remapped on newst ones, but their entry point must be not removed, M$ doesn't adopt this trick ;)
> What I hope doesn't happen is for REBOL to become like some other > languages that are really only good for programmers because it just > requires too much effort to set them up, use them, and learn about how > things work.
Modularized Rebol will be good even for rookie ;) Regards -- "Where did you get all those facts!?!"

 [45/48] from: greggirwin:mindspring at: 3-Oct-2002 10:53


Hi Francesco, << Carl is AmigaOS' main designer, and AmigaOS is heavly based on "dynamic linked library", and none has encountered trouble with them. M$ is another thing! >> Yes, it's not the concept of a DLL that I don't like, but how distribution is handled (or allowed), what regression testing is done for compatibility, etc. Another big distinction is that of libraries that are shared by many apps, as well as the OS, versus each app (or suite of apps, etc.) having their own version of a library that affects only them. << Amiga's libraries adopt this trick: if version 1.0 has these procedure: a, b, c The next library version MUST have old a, b, c procedure and add newest ones. A, b, c may be remapped on newst ones, but their entry point must be not removed, M$ doesn't adopt this trick ;) >> With COM you can define the interface and then ensure that the original interface is always supported in future versions through typelib versioning. This, in itself, isn't a perfect solution. I built a set of DLLs for a client who then modified them as time went on. Occasionally they would see a problem and attempt to solve it by turning off compatibility checking (this is in VB) which, of course, only caused many more problems as the ripple effect kicked in and more pieces had to be re-built to match the new interface IDs being generated. DLLs aren't the problem of course. People are. :) I *love* reusable libraries of code! I couldn't live without them. The question is, how to make it work? Because of the way REBOL works, we're probably going to be seeing apps that are built of many small pieces which may change dynamically. Whether the concept of Web Services takes off or not, the world is different now. With REBOL, it's about communication (messaging). We don't have to use components and libraries as we have, historically, with other langugages. We need a good model that is simple, flexible, and robust. Lots of details to consider on that front. In any case, RT seems to have a plan. They released /Base and Carl said they want to know what we think, so let's keep thinking and telling them. He also said another tool would be forthcoming to help with including the pieces they took out, so I think they have something in mind about how to handle this. What do *I* want as a developer? I want to be able to send out a single EXE, that isn't dependent on anything that might be changed for the OS or another app. External pieces I ship should not be used by anyone else, so I can handle them however I want. If I break my own app, that's my fault. If I deploy a script, either it's targeted at REBOL developers, sysadmins, etc. who know how this stuff works, or it's for users. If it's for users, there needs to be a single interpreter/runtime that is used for everything (IMHO). E.g. under Windows, .r files will be associated with rebol.exe and that version of rebol needs to be able to run every script they might get. This doesn't fit very well with the current model though. Keep brainstorming! --Gregg
> What I hope doesn't happen is for REBOL to become like some other > languages that are really only good for programmers because it just > requires too much effort to set them up, use them, and learn about how > things work.
Modularized Rebol will be good even for rookie ;) Regards -- "Where did you get all those facts!?!"

 [46/48] from: pwoodward:cncdsl at: 3-Oct-2002 13:58


----- Original Message ----- From: "Petr Krenzelok" <[petr--krenzelok--trz--cz]>
> Are you sure the idea is new? :-) I would even go further, stating that > REBOL/Base should become real kernel, even for native mode stuff. Rebol
<<quoted lines omitted: 4>>
> RT add it, or will RT say that it will not be added, as it would add > significant increase to executable size?
Some bits-and-pieces are already located in .r file, but most of the stuff is "encap"ed into the main .exe. But, you're right, when you start looking at multimedia codecs it would be very handy if those could be located outside of the main executable. If small enough, it makes sense to build them in - but when they get large (or there are a lot of them) it would probably make sense to externalize them in some fashion.
> If I understand it correctly, rebol components as can be seen in system > structure, are separated already ... what if I am not interested in
<<quoted lines omitted: 4>>
> Such aproach would even imo better allow RT to structure sales, prices, > create some package combinations etc.
I somewhat agree with this. I think the standard distribution should include as much functionality as possible (the current configurations are pretty much ideal). However it might make sense to defer loading of some modules until they are actually needed. Not so much a "download" of the module, but rather a delayed loading of modules which are already resident on the system running REBOL. The load and install of modules (sound, odbc) should be transparent to the script writer - no need to "include" or import the library. The first time their script hits HTTP, the appropriate network protocol is loaded. This makes the first time you fetch a web page take a second or so longer, but subsequent calls would use the memory resident module. Another change that might work out well is a config.r file that allows you to specify which modules to pre-load on startup. If you know you're using VID components alot, or ODBC, or whatever, load them right away. REBOL Tech could include a number of defaults, as well as some sort of "download" mapping for modules which are not part of a standard install. So, MP3, or other codec type functionality could be downloaded if needed...
> If there is still someone scared of so called .dll hell, so RT > introduced Rebol preprocessor to us. Simply put - create package of > stuff you need and distribute as one file, if you need ...
Essentially I think the directory structure of the REBOL install needs some strengthening. By adding a few more directories to manage modules/components. RT could have a standard installation directory structure that is created. By externalizing some components, they could be updated seperately - /Core essentially becomes the standard library (much like Java). /Base becomes the language processor, and /Core is an overlay on top of that. The /Core library mapping could be provided by a single .r file which would provide the "flavor". It would name the standard protocols and extensions, but loading the code could be deferred until such functions are actually called by a running script. I would definitely like to avoid include/import type statements for scripts for /Core functionality though. Extended, non-core functionality certainly could use a "requires" or other directive. Additionally something like requires could be used to specify a version of /Core functionality. Another thing that might be useful for RT is to consider the /Core flavor definition to include some deprecation mapping. If certain types of features are to be retired (do to a poorly thought out initial implementation or whatnot) then they could be put into a deprecated list - still available, but a script could generate "deprecation" warnings then. And, eventually maintainers could update their script. I know this probably sounds like a lot - and a lot of it is inspired by Java and .Net. While REBOL may do a lot differently, and more easily than those two component models, it doesn't mean that we can't learn from them. - Porter

 [47/48] from: petr:krenzelok:trz:cz at: 3-Oct-2002 22:08


Gregg Irwin wrote:
>DLLs aren't the problem of course. People are. :) I *love* reusable >libraries of code! I couldn't live without them. The question is, how to
<<quoted lines omitted: 5>>
>langugages. We need a good model that is simple, flexible, and robust. Lots >of details to consider on that front.
yes, and that's what I said - just let's do it right. I also remember one email from Carl some year or two ago, stating that he knows very well what the dynamic system should be all about. So I consider current Rebol state still Rebol 1.0 generation ... we need to move forwards though ....
>In any case, RT seems to have a plan. They released /Base and Carl said they >want to know what we think, so let's keep thinking and telling them. >
we do so ... I always try to see bigger perspective .... /base is step in a good direction, but not enough revolutionary - it separates only mezzanine level and RT has yet to show us - how to make it usefull, especially in combination with their preprocessor ....
> He also >said another tool would be forthcoming to help with including the pieces >they took out, so I think they have something in mind about how to handle >this. >
yes - preprocessor imo ...
>What do *I* want as a developer? > >I want to be able to send out a single EXE, that isn't dependent on anything >that might be changed for the OS or another app. External pieces I ship >should not be used by anyone else, so I can handle them however I want. If I >break my own app, that's my fault. >
now the options: 1) Encap your app .... pros: hides source code, allows you to keep everything in one file ...) cons: it works upon one platform only though, requires you to redistribute whole executable once you patch the bug or want to distribute newer version of rebol itself That model might work for platform specific development - small tools or apps, or even bigger ones, where bandwidth is no problem ... 2) Rebol player - distribute rebol/base or rebol/view/base and pack everything using preprocessor into one package. So we've got two files. Rebol, and platform agnostic rebol app package. You could even create real player :-) just press "play" button upon selected package and voila ..... Still does not work well for small dynamic devices. That's why I want more ... call me a perfectionist ... or am I just pedant? :-) 3) X-Inet apps - not "player" based ... a) introduce finally async networking. Why should I wait for my app window to appear, just because I am downloading background image? b) script or even player package, checking if Sound 1.3 is available. If not - download new component and plug-it in. Forget of rebol.exe being everything. It can't work if you want rebol to play mp3s, avis, do 3D graphics, strong math, etc. in the future. That's kind of model I would like to see introduced in two years horizon ... PDAs and other mobile stuff will become even more widespread, Rebol will get more functionality, but bandwidth will not still be cheap enough to waste it by downloading new rebol.exe, just because of upgrade of one of its components ....
>If I deploy a script, either it's targeted at REBOL developers, sysadmins, >etc. who know how this stuff works, or it's for users. If it's for users, >there needs to be a single interpreter/runtime that is used for everything >(IMHO). E.g. under Windows, .r files will be associated with rebol.exe and >that version of rebol needs to be able to run every script they might get. >This doesn't fit very well with the current model though. >
And that's exactly what I am talking about - we need one and only one rebol.exe kernel - everything other is component ....
>Keep brainstorming! >
good comments anyway! :-) -pekr-

 [48/48] from: steve:shireman:semaxwireless at: 14-Oct-2002 2:27

Re: Introducing REBOL/Base - FAQ


Seems much faster than Core...have to try a slow machine... Interesting! I was thinking it would need some test for scripts, but can just test with /Base /Pod might be more apropos than /Base for a name (implying more mobility) /Focus, /Gadget or /Scope might be a shrunk-wrapped name for /View Nice to know the memory constraints. Thanks, Steve Shireman

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted