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:y:ahoo 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