Compiler for Rebol ?
[1/52] from: youpi:technologies:wanadoo at: 23-Sep-2000 20:22
I heard about a compiler for Rebol. Is it still available because how can
you deliver application to client if there isn't any kind of code protection
?
@
----- Message d'origine -----
De : <[pa--russo--perd--com]>
À : <[list--rebol--com]>
Envoyé : vendredi 22 septembre 2000 17:05
Objet : [REBOL] Why I'll pay for REBOL/command (or not). Was - Will
REBOL/View be commercial?
[2/52] from: al:bri:xtra at: 24-Sep-2000 10:19
[youpi--technologies--wanadoo--fr] wrote:
> I heard about a compiler for Rebol. Is it still available...
That's Sherman. It's a compiler for an old version of Rebol. I believe it
won't work for recent versions of Rebol.
> because how can you deliver application to client if there isn't any kind
of code protection?
With Rebol/Command, this might not be an issue, as it's more a CGI and in
house tool, I believe.
For Rebol/View, this doesn't seem to be an issue, because the source code is
stored at a URL. This operates much like HTML pages and JavaScript on the
web does currently. Organisations pay people to write HTML, JavaScript, Java
and to design .gif, .jpeg and Flash graphics, yet piracy of the "code" isn't
really a problem, because the "code" is embedded in the content.
For stand-alone, shrink-wrapped client use, like RebMail, a email client, or
similar programs, I can imagine that a future Rebol product would a
Rebol/View or Rebol/Core that can be packaged with a number of encrypted
scripts into one executable binary. That seems fairly obvious to me. I've
also CC-ed this to [feedback--rebol--com] just in case the Rebol crew haven't
thought of it yet.
Andrew Martin
ICQ: 26227169
http://members.ncbi.com/AndrewMartin/
http://members.xoom.com/AndrewMartin/
[3/52] from: petr:krenzelok:trz:cz at: 24-Sep-2000 0:50
> For stand-alone, shrink-wrapped client use, like RebMail, a email client,
or
> similar programs, I can imagine that a future Rebol product would a
> Rebol/View or Rebol/Core that can be packaged with a number of encrypted
> scripts into one executable binary. That seems fairly obvious to me. I've
> also CC-ed this to [feedback--rebol--com] just in case the Rebol crew haven't
> thought of it yet.
I think some ideas were expressed for many times here on ml. I also think RT
thought about it already, the question is if they will regard it being
priority. Let's face it:
Some time ago Carl mentioned something about partial compilation of certain
expression. Just few weeks ago he thowed here one email stating something
like why don't you guys use 'compile? Hey ;-) With no further explanation
following, one can only guys Carl is somethin cooking on his notebook, or I
just misuderstood the issue.
Elan, in one of his last posts (as reaction to my email of disappointment),
talked about slim binaries. If I am not wrong, slim binaries are kind of
multiplatform binaries. New Amiga OS will have the same advantage. Once app
will be in VP code, you can transfer the file between platforms. I don't
know how efficient the solution could be with interpreted language, if it
would be some kind of byte code or what, but could be interesting ...
Then there is a possibility of REBOL runtime. Well, that's something I would
like to see as the last option. Why? Because this way RT has to maintain
another family of REBOL versions, limiting the language.
I would like to see freedom of expression. E.g., some scripts (modules) in
compiled form (slim "binary", byte-p-code, whatever), while end user ability
to influence some of the other scripts (modules) ...
Some one or two years ago, there was also talk about so called
REBOL/Toolkit - REBOL in the form of libraries, embeddable into another
language apps ...
Cheers,
-pekr-
[4/52] from: jsc:dataheaven at: 24-Sep-2000 1:15
I think CodeSecurity through compiling is nonsense.
You should compile something to make it running faster, not
to make sure nobody can read your secrets.
If someone really is interested in your code - a compiler doesn't
protect you. If you say "But it's a great efford to disassemble and
reengineer compiled code and nobody will do that" then your
code isn't really worth to protect it.
IMHO 99.99% of the nowadays written code isn't worth protecting it.
The little amount of code that is really sophisticated and valueable
would need to be protected by stronger means.
But why?
IMHO I think it is ridiculous to think that "Open Source" projects
can be cloned by each newbie-programmer.
A open-sourced project that offers really sophisticated code is not easy
to understand and therefore not easy to clone.
If someone has the ressources to (legally) clone such a complex
project, he would certainly have also the resources to rewrite it
from scratch.
Open Source is a important quality-characteristic. If I can choose between
a opensource application and a closed-source application? You know
what I would choose. Is it so that with Open Source projects all people begin
to clone the software and not buying it?
I do not want to write my own webserver - I simply use Apache and I know that
the good folks that develop this tool will make a far better job than I
could do.
If I charge a software-team to develop a special software for me, I certainly
want the source too! Such a software will cost me ~ 100$ per man-hour!!!
Regards,
Jochen Schmidt
On Sun, 24 Sep 2000, you wrote:
[5/52] from: jsc:dataheaven at: 24-Sep-2000 1:29
I would prefer a more Lisp-like way of compiling.
In Lisp compiling is only for gaining speed and make smaller
code-units. In Lisp - similar to REBOL - you can inspect the not native
functions at runtime. (in compiled code too!!)
So there compilation would be no real protection.
History shows that applications written in CommonLisp are solving
highly complex tasks e. g. the NASAs Pathfinder-Mission-Planning tool was
written in CommonLisp.
Although the code is accessible at runtime (and so somewhat "open")
CommonLisp applications are sold for huge amounts of money.
Yahoo has bought some months ago a CommonLisp application for
~50 Mio $
All customers using CommonLisp say they love the ability to change
code in a running application. This is also possible with REBOL and
we should not loose it through a compiling feature that hinders us in access
to compiled REBOL code.
Regards
Jochen Schmidt
On Sun, 24 Sep 2000, you wrote:
[6/52] from: al:bri:xtra at: 24-Sep-2000 11:22
pekr wrote:
> Some time ago Carl mentioned something about partial compilation of
certain expression. Just few weeks ago he thowed here one email stating
something like why don't you guys use 'compile? Hey ;-) With no further
explanation following, one can only guess Carl has somethin' cooking on his
notebook, or I just misunderstood the issue.
I couldn't find 'compile anywhere! :-( ;-)
> Elan, in one of his last posts (as reaction to my email of
disappointment), talked about slim binaries. If I am not wrong, slim
binaries are kind of multiplatform binaries. New Amiga OS will have the same
advantage. Once app will be in VP code, you can transfer the file between
platforms. I don't know how efficient the solution could be with interpreted
language, if it would be some kind of byte code or what, but could be
interesting ...
I think encrypting a bunch of scripts and then decrypting them only in the
computer's memory, should provide a reasonable way to ensure security of
scripts.
> Then there is a possibility of REBOL runtime. Well, that's something I
would like to see as the last option. Why? Because this way RT has to
maintain another family of REBOL versions, limiting the language.
> I would like to see freedom of expression. E.g., some scripts (modules) in
compiled form (slim "binary", byte-p-code, whatever), while end user ability
to influence some of the other scripts (modules) ...
I think a Rebol runtime is a good idea, along with encrypted scripts.
> Some one or two years ago, there was also talk about so called
REBOL/Toolkit - REBOL in the form of libraries, embeddable into another
language apps...
That was the Rebol DLL. It's still a possibility.
As for Rebol crew's work load, they all ready provide binaries for 40+
different OS. An encryptor/decryptor module, once it's working OK, shouldn't
be too much of a problem, I would think.
Andrew Martin
ICQ: 26227169
http://members.ncbi.com/AndrewMartin/
http://members.xoom.com/AndrewMartin/
[7/52] from: tim:johnsons-web at: 23-Sep-2000 16:14
MTCW:
Where I live, I know two kinds of programmers:
1)Self-employed curmudgeons like myself.
2)Programmers for large organizations, like
government, municipalities.
When I talked to members of 1) about rebol,
they said things like "wow", "cool", "check it out!".
When I talked to members of 2) about rebol,
those folks asked questions like: "Is it compilable?"
and "Is it embeddable?".
For what it is worth...
Tim
[8/52] from: joel:neely:fedex at: 23-Sep-2000 23:54
Hi, Jochen!
[jsc--dataheaven--de] wrote:
> I think CodeSecurity through compiling is nonsense.
>
Bit harsh. Not nonsense, just not a perfect solution against a
well-equipped, knowledgeable attacker.
> You should compile something to make it running faster...
Agreed that this is another advantage.
> ... not to make sure nobody can read your secrets.
>
How about, "To make it difficult enough that fewer will do so,
and to reduce the risk of alterations (accidental or otherwise)
of the source which can create stability/support problems."
> If someone really is interested in your code - a compiler doesn't
> protect you.
>
If that someone is sufficiently skilled and has sufficient resources
and time, agreed. But not everyone fits those criteria.
> Open Source is a important quality-characteristic...
>
Open source development (if properly managed) is certainly an
effective process for producing high-quality code. Even the
Forrester group agrees with that (much to my amazement!)
> If I charge a software-team to develop a special software for me,
> I certainly want the source too! Such a software will cost me
> ~ 100$ per man-hour!!!
>
And if you're paying them to develop custom software for you, it
is certainly reasonable for you to establish as a condition of the
contract that you get the source (or at least have access to it in
the event of a failure on their part).
However, there's more to the software market than bright people
such as yourself contracting with high-priced developers for the
construction of custom code.
BOTTOM LINE: As has been pointed out in the recent "40 platforms"
thread, there's a real marketplace out there. While Carl and
company would be within their legal/moral/whatever rights to stop
supplying REBOL for w95/98/nt/2k (just to use a hypothetical and
totally unlikely example ;-), I'd consider that an impractical
decision if the goal is to get REBOL widely adopted. Similarly,
although I applaud/appreciate the legions of excellent developers
who contribute to the open source movement, and am a grateful
beneficiary of their labors, I question the practicality of
refusing to address the concerns of developers who wish to have
some other means of distribution than pure source code -- for a
variety of reasons.
-jn-
[9/52] from: jsc:dataheaven at: 24-Sep-2000 7:50
On Sun, 24 Sep 2000, you wrote:
> Hi, Jochen!
>
> [jsc--dataheaven--de] wrote:
> > I think CodeSecurity through compiling is nonsense.
>
> Bit harsh. Not nonsense, just not a perfect solution against a
> well-equipped, knowledgeable attacker.
Hm my harsh tone seems to be a real problem ... ;-)
But I think compared with the other thread this is much lesser
harsh ! ???
> > ... not to make sure nobody can read your secrets.
>
> How about, "To make it difficult enough that fewer will do so,
> and to reduce the risk of alterations (accidental or otherwise)
> of the source which can create stability/support problems."
To ensure the risk of alterations we could also use checksums
with our scripts. So that a script can abort after checking it's checksum.
This will help out with accidental alterations. (Compiled code
can also crash when modified!)
The problem with "other" (user?) alterations is a bit more difficult.
As a vendor I would reject all warranty-claims if a client modifies
the product. To check this we could again use checksums of the
distributed files.
> > If someone really is interested in your code - a compiler doesn't
> > protect you.
>
> If that someone is sufficiently skilled and has sufficient resources
> and time, agreed. But not everyone fits those criteria.
This is why I said that it is a sign that the code isn't worth the whole
protecting-thing if theres no one that throws in the ressources to
reverseengineer it.
> > Open Source is a important quality-characteristic...
> Open source development (if properly managed) is certainly an
<<quoted lines omitted: 10>>
> such as yourself contracting with high-priced developers for the
> construction of custom code.
It was only a example - I work as Softwaredeveloper at a softwarevendor
that creates e. g. software for airports,Air Information Services,
traveling-agencies and more.
Most of our profit is made through custom applications. 100$ per man-hour
is not to much for such work. Most projects cost in the range of some
100k$.
> BOTTOM LINE: As has been pointed out in the recent "40 platforms"
> thread, there's a real marketplace out there. While Carl and
<<quoted lines omitted: 8>>
> some other means of distribution than pure source code -- for a
> variety of reasons.
I think I have to explain a little more what I meant.
I did not say RT should stop supplying Win.. Platforms with their fantastic
tools!!! It is important for RT and the REBOL-Comunity that REBOL evolves
to a widely used language.
What I said was much more general than it obviously seemed.
IMHO there exist NO OS I really like.
UN*X is the worst OS - besides all the other ;-)
I've dreams of what a OS should look like. But no Vendor seems to try to
evolve in those directions.
As you certainly agree the net is one of the most important things in the
future. We are in the beginnings - There is _much_ more possible.
The Problem is that the Microsoft-Way (And the Apple Way too!!!) hinders
the development of that future. They develop Desktop OSs why should they
work toward a more networked future???
Sun is in another situation. They sell servers - so they try to let the
network grow more. But there are other reasons why Sun hinders the
development too.
In relation to to the Open Source topic:
IMHO most developers should more think of what source they can protect
than what sources to Open. This sounds irritating but if they open most of
their code by default and only some little (real valuable) code is protected
this would led to a much better situation.
What I wanted to say is
"Hey Guys look at your Software! Is it REALLY SOOOOO
special, sophisticated and valuable that it have to be protected?"
I hope this explaines a little bit more what I wanted to say.
Regards,
Jochen Schmidt
[10/52] from: news:ted:husted at: 24-Sep-2000 7:06
On 9/23/2000 at 4:14 PM [tim--johnsons-web--com] wrote:
> 1)Self-employed curmudgeons like myself.
> 2)Programmers for large organizations, like government,
municipalities.
And then there's someone like me, a self-employed curmudgeon who
contracts with larger organizations, who says "wow" or "is it"
depending on whether it's for me or another organization.
-T/
*********** REPLY SEPARATOR ***********
MTCW:
Where I live, I know two kinds of programmers:
1)Self-employed curmudgeons like myself.
2)Programmers for large organizations, like
government, municipalities.
When I talked to members of 1) about rebol,
they said things like "wow", "cool", "check it out!".
When I talked to members of 2) about rebol,
those folks asked questions like: "Is it compilable?"
and "Is it embeddable?".
For what it is worth...
Tim
[11/52] from: news:ted:husted at: 24-Sep-2000 7:08
On 9/24/2000 at 1:15 AM [jsc--dataheaven--de] wrote:
> IMHO I think it is ridiculous to think that "Open Source" projects
can be cloned by each newbie-programmer.
This is an important point. What many people who write code overlook is
that the marketplace still considers software applications an
investment (as opposed to a disposable commodity). They are not just
buying the software product that is shipping today, but the support and
upgrades that go with it. The reason so many products are going open
source now is because people realize that the source really isn't worth
that much. The world is full of source. The value is with the
organization or community that distributes and supports the software.
Source is a commodity; Products are an investment.
If MS released the source for Excel, people would still rather buy the
official distribution for $50 or $100 then pay less from an unknown
source. This is one reason Sun's StarOffice isn't taking the corporate
world by storm -- there isn't a lot of desktop support in place for the
product, and that's where people spend the real bucks - training and
customization.
-Ted.
[12/52] from: news:ted:husted at: 24-Sep-2000 7:15
On 9/24/2000 at 10:19 AM [Al--Bri--xtra--co--nz] wrote:
> yet piracy of the "code" isn't really a problem
Has it ever been a real "problem"? (Damages you could prove.) Or just a
bogey-man?
-Ted.
[13/52] from: siegel:prodigy:mx at: 24-Sep-2000 6:50
At 07:08 a.m. 24/09/00 -0400, you wrote:
>This is one reason Sun's StarOffice isn't taking the corporate world by
>storm -- there isn't a lot of desktop support in place for the product,
>and that's where people spend the real bucks - training and customization.
I tried it. It's kind of clunky and weird but intriguing. Some of the
labels are still in a foreign language. First I thought it was German, but
I think it's Norwegian. The default spell check language is Norwegian. It
does strange things, such as substituting "/" if you type "--", and it's
hard to find out why or how to change it.
I think that if there were full attention to these details it would be very
successful, as there is a lot to like about the product. It is surprisingly
useful for web page design, for example, but the weird aspects made me
leave it after a while.
--
JULES SIEGEL Apdo 1764 Cancun Q. Roo 77501
http://www.cafecancun.com Fax1.530.706.8739 Tel 1.52.98 83.36.29
[14/52] from: joel:neely:fedex at: 24-Sep-2000 8:07
[news--ted--husted--com] wrote:
> On 9/23/2000 at 4:14 PM [tim--johnsons-web--com] wrote:
> > 1)Self-employed curmudgeons like myself.
<<quoted lines omitted: 3>>
> contracts with larger organizations, who says "wow" or "is it"
> depending on whether it's for me or another organization.
And then there are just plain cranky old goats like me, who will
in a typical day/week be using HP-UX, Solaris, Linux, MacOS, and
a growing list of "W" variations -- who is TOTALLY FED UP with
having to write the same code more than once, whether its for
day-pay, private consulting, volunteer work, personal enjoyment,
self-education, or whatever.
Which is why any tool that is not supported on every platform I
routinely use (or may [have to] use in the future) is of little
interest to me. (Even though circumstances may force me to be
flexible
on occasion ;-)
-jn-
[15/52] from: joel:neely:fedex at: 24-Sep-2000 8:36
[jsc--dataheaven--de] wrote:
> On Sun, 24 Sep 2000, you wrote:
...
> > BOTTOM LINE: As has been pointed out in the recent "40 platforms"
> > thread, there's a real marketplace out there. While Carl and
<<quoted lines omitted: 13>>
> that REBOL evolves to a widely used language.
> What I said was much more general than it obviously seemed.
My reference to msxxx was only an analogy. Let me try to do better
at drawing the parallel:
Regardless of what I think of Regardless of what I think of a
the Windows environment, there Closed-Source approach, there
are many people who prefer it are many people who prefer it
or who have constraints that or who have constraints that
force them to use it. force them to use it.
Any language that fails to Any language that fails to
address their desires/needs address their desires/needs
will limit its acceptance. will limit its acceptance.
Regardless of my personal Regardless of my personal
views on that environment, I views on that approach, I
believe the language designer believe the language designer
should consider the desires/ should consider the desires/
needs of the group above, or needs of the group above, or
risk limiting his language's risk limiting his language's
growth and acceptance. growth and acceptance.
As long as his support for As long as his support for
that environment doesn't that approach doesn't
FORCE ME to use it when I FORCE ME to use it when I
choose not to. choose not to.
Carl's support for MS operating systems doesn't keep me from
using any of several varieties of Unix/Linux (except Debian, but
that's another issue!), MacOS, etc.
If Carl chose to give us a way to compile, tokenize, convert-to-
byte-code, or whatever, as a way to deliver executable REBOL
scripts in a form that does not immediatly disclose the source
code (whatever the reaons!), that wouldn't keep anyone who wished
to do so from supplying source code.
> What I wanted to say is
>
> "Hey Guys look at your Software! Is it REALLY SOOOOO
> special, sophisticated and valuable that it have to be
> protected?"
>
A perfectly fair question for a discussion such as this. But
I don't think anyone else has to answer it to my satisfaction
before being allowed to protect it.
What I wanted to say to RT is
"Hey guys! Is it really so important to force all
developers to give out their source code that you
won't provide any alternatives?"
> I hope this explaines a little bit more what I wanted to say.
>
And, of course, all of the above discussion ignores other quite
legitimate reasons for wanting some sort of pre-processed form
of code: performance (which you mentioned in an earlier post),
reduced run-time overhead (no need to parse/translate/compile,
potentially fewer moving parts in the distributed product,
potentially simpler set up, etc.), simpler/faster distribution
("object" is typically smaller than "source", making it faster
to download/copy/install, etc.)
and so on...
Thanks!
-jn-
[16/52] from: news:ted:husted at: 24-Sep-2000 9:44
On 9/24/2000 at 6:50 AM [siegel--prodigy--net--mx] wrote:
> I think that if there were full attention to these details it would
be very successful, as there is a lot to like about the product. It is
surprisingly useful for web page design, for example, but the weird
aspects made me leave it after a while.
StarOffice's greatest strength and weakness is the tight integration
between applications. On one hand, the applications can work together
in surprizing and useful ways. On the other, it works against the idea
of someone assembiling their own "best of breed" suite of applicatoins.
But it would seem a good choice where people are trying hard to
standardize their corporate desktops.
To give the devil its due, I think the Win32 desktop is a marvelous
example of integrating applications into a useful work environment.
(Now, if only the underlying OS wasn't broken.)
-Ted.
[17/52] from: jsc:dataheaven at: 24-Sep-2000 17:31
On Sun, 24 Sep 2000, you wrote:
> At 07:08 a.m. 24/09/00 -0400, you wrote:
> >This is one reason Sun's StarOffice isn't taking the corporate world by
<<quoted lines omitted: 5>>
> does strange things, such as substituting "/" if you type "--", and it's
> hard to find out why or how to change it.
Hm.. it maybe because I'm German (and StarDivision was a German Vendor) but
I've nto seen such behavior in last releases.
Have you ever tried the 5.2 release? (A whole bunch of changes)
I like the high grade of integration. Furthermore it has the best
formula-editor I ever seen in a wordprocessor.
Regards
Jochen Schmidt
[18/52] from: jsc:dataheaven at: 24-Sep-2000 18:07
> As long as his support for As long as his support for
> that environment doesn't that approach doesn't
> FORCE ME to use it when I FORCE ME to use it when I
> choose not to. choose not to.
Right, thats my opinion too, but by using compile to hide the source we would
loose the ability to acces code at runtime of compiled code.
Coming from CommonLisp I think this would be very bad - we would
give away a really important feature!
> Carl's support for MS operating systems doesn't keep me from
> using any of several varieties of Unix/Linux (except Debian, but
> that's another issue!), MacOS, etc.
I never said something against this fact.
> > I hope this explaines a little bit more what I wanted to say.
> And, of course, all of the above discussion ignores other quite
<<quoted lines omitted: 5>>
> ("object" is typically smaller than "source", making it faster
> to download/copy/install, etc.)
Yes that's the point!
_I_ would prefer using compilation (native, bytecode or whatever)
for making the code more efficient and smaller. But I do _not_ want to
loose runtime accessibility to the code.
Regards,
Jochen Schmidt
[19/52] from: tim:johnsons-web at: 24-Sep-2000 8:50
Hi:
I see that we have taken a thread more about
strategy and marketing here, and I hope
rebol team people are reading this.
Interesting thing coming up here... I think.
Koffice (KDE answer to Microsoft Office)
is supposed to provide hooks to a number of
languages, rather than a proprietory VBA
as does MS-Office.
Perhaps Carl and folks should consider looking
into this and perhaps trying to make sure that
Koffice provides such "hooks" for rebol.
I could sure "dig it".
It is reasonable to speculate that in the next
year, in the area that I live in we will see a number
of networks of small organizations running
Windows on top of Linux through something
like Win4Lin. With KOffice there would then
be a cheaper alternative to Microsoft's expensive
Office license. It then follows that a considerable
amount of small-module programming would happen.
I'm already putting together General Purpose modules
for Ms-Access using VBA. I'd rather be doing that
in rebol!
:)
-Tim
[news--ted--husted--com] wrote:
[20/52] from: joel:neely:fedex at: 24-Sep-2000 12:24
[jsc--dataheaven--de] wrote:
> Right, thats my opinion too, but by using compile to hide the
> source we would loose the ability to acces code at runtime of
> compiled code. Coming from CommonLisp I think this would be
> very bad - we would give away a really important feature!
>
I don't want to belabor this point unnecessrily (I probably
have!), but I do NOT agree with casting this issue as a value
judgement over an option which other languages provide the
developer.
If you (or your company) takes the policy position that you
will never buy/license any software that comes without source,
that's your right! (And if that means that you therefore can't
use some products because they don't come with that option...
well, you had the choice, so you get the consequences.)
EQUALLY IMPORTANT IS THE DEVELOPERS RIGHT TO CHOOSE...
If some developer creates a product for which he/she chooses not
to distribute the source, that's his/her right! (And if that
means that she/he loses some sales to people who require source
as a precondition... well, she/he had the choice, so she/he gets
the consequences.)
EITHER WAY, that's what free markets are about.
But to pre-empt EITHER the consumers' or developers' rights to
choose how they will do business by creating a development
environment (or a political environment or an economic one...)
that gives all the rights of choice to one party (or by
institutionalizing that party's choice so that it isn't even
a choice any longer) is to prevent the market from working
such things out on a case by case basis -- which I believe to
be the fairest mechanism in the long run.
> > Carl's support for MS operating systems doesn't keep me from
> > using any of several varieties of Unix/Linux (except Debian, but
> > that's another issue!), MacOS, etc.
>
> I never said something against this fact.
>
You didn't, and I didn't mean to imply that you had.
I was using the "choice of O/S" issue (which I think we all
agree is a Good Thing) to try to illustrate why I think the
choice of distribution form
is also a Good Thing.
> _I_ would prefer using compilation (native, bytecode or whatever)
> for making the code more efficient and smaller.
>
And I wholeheartedly support any steps which allow you that choice!
> But I do _not_ want to loose runtime accessibility to the code.
>
And that, also, is your choice. You have a perfect right to make
that a condition of doing business with you. However, I don't
support making that a constraint on how everybody can conduct their
affairs, when they are NOT doing business with you. That's THEIR
choice!
-jn-
[21/52] from: lmecir:geocities at: 24-Sep-2000 22:01
Well, let me throw in some thoughts.
I think, that the debate started to look more abstract than I prefer. My
comments are:
1) Rebol is IMHO designed with the runtime code accessibility in mind
(inspired by Lisp), so I do not think, there's an easy way to convert that
feature to its opposite.
2) I prefer the speed when compilation is considered, the source code
protection is only a minor effect surely achievable by more direct means
(discussed by Joel some time ago).
2a) When I look at the development in processor speeds (GHz looking as
standard for year 2001 processors) and the neverstopping need to increase
processor speeds, it is surely less preferable to write programs 100 or more
times slower than C in some cases, so the speed is something any language
including Rebol could use.
2b) Rebol with its mutable values used to store code radically differs even
from Lisp, that uses immutable series for that AFAIK. That fact has
immediate consequences - Self Modifying Code looks as standard - even some
basic Rebol constructs are modifying, eg:
2ba) Use - modifies its (code) block argument (this causes even "unexpected"
behaviour when recursive functions are called) and causes its code block
argument very hard to compile when speed is the goal
2bb) Make object! - modifies its (code) block argument - see above
2bc) Bind - modifying, as opposed to Bind/copy, which behaves better
2bd) any mutables contained in the code aren't protected against change - no
compilation advantage
2be) the code block can easily modify itself - a feature making compilation
almost impractical
Not trying to criticize, just to discuss the possibilities. What do you
think?
Ladislav
[22/52] from: siegel:prodigy:mx at: 24-Sep-2000 15:30
At 05:31 p.m. 24/09/00 +0200, you wrote:
>Have you ever tried the 5.2 release? (A whole bunch of changes)
It's a 40 mb download (I think). the last one was arduous. This is Mexico.
Then comes Cancun, which is at the end of the line, believe me. I keep
meaning to get the CD, but other things come first -- like a new
harddrive. we run a tight ship here at Siegel & Children Third World Slave
Labor Writing Industries SA de CV.
--
JULES SIEGEL Apdo 1764 Cancun Q. Roo 77501
http://www.cafecancun.com Fax1.530.706.8739 Tel 1.52.98 83.36.29
[23/52] from: news:ted:husted at: 25-Sep-2000 9:35
Under the heading compare and contrast, I would offer the following
clips from the Python FAQ-o-Matic. While a popular topic for
speculation, I don't believe whether or how the REBOL interpreter
precompiles code has never been clarified. Of course, Carl's recent
mention of the mysterious 'compile keyword implies something like this
is taking place behind the scenes (and could then ultimately be
exposed).
---
6.13. Can Python be compiled to machine code, C or some other language?
Not easily. Python's high level data types, dynamic typing of objects
and run-time invocation of the interpreter (using eval() or
exec) together mean that a "compiled" Python program would probably
consist mostly of calls into the Python run-time system,
even for seemingly simple operations like "x+1".
Several projects described in the Python newsgroup or at past Python
conferences have shown that this approach is feasible,
although the speedups reached so far are only modest (e.g. 2x). JPython
uses the same strategy for compiling to Java
bytecode. (Jim Hugunin has demonstrated that in combination with
whole-program analysis, speedups of 1000x are feasible for
small demo programs. See the website for the 1997 Python conference.)
Internally, Python source code is always translated into a "virtual
machine code" or "byte code" representation before it is
interpreted (by the "Python virtual machine" or "bytecode
interpreter"). In order to avoid the overhead of parsing and
translating
modules that rarely change over and over again, this byte code is
written on a file whose name ends in ".pyc" whenever a
module is parsed (from a file whose name ends in ".py"). When the
corresponding .py file is changed, it is parsed and translated
again and the .pyc file is rewritten.
There is no performance difference once the .pyc file has been loaded
(the bytecode read from the .pyc file is exactly the same
as the bytecode created by direct translation). The only difference is
that loading code from a .pyc file is faster than parsing and
translating a .py file, so the presence of precompiled .pyc files will
generally improve start-up time of Python scripts. If desired,
the Lib/compileall.py module/script can be used to force creation of
valid .pyc files for a given set of modules.
Note that the main script executed by Python, even if its filename ends
in .py, is not compiled to a .pyc file. It is compiled to
bytecode, but the bytecode is not saved to a file.
If you are looking for a way to translate Python programs in order to
distribute them in binary form, without the need to
distribute the interpreter and library as well, have a look at the
freeze.py script in the Tools/freeze directory. This creates a
single binary file incorporating your program, the Python interpreter,
and those parts of the Python library that are needed by
your program. Of course, the resulting binary will only run on the same
type of platform as that used to create it.
4.93. How do I compile a Python application to a stand-alone program?
Even though there are Python compilers being developed, you probably
don't need a real compiler, if all you want is a
stand-alone program. There are three solutions to that.
One is to use the freeze tool, which is included in the Python source
tree as Tools/freeze. It converts Python byte code to C
arrays. Using a C compiler, you can embed all your modules into a new
program, which is then linked with the standard Python
modules.
On Windows, another alternative exists which does not require a C
compiler. Christian Tismer's SQFREEZE
(http://starship.python.net/crew/pirx/) appends the byte code to a
specially-prepared Python interpreter, which will find the byte
code in executable.
Gordon McMillian offers with Installer
(http://starship.python.net/crew/gmcm/distribute.html) a third
alternative, which works
similar to SQFREEZE, but allows to include arbitraty additional files
in the stand-alone binary as well.
---
A while back, someone asked about a Java implementation of REBOL. The
idea was dismissed in general since the REBOL binary is available for
all Java platforms (and then some), and an imaginative Java to REBOL
workaround was posted. Here's how the JPython group <
http://jpython.org > justified their project:
--
Embedded scripting - Java programmers can add the JPython libraries to
their system to allow end users to write simple or complicated scripts
that add functionality to the application. Since JPython is certified
100% Pure Java, it can be added to an application without fear of
compromising its ability to run on all Java platforms.
Interactive experimentation - JPython provides an interactive
interpreter that can be used to interact with Java packages or with
running Java applications. This allows programmers to experiment and
debug any Java system using JPython.
Rapid application development - Python programs are typically 2-10X
shorter than theequivalent Java program. This translates directly to
increased programmer productivity. The seamless interaction between
Python and Java allows developers to freely mix the two languages both
during development and in shipping products.
--
In REBOL's case, I'd also mention that Java has support for many
mundane features, like printing, that REBOL now lacks, not to mention
other niceities like PDA sychronization. So if there were a
jREBOL.class, and I ran into a feature-gap, I could put a Java wrapper
around it and move forward.
There would also be the part about distributing my application in Java
bytecode, to hide the source.
-Ted.
[24/52] from: hopeless::eircom::net at: 25-Sep-2000 15:04
jREBOL (was Compiler for Rebol ? Re:(9))
> In REBOL's case, I'd also mention that Java has support for many
> mundane features, like printing, that REBOL now lacks, not to mention
<<quoted lines omitted: 4>>
> bytecode, to hide the source.
> -Ted.
Indeed. There is such a huge amount of API's available for Java that it
seems such a shame to ignore it. On the other hand jPython (AFAIK) is mostly
used for scripting java objects, in particular for embedded scripting within
aplications and for testing purposes. i.e. Python->Java. Whether REBOL is
suitable for this role I doubt.
But with REBOL you can do things like parsing and internet functionality
much easier than in Java so typically it would be useful doing Java->REBOL.
This is slightly different to the typical uses of JPython (let me know if
I'm completely wrong on this one). The solution suggested a while back
involved running a REBOL server and using TCP/IP sockets to communicate from
Java to REBOL. Imaginative but still ugly and possibly slow (I'll be trying
it out soon hopefully). Ideally a Java Native Interface to REBOL would be
nice but platform-specific so we can discount it. Perhaps there is no
better way ;-(
Jamie
[25/52] from: jhagman:infa:abo:fi at: 25-Sep-2000 20:05
Compiler for Rebol ? Re:(6)
Quoting [joel--neely--fedex--com] ([joel--neely--fedex--com]):
> Carl's support for MS operating systems doesn't keep me from
> using any of several varieties of Unix/Linux (except Debian, but
> that's another issue!), MacOS, etc.
What's wrong with Debian? I am just being curious because that is the
distribution I am using...
- Jussi
--
Jussi Hagman CS in Åbo Akademi University
Studentbyn 4 D 33 [juhagman--abo--fi]
20540 Åbo [jhagman--infa--abo--fi]
Finland
[26/52] from: joel:neely:fedex at: 25-Sep-2000 14:49
[jhagman--infa--abo--fi] wrote:
> Quoting [joel--neely--fedex--com] ([joel--neely--fedex--com]):
> > Carl's support for MS operating systems doesn't keep me from
<<quoted lines omitted: 3>>
> distribution I am using...
> - Jussi
I arranged to make a presentation a few weeks ago to the local Linux
users' group. That group meets after hours in the local headquarters
of a national-scale company, with employees of that company bringing
their own boxen into the auditorium and setting up network, video
projection, etc. before each mtg.
I had previously done a presentation on REBOL (well received BTW) using
a box running RedHat 6.whatever. THIS time, the box set up for the mtg
was running Debian. Both the public beta of /View and the current rlse
of /Core blew up instead of running. I tap-danced furiously, and did a
few minutes on XML. I didn't report it at the time because the box was
actually running Debian Unstable, and assumed that maybe the guy who
set it up was just a little too close to the edge. Also, it wasn't my
box (and I was on the stage...) so I couldn't spend too much time
poking around.
Since then, I've seen traffic on this list indicating that others have
had problems with REBOL on Debian, so perhaps my experience wasn't so
unique or box-owner-dependent after all???
-jn-
[27/52] from: handy:techie at: 27-Sep-2000 0:32
(im not sure if this has already been talked about but ...)
You know what would be really cool? If the Rebol compiler compiled to Java
bytecodes!
...now hold your horses...
Apart from the obvious platform benefits (which i *know* rebol already has):
1) Theres already a lot of support for Java and all related technologies
2) Rebol could utilise some of the Java popularity<->support to bring rebol
into the mainstream
3) There are native language compilers for Java bytecodes >:) (eg GCJ)
-- But its just an idea ... why can i sense a flame coming my way? :)
AndrewH
[28/52] from: sharriff:aina:med-iq at: 26-Sep-2000 16:08
I can see it coming, somebody would write a wrapper or compiler for REBOL
one day.....
Sharriff Aina
med.iq information & quality in healthcare AG
Gutenbergstr. 42
41564 Kaarst
tel.: 02131-3669-0
fax: 02131-3669-599
www.med-iq.de
[29/52] from: ptretter:charter at: 26-Sep-2000 14:24
I believe the best option for the masses would be to just be able to make
native! those functions that expose the performance or characteristic of the
finished script. Seems the easiest approach and should accomplish the goal.
Maybe the make native! function would have some algorithm that unlock the
code that the programmer only knows. Do I sounds out of my mind here?
Paul Tretter
[30/52] from: al:bri:xtra at: 27-Sep-2000 8:34
Sharriff Aina wrote:
> I can see it coming, somebody would write a wrapper or compiler for REBOL
one day.....
I don't know about the compiler, but the wrapper is available from Rebol
now! Read what Bo sent to me:
<Quote>
(Regarding REBOL Helpdesk #4466)
Andrew,
Here is a snippet from our REBOL/Command press release:
Ukiah, CA - September 21, 2000 - REBOL Technologies today announced the
availability of REBOL/Command 1.0, a commercial extension to its leading
Internet application development product REBOL/Core 2.3. REBOL/Command 1.0
enables developers to extend their REBOL language-based applications by
integrating them with popular platform-specific libraries, tools, 3rd party
applications and databases. REBOL/Command Runtime, which will be released
next month, will enable developers to encapsulate their REBOL applications
for distribution to their customers.
By 'encapsulate', we mean that you can write a script and distribute it with
the REBOL/Command binary. The source code to the script cannot be seen and
the binary cannot run any scripts other than the one that is encapsulated
with it and the scripts that are called from within that script. It will
most likely be sold on a number-of-units-distributed license. This same
scheme
can easily be extended to REBOL/View and REBOL/Core should we decide to do
this at some point.
If you have any additional questions/comments/suggestions, please let us
know!
</Quote>
Note the "Encapsulate" part.
Andrew Martin
ICQ: 26227169
http://members.nbci.com/AndrewMartin/
http://members.xoom.com/AndrewMartin/
[31/52] from: joel:neely:fedex at: 26-Sep-2000 16:11
No flaming from me; just puzzled head-scratching. It's not clear to me
that REBOL and Java are conceptually close enough to be ABLE to compile
REBOL directly into Java bytecode. Some REBOL features could be dealt
with by defining support classes in Java, with appropriate method calls
as the Java equivalent of REBOL words/phrases. However, there are
REBOL features for which I don't see an obvious JVM representation.
For example:
1) REBOL's refusal to distinguish between data and code, whick allows
one to construct a block and then do that block,
2) REBOL's ability to manipulate contexts,
3) REBOL's class-less view of objects...
It would certainly be possible to create a REBOL interpreter written
in Java, but that's not what I understood you to be suggesting (and
my experience with Java suggests that it would run like a pig on
tranquilizers...)
-jn-
[handy--techie--com] wrote:
[32/52] from: bciceron:rsn:hp at: 26-Sep-2000 16:34
why not a rebol plugin, instead ?
so your favorite browser would have a rebol interpreter inside and so the
ability to run .r script on the client side...
[33/52] from: gmassar:dreamsoft at: 26-Sep-2000 15:08
Why not a rebol converter, also? The converter converts any Rebol
scripts to some standard language such as ANSI C or ISO Pascal
(preferrable). Then use a fast compiler to compile the converted code.
You got high-speed executables!
Note: we already have JCC and PY2PAS, Java converter to C and Python
converter to Pascal (Free Pascal) respectively.
Links:
http://www.geocities.com/CapeCanaveral/Hangar/4040/jcc.html
http://www.spam.ee/~andreie/software/py2pas/english-index.html
Geo...
[bciceron--rsn--hp--com] wrote:
[34/52] from: sharriff:aina:med-iq at: 27-Sep-2000 7:23
>can easily be extended to REBOL/View and REBOL/Core should we decide to do
>this at some point.
Sounds okay, but whats with the "should we decide to..." I take this as as
chance that a wrapper for Core might not see the light of day. All the same
it still won´t stop some Rebol guru from implementing something of the
sort. The necessity is definately there when one writes applications on
which a firm/individual bases its/his/her market value on...
Sharriff Aina
med.iq information & quality in healthcare AG
Gutenbergstr. 42
41564 Kaarst
tel.: 02131-3669-0
fax: 02131-3669-599
www.med-iq.de
[35/52] from: handy:techie at: 28-Sep-2000 0:22
> No flaming from me; just puzzled head-scratching. It's not clear to me
> that REBOL and Java are conceptually close enough to be ABLE to compile
> REBOL directly into Java bytecode.
Im taking a guess here, but it seems you are thinking at a much higher level
than I am.
Theoretically conversion from REBOL to bytecode doesnt require any
syntactic/semantic resemblance to Java, merely a mapping of REBOL functions
to bytecode sequences.
Further, this conversion would be somewhat simplified by the fact that the
bytecodes are
much more finite than the language that it is compiled from (an analogy:
c -> RISC assembler),
creating less mapping possibilities, making it a simpler conversion process.
Im afraid that I am new to both languages and cant adequately go into detail
on the points you raised...BUT:
> It would certainly be possible to create a REBOL interpreter written
> in Java, but that's not what I understood you to be suggesting (and
> my experience with Java suggests that it would run like a pig on
> tranquilizers...)
This process would entail roughly the steps I am talking about! ...albiet at
the language level, not the bytecode level (but you can always go from
lang->bytecode so...) By an interpreter I take it you mean parsing REBOL
code and mapping REBOL commands to JAVA commands and executing them?
Does this not represent a roughly adequate conversion process? That is,
store the commands as opposed to executing them (and maintain a variable's
dynamic nature), and then compile the resulting source (it would be shocking
source - probably all linear)? Then were home & hosed ... compile to
bytecode and to native machine code (if need be - yes i am aware of the
design violations this incurrs but ... :)
Although I do admit it would be extremely hard to achieve dynamic generation
and resultant execution of code ... eg #1 on your list ... hmmm :)
AndrewH
[36/52] from: news:ted:husted at: 27-Sep-2000 11:21
On 9/28/2000 at 12:22 AM [handy--techie--com] wrote:
> By an interpreter I take it you mean parsing REBOL code and mapping
REBOL commands to JAVA commands and executing them?
A working example of this product category might be the jPhython
project < http://jpython.org/ >.
Like REBOL, Python is an interpreted scripting language. jPython does
what you might expect, interpret Python code and spit out bytecodes to
the JVM, much like cPython would interpret Python and spit machine code
to the processor.
There's not a snowball's chance of this happening, but if it did, it
would mean you could encapsulate REBOL scripts within Java programs.
Of course, there may be performance trade-offs, since many JVM's are
pokey. Using a high-performance Java configuration, people have matched
benchmarks between jPython and cPython (the conventional C
implementation). Though, in practice, jPhython is said to be 2.5x
slower than the mature cPython compiler.
-Ted.
[37/52] from: petr:krenzelok:trz:cz at: 27-Sep-2000 18:22
----- Original Message -----
From: <[news--ted--husted--com]>
To: <[list--rebol--com]>
Sent: Wednesday, September 27, 2000 5:21 PM
Subject: [REBOL] Compiler for Rebol ? Re:(13)
> On 9/28/2000 at 12:22 AM [handy--techie--com] wrote:
> > By an interpreter I take it you mean parsing REBOL code and mapping
<<quoted lines omitted: 12>>
> implementation). Though, in practice, jPhython is said to be 2.5x
> slower than the mature cPython compiler.
You will have the smallest jvm with Tao (read some reviews at
www.amigasdk.com), and if REBOL/View will run with tao, you run with Java
:-) ...
-pekr-
[38/52] from: joel:neely:fedex at: 27-Sep-2000 16:58
Hi, Andrew!
[handy--techie--com] wrote:
> > No flaming from me; just puzzled head-scratching. It's not clear to me
> > that REBOL and Java are conceptually close enough to be ABLE to compile
<<quoted lines omitted: 4>>
> syntactic/semantic resemblance to Java, merely a mapping of REBOL
> functions to bytecode sequences.
I'm sorry, but I must disagree. The JVM and its bytecode were specifically
designed for the Java language; many of their features are directly related
to requirements, features, and concepts of the Java language. By the same
token, concepts NOT part of the Java world-view would be VERY difficult to
map directly to JVM bytecode. The "mere" mapping of REBOL functions to
JVM bytecode is not very "mere" where REBOL has a concept missing from
Java.
Let me give just a couple of brief examples:
1) Java uses a class-model style of OO programming, in which one defines
a "class" (at compile time) as a kind of factory or classification
entity, then creates objects (at run time) by asking the class to construct
an "instance" of itself. REBOL uses neither the class/instance distinction
nor the compile-time/run-time distinction.
2) Java draws a sharp distinction between code and data. REBOL, as a pure
von Neumann language, refuses to recognize that distinction. It is
trivial to write REBOL code that modifies itself, or that creates a new
function (or just a block) at run-time, and subsequently evaluates/executes
that newly constructed expression. I know of no reasonable mechanism in the
JVM that allows running JVM bytecodes to manufacture new content for the
runtime constant pool (which is where symbolic references to classes,
methods, method signatures, etc. are stored).
An example of an unreasonable mechanism would be for the running code to
compose an entirely new class file on the fly, then invoke the class loader
on that new class file. I believe the overhead of such an approach would
be intolerably high for any practical uses.
3) Java is a strongly-typed language. JVM bytecodes for such common actions
as comparing two values depend on advance (i.e., compile-time) knowledge
of the types of the values being compared. Different opcodes are used for
comparing two integers than for comparing two doubles, for example. Also,
invoking a Java method (e.g., via the INVOKEVIRTUAL opcode) requires a
reference to the constant pool which provides a method signature (which
includes identification of the types of all arguments). REBOL, by contrast,
can punt on the entire issue of function argument types, leaving that issue
to be handled implicitly by each operator or explicitly by the high-level
code.
Based on the above (among other issues), the REBOL code:
block1: [a: 1 b: does [print a] z: func [x] [a < x]]
block2: [a: 2.3 c: does [print ["fee has" a]]]
foo: make object! block1
fee: make foo block2
fum: make object! append copy block1 [
z: func [x] [either number? x [a > x] [false]]
]
poses a number of significant challenges to any attempt to render it into
equivalent JVM bytecode.
> Further, this conversion would be somewhat simplified by the fact that
> the bytecodes are much more finite than the language that it is compiled
> from (an analogy: c -> RISC assembler), creating less mapping
> possibilities, making it a simpler conversion process.
>
I don't understand this sentence at all.
Bytecodes typically deal with more fine-grained, operationally oriented
concepts than high-level programming languages. The translation process
is only "a simpler conversion" (than compilation to object code for some
physical computer?) if the defining concepts of the source language and
the byte code are nicely aligned.
> Im afraid that I am new to both languages and cant adequately go into
> detail on the points you raised...BUT:
<<quoted lines omitted: 5>>
> ...albiet at the language level, not the bytecode level (but you can
> always go from lang->bytecode so...)
Different concepts.
> By an interpreter I take it you mean parsing REBOL code and mapping
> REBOL commands to JAVA commands and executing them?
>
No. The distinction I'm drawing is between
a) Writing a compiler (in whatever lanaguage -- that's irrelevant)
that reads REBOL source code and produces standard Java class files
which can be executed using a standard JVM. That's I was discussing
in the first section above.
b) Writing a REBOL intepreter IN Java -- i.e., a Java program that
reads REBOL source code, parses and analyzes it, and then performs
the actions specified by that REBOL code.
Those are VERY different. And, IMHO, the first would be extremely
difficult (if not totally infeasible), while the second would likely
be too slow for any realistic use.
-jn-
--
; Joel Neely [joel--neely--fedex--com] 901-263-4460 38017/HKA/9677
REBOL [] print to-string debase/64 decompress #{
789C0BCE0BAB4A7176CA48CAB53448740FABF474F3720BCC
B6F4F574CFC888342AC949CE74B50500E1710C0C24000000}
[39/52] from: sharriff:aina:med-iq at: 28-Sep-2000 10:08
Just when I thought my problems were solved..sorry to bother you guys again
[
admin [
name "Sharriff Aina"
password "gong"
email [sharriff--aina--med-iq--de]
dept "Administration"
view "yes"
]
sharriff [
name "Sharriff Aina"
password "jungle"
email [sharriff--aina--med-iq--de]
dept "Administration"
view "yes"
]
]
a "SELECT" or "FIND" always results in a " NONE" how do I iterate? the path
test-path: admin/name
for example works. I would to be able to search the
database given the first name (login name) of the user with a function...
Thanks and much appreciation for your help
I´ll get the hang of this one day, this is my second REBOL week!
Sharriff Aina
med.iq information & quality in healthcare AG
[40/52] from: joel:neely:fedex at: 28-Sep-2000 7:07
Well, Sharriff, it depends on what you want to select...
Using cut-n-paste from your original note:
>> foo: [
[ admin [
[ name "Sharriff Aina"
[ password "gong"
[ email [sharriff--aina--med-iq--de]
[ dept "Administration"
[ view "yes"
[ ]
[
[ sharriff [
[ name "Sharriff Aina"
[ password "jungle"
[ email [sharriff--aina--med-iq--de]
[ dept "Administration"
[ view "yes"
[ ]
[ ]
== [
admin [
name "Sharriff Aina"
password "gong"
email [sharriff--aina--med-iq--de]
dept "Admini...
>> select foo 'admin
== [
name "Sharriff Aina"
password "gong"
email [sharriff--aina--med-iq--de]
dept "Administration"
view "yes"
]
>> select foo "admin"
== none
>> select foo admin
** Script Error: admin has no value.
** Where: select foo admin
Note that all of your "key" values are of type word! and NOT of
type string! which means you must use a literal word or an
expression that evaluates to a value of type word! in order to
get a match.
OTOH, if you want to search by name, you can either write
a function to search the nested blocks, as in
>> searchname: func [who [string!] /local k v] [
[ foreach [k v] foo [
[ if v/name = who [return v]
[ ]
[ ]
>> searchname "Sharriff Aina"
== [
name "Sharriff Aina"
password "gong"
email [sharriff--aina--med-iq--de]
dept "Administration"
view "yes"
]
OTOH, (wait a minute... I don't have three hands! Can somebody
give me a hand? ;-) if you're going to do lots of searching in
that data structure, it's worthwhile to pre-build another data
structure that can serve as an index or cross-reference to the
original one:
>> buildxref: func [/local xref k v] [
[ xref: copy []
[ foreach [k v] foo [
[ append xref v/name
[ append/only xref v
[ ]
[ xref
[ ]
>> fum: buildxref
== ["Sharriff Aina" [
name "Sharriff Aina"
password "gong"
email [sharriff--aina--med-iq--de]
dept "A...
>> select fum "Sharriff Aina"
== [
name "Sharriff Aina"
password "gong"
email [sharriff--aina--med-iq--de]
dept "Administration"
view "yes"
]
Modifying either of the above to return both the key and value from
the ORIGINAL block (e.g., getting back BOTH the key 'admin and the
block of associated data), is a minor tweak that is left to the
reader.
(That's academicspeak for
"I don't have time to type it right now."
but feel free to ask if you want any followup! ;-)
-jn-
[Sharriff--Aina--med-iq--de] wrote:
[41/52] from: sharriff:aina:med-iq at: 28-Sep-2000 14:21
Thanks Jeff!! one question:
the "local" value "k", what is it piroüose exactly , its not beineg
breferenced at all
>> buildxref: func [/local xref k v] [
[ xref: copy []
[ foreach [k v] foo [
[ append xref v/name
[ append/only xref v
[ ]
[ xref
[ ]
Sharriff Aina
med.iq information & quality in healthcare AG
Gutenbergstr. 42
41564 Kaarst
tel.: 02131-3669-0
fax: 02131-3669-599
www.med-iq.de
[42/52] from: joel:neely:fedex at: 28-Sep-2000 14:34
[Sharriff--Aina--med-iq--de] wrote:
> Thanks Jeff!! one question:
>
> the "local" value "k", what is it piroüose exactly , its not beineg
> breferenced at all
>
Hey, I did say I'd left something as an exercise! ;-)
> >> buildxref: func [/local xref k v] [
> [ xref: copy []
<<quoted lines omitted: 4>>
> [ xref
> [ ]
If the second argument of foreach is a list of words, then they take
consecutive values from the block that is the second argument.
>> foo: [1 "a" 2 "b" 3 "c" 4 "d"]
== [1 "a" 2 "b" 3 "c" 4 "d"]
>> foreach [n s] foo [print s]
a
b
c
d
>> foreach [n s] foo [print n]
1
2
3
4
>> foreach [n s] foo [print [n "->" s]]
1 -> a
2 -> b
3 -> c
4 -> d
>>
So, all I was saying in buildxref was "Walk through foo , treating
it as a collection of pairs. Call the left-hand element k and the
right-hand element v while looking at each pair. Now, here's what
to do with each pair..." It just happens that the simplified version
if cross-referencing I showed in that example didn't use the left-hand
element.
There are other ways to skin this cat. For example, using forskip as
illustrated by:
>> skipfoo: next foo
== ["a" 2 "b" 3 "c" 4 "d"]
>> forskip skipfoo 2 [print first skipfoo]
a
b
c
d
== false
>> skipfoo: foo
== [1 "a" 2 "b" 3 "c" 4 "d"]
>> forskip skipfoo 2 [print first skipfoo]
1
2
3
4
== false
>> skipfoo: foo
== [1 "a" 2 "b" 3 "c" 4 "d"]
>> forskip skipfoo 2 [print [first skipfoo "->" second skipfoo]]
1 -> a
2 -> b
3 -> c
4 -> d
== false
>>
Both of these approaches can be used with groupings of more then two
elements at a time. For instance, if I had a block containing ID#,
name, and phone number for a bunch of employees (I'll not bother to
make up sample data for this one), one could list all of the names
by saying either (*WARNING* *UNTESTED CODE FRAGMENT*)
foreach [emp-id emp-name emp-phone] emp-data-block [
print emp-name
]
or
emp-temp-block: next emp-data-block
forskip emp-temp-block 3 [print first emp-temp-block]
or (a TOTALLY UNSATISFACTORY solution, in my opinion)
emp-data-block: next emp-data-block
forskip emp-data-block 3 [print first emp-data-block]
emp-data-block: head emp-data-block
The first of these three (at least to my eye) seems to do the best
job of making clear that I'm dealing with emp-data-block as a
collection of triples, and making clear exactly what I'm doing with
(what parts of) each triple.
-jn-
PS: Since I've already blabbered on for this long, I might as well
include one solution to the open issue I raised in the earlier
post in this thread -- creating an index/crossreference to your
original block that lets me start with a name and get at both the
key and value block from the original data structure:
== false
>> foo: [
[ admin [
[ name "Sharriff Aina"
[ password "gong"
[ email [sharriff--aina--med-iq--de]
[ dept "Administration"
[ view "yes"
[ ]
[
[ sharriff [
[ name "Sharriff Aina"
[ password "jungle"
[ email [sharriff--aina--med-iq--de]
[ dept "Administration"
[ view "yes"
[ ]
[ ]
== [
admin [
name "Sharriff Aina"
password "gong"
email [sharriff--aina--med-iq--de]
dept "Admini...
>> buildxref: func [orig [block!] /local xref k v] [
[ xref: copy []
[ foreach [k v] orig [
[ append xref v/name
[ append/only xref reduce [k v]
[ ]
[ xref
[ ]
>> fum: buildxref foo
== ["Sharriff Aina" [
admin [
name "Sharriff Aina"
password "gong"
email sharriff.ain...
>> first select fum "Sharriff Aina"
== admin
This version uses both the key and value elements of each pair.
Of course, I can't let this drop without assigning more homework
(old teaching habits die hard ;-), so let's notice that the
name "Sharriff Aina" occurs more than once in your original data.
Wouldn't it be nice to have a version of buildxref that made a
crossreference structure that paired each name with a block of
key/value pairs, for all entries in the original data where the
name appeared?
--
; Joel Neely [joel--neely--fedex--com] 901-263-4460 38017/HKA/9677
REBOL [] print to-string debase decompress #{
789C0BCE0BAB4A7176CA48CAB53448740FABF474F3720BCC
B6F4F574CFC888342AC949CE74B50500E1710C0C24000000}
[43/52] from: sharriff:aina:med-iq at: 28-Sep-2000 15:58
..Whoa! you laid it down so nicely it seems painfully simple, I really have
to RTFM, not once but "LOOP 5" times ;-)
I would do some reading now on all what you´ve explained to me..sorry to
have been a bother to you.
Thanks Jeff
..uhm Mr. Sassenrath? if you´re reading this list : someone said somewhere
that REBOL was addictive, he was right...PLEASE make an EXEC function free
for CORE ( I think everyone on this list agrees with me? )
Sharriff Aina
med.iq information & quality in healthcare AG
[44/52] from: jhagman:infa:abo:fi at: 28-Sep-2000 19:14
Quoting [joel--neely--fedex--com] ([joel--neely--fedex--com]):
> [jhagman--infa--abo--fi] wrote:
> >
<<quoted lines omitted: 12>>
> public beta of /View and the current rlse of /Core blew up instead
> of running.
Yes, that's the demo effect! :) I hope you tested rebol on that
machine _before_ the demo...
> I didn't report it at the time because the box was
> Debian Unstable, and assumed that maybe the guy who set it up was
> just a little too close to the edge.
>
> Since then, I've seen traffic on this list indicating that others have
> had problems with REBOL on Debian, so perhaps my experience wasn't so
> unique or box-owner-dependent after all???
Yes, problem was the guy running the box, not Debian not even it's
unstableness. The root of the problem lies in rebol using an _ancient_
library called termcap. Debian does not have this library in it's
normal distribution but in _oldlibs_ as it is very old it is compiled
against libc5. As other libraries and rebol are compiled against libc6
and those two don't mix the crash occurs.
The guy running the box just has not removed the old libtermcap. He
surely has no programs depending on it anymore. The workaround is to
remove the libtermcap and make link from libncurses to libtermcap.
So, it is not Debian's fault that the guy wanted to keep an old libc5
library installed. Sure Debian is somewhat harder to install than
RedHat. But it has some other virtues (atleast for power users and
opensource enthusiasts).
And for my part, no I was not up for the task either and had
libtermcap installed once, but that has been long gone. I surely
wondered about the problem for a long time. I would suggest REBOL to
include a warning to the readme on this. It seems that a lot of people
have debian installed with the libtermcap.
Yours,
Jussi
--
Jussi Hagman CS in Åbo Akademi University
Studentbyn 4 D 33 [juhagman--abo--fi]
20540 Åbo [jhagman--infa--abo--fi]
Finland
[45/52] from: holger:rebol at: 28-Sep-2000 10:43
On Thu, Sep 28, 2000 at 07:14:53PM +0300, [jhagman--infa--abo--fi] wrote:
> And for my part, no I was not up for the task either and had
> libtermcap installed once, but that has been long gone. I surely
> wondered about the problem for a long time. I would suggest REBOL to
> include a warning to the readme on this. It seems that a lot of people
> have debian installed with the libtermcap.
The new experimental versions of REBOL/Linux/x86 come with libtermcap
statically linked, so there should be no more conflicts with libc5/6.
--
Holger Kruse
[holger--rebol--com]
[46/52] from: larry:ecotope at: 28-Sep-2000 12:10
Hi Joel
Just a small clarification. You wrote:
>> searchname: func [who [string!] /local k v] [
[ foreach [k v] foo [
[ if v/name = who [return v]
[ ]
[ ]
Actually the declaration of k and v as local vars to the searchname function
is unnecessary as in your example they are never used. The foreach function
binds the words in it's first arg (also k and v in your example) as local to
it's own context. The outer k and v are unused. Here is a short example:
>> f: func [/local k][
[ k: 1
[ foreach [k]["a" "b"][print k]
[ print k
[ ]
>> f
a
b
1
>>
Cheers
-Larry
[47/52] from: joel:neely:fedex at: 28-Sep-2000 19:25
Thanks, Larry! You're absolutely right...
I ran into this a while back in the context of the following kind of
thing:
something: [print x]
foreach x some-block [do something]
but the knowledge hasn't made it from my memory to my typing fingers! ;-)
-jn-
[larry--ecotope--com] wrote:
> Hi Joel
> Just a small clarification. You wrote:
<<quoted lines omitted: 19>>
> Cheers
> -Larry
--
; Joel Neely [joel--neely--fedex--com] 901-263-4460 38017/HKA/9677
REBOL [] print to-string debase decompress #{
789C0BCE0BAB4A7176CA48CAB53448740FABF474F3720BCC
B6F4F574CFC888342AC949CE74B50500E1710C0C24000000}
[48/52] from: jhagman:infa:abo:fi at: 1-Oct-2000 21:11
Quoting [holger--rebol--com] ([holger--rebol--com]):
> The new experimental versions of REBOL/Linux/x86 come with libtermcap
> statically linked, so there should be no more conflicts with libc5/6.
Great!
--
Jussi Hagman CS in Åbo Akademi University
Studentbyn 4 D 33 [juhagman--abo--fi]
20540 Åbo [jhagman--infa--abo--fi]
Finland
[49/52] from: chris:double:tab at: 2-Oct-2000 9:40
> Those are VERY different. And, IMHO, the first would be extremely
> difficult (if not totally infeasible), while the second would likely
> be too slow for any realistic use.
Have you seen Kawa? The scheme compiler that compiles to JVM and
executes the byte code on the fly [1].
It would seem to face the same sorts of problems as a REBOL-on-JVM
would face and it works quite nicely.
[1] http://www.gnu.org/software/kawa/kawa.html
Chris.
--
http://www.double.co.nz/dylan
[50/52] from: joel:neely:fedex at: 1-Oct-2000 21:45
[chris--double--tab--co--nz] wrote:
> > Those are VERY different. And, IMHO, the first would be extremely
> > difficult (if not totally infeasible), while the second would likely
> > be too slow for any realistic use.
>
> Have you seen Kawa? The scheme compiler that compiles to JVM and
> executes the byte code on the fly [1].
>
Not before your post. Thanks! I've been looking at their site since
receiving the URL you provided. I'm quite impressed with what they've
done.
> It would seem to face the same sorts of problems as a REBOL-on-JVM
> would face and it works quite nicely.
>
I guess it depends on one's definition of "quite nicely". My own
definition of "nicely-working" REBOL-on-JVM is quite simple (and
quite strict!): it must be totally equivalent in functionality to
REBOL as supplied by RT. One should be able to pick up any working
REBOL script and compile/execute it in the alternate environment
with no changes and no feature unsupported.
Bear in mind that there are already many versions of LISP/Scheme.
I suspect that the shock to the LISP/Scheme community of stepping
from N version to N+1 versions would be smaller than the shock to
the REBOL community of stepping from 1 version to 2.
Further, there is already a large body of literature using the
Scheme language (including the seminal SICP). Having more options
for running programs in a widely-publicized language is a good
thing, but that's not the most burning issue for REBOL, IMHO.
In addition, I view Scheme as a significantly simpler language
than REBOL. I should also add at this point that the "internals"
of Scheme are FAR better documented than what is currently
available for REBOL -- regardless of whether this is because of
RT policy, trade secrets, work-in-progress issues, or just the fact
that Carl and the other folks at RT deserve at least three or four
hours of sleep a week! ;-)
Finally, I'm not challenging the theoretical posibility of doing
REBOL on a JVM, but I have serious questions about how practical
it would be, depending on one's objectives.
> [1] http://www.gnu.org/software/kawa/kawa.html
>
Having looked briefly through that site, I am impressed by the
work that's been done thus far, but it appears to fall short of
the (admittedly hard-nosed) criterion I stated above. Consider the
partial list of exceptions and caveats quoted from the site above:
Also, call-with-current-continuation is only "upwards" (?).
I.e. once a continuation has been exited, it cannot be invoked.
These restricted continuations can be used to implement
catch/throw (such as the examples in R4RS), but not co-routines
or backtracking.
Here, a feature of the language can't be used in Kawa to do some
things it can do in standard Scheme.
Kawa now does general tail-call elimination, but only if you use
the flag --full-tail-calls. (Currently, the eval function itself
is not fully tail-recursive, in violation of R5RS.) The
--full-tail-calls flag is not on by default, partly because it is
noticably slower (though I have not measured how much), and
partly I think it is more useful for Kawa to be compilatible with
standard Java calling conventions and tools...
I assume that "compatible" was meant by the mangled word in the next-
to-last line; if so, compatibility with Jave was deemed useful enough
to influence the default behavior of this implementation.
Even without --full-tail-calls, if the compiler can prove that
the procedure being called is the current function, then the tail
call will be replaced by a jump. This means the procedure must be
defined using a letrec, not a define (because the compiler does
not know if someone might re-define a global definition), and
there must be no assignments (using set!) to the procedure
binding.
Note the parenthesized remark that "the compiler does not know if
someone might re-define a global definition", a perfectly reasonable
thing to do in REBOL.
If you define a macro with defmacro, you (currently) cannot use
the macro in the same compilation as the definition.
A fairly severe restriction, IMHO.
The current Kawa compiler is rather simple-minded, and in many
places only allows simple types that the compiler can evaluate
at compile-time. More specifically, it only allows simple type
names that map to primitive Java types or java classes.
Another example of a Java-oriented language compromise.
This next one needs some explanation. The rules for valid names in
Scheme are different (and much more liberal) than the rules for valid
names in Java. Kawa "mangles" (their word, not mine) Scheme names
into the more limited options allowed by Java. With that background:
Note that this mapping may map different Scheme names to the same
Java name. For example `string?', `String?', `is-string',
`is-String', and `isString' are all mapped to the same Java
identifier `isString'. Code that uses such "Java-clashing" names
is not supported.
In other words, you must know what names are legal in Java and how
Kawa maps Scheme names to that more restricted set, or risk having
multiple names that end up the same. If so, tough luck.
The behavior of interpreted code and compiled code is not
indentical, though you should get the same result either way
unless you have designed the classes rather strangely.
In contrast to the previous point, no explanation for "rather
strangely" is given. Thus, there's no guarantee that you won't
write "strange" code which behaves inconsistently.
Let me be VERY clear. I'm impressed with what the Kawa team has
done, and do not intend my comments to reflect negatively on their
accomplishments. What I am trying to point out, however, is that
a quick perusal of their web site reveals that using Kawa is not
SIMPLY a matter of taking any working Scheme program and dropping
it into their compiler.
Even if it were feasible to build a REBOL-onto-JVM compiler of
comparable quality to Kawa, I wonder whether the brainpower might
be more profitably spent on other REBOL promotion and support
issues: documentation, more tutorials, building a "standard
library" of widely-needed and reusable objects/functions, etc.
Thanks for the very interesting link! I'll plan to read more
on what they're doing with Kawa.
-jn-
[51/52] from: joel:neely:fedex at: 1-Oct-2000 22:38
Let me clarify a previous statement that probably was misleading:
[joel--neely--fedex--com] wrote:
> 2) Java draws a sharp distinction between code and data. REBOL,
> as a pure von Neumann language, refuses to recognize that
<<quoted lines omitted: 10>>
> overhead of such an approach would be intolerably high for any
> practical uses.
It's not actually necessary to write the class file to disk and load
it back from disk. A ClassLoader can take bytecode from an array
in memory.
That detail wasn't my main point -- which was that manufacturing
new classes on the fly would be a terribly inefficient way to
handle the REBOL concept
florp: make object! [
; etc...
]
glompfh: make florp [
; more etc...
]
However, I don't want to risk making bogus arguments, in fact or
appearance.
-jn-
--
; Joel Neely [joel--neely--fedex--com] 901-263-4460 38017/HKA/9677
REBOL [] print to-string debase/64 decompress #{
789C0BCE0BAB4A7176CA48CAB53448740FABF474F3720BCC
B6F4F574CFC888342AC949CE74B50500E1710C0C24000000}
[52/52] from: chris:double:tab at: 3-Oct-2000 8:16
> Even if it were feasible to build a REBOL-onto-JVM compiler of
> comparable quality to Kawa, I wonder whether the brainpower might be
> more profitably spent on other REBOL promotion and support issues:
> documentation, more tutorials, building a "standard library" of
> widely-needed and reusable objects/functions, etc.
Personally I agree. I thing it would be better to spend time on
using/developing the current REBOL than building another. One problem
with two not-quite-the-same implementations is having to keep them in
sync with each other.
Similar to the JVM is the microsoft .NET platform. Many languages have
been ported to .NET but due to difficulties most of the languages have
had to have subtle changes or not implement the more difficult parts
of the languages (like call/cc for example).
> Thanks for the very interesting link! I'll plan to read more on what
> they're doing with Kawa.
You're welcome!
Cheers,
Chris.
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted