DLL Hell = Rebol library script version
[1/19] from: andrew::martin::colenso::school::nz at: 24-Dec-2003 22:45
Thanks, Anton!
You wrote:
> > (A) f2 just tries to use whatever version of f1 is currently
installed.
I'd go for this option as it's the most simple option, in breaking as
soon as possible. The other options involve the higher level function
knowing
too much about the lower level function.
The scenarios remind me of Windows "DLL Hell" and the solution that MS
came up for it for .NET. That solution was basically to not use DLLs. :)
Instead, supply all the software (including DLLs) for an application
with the application's main .exe. Those DLLs supplied with the
application are the ones used by the application. Only if DLLs have the
same version are they shared, IIRC.
We can use a similar principle. When distributing a Rebol script,
include all the functions (words) that the main script requires. Of
course, the problem here is that most of us have nice toolkits of
functions that we want to use in our main script applications, and it's
pointless manually copying and pasting from our toolkit because that
just produces multiple copies, with no definitive, authoritive source.
So the solution to me, is for the release version of the
script/application to have the library/toolkit functions the script
requires, automatically inserted into the script just after the Rebol
header. That way, the script application will create it's preferred
environment, regardless of previously launched library programs.
Of course, there can be a problem with what to do, when current and past
Rebol interpreters have faults and need patching. Perhaps we should prod
Rebol HQ into action? :) It would be nice to have defects fixed, and old
versions of Rebol interpreters removed.
What do you think about it? Is there something I've missed?
Andrew J Martin
Attendance Officer
Speaking in tongues and performing miracles.
Colenso High School
Arnold Street, Napier.
Tel: 64-6-8310180 ext 826
Fax: 64-6-8336759
http://colenso.net/scripts/Wiki.r?AJM
http://www.colenso.school.nz/
DISCLAIMER: Colenso High School and its Board of Trustees is not responsible (or legally
liable) for materials distributed to or acquired from user e-mail accounts. You can report
any
misuse of an e-mail account to our ICT Manager and the complaint will be investigated.
(Misuse can come in many forms, but can be viewed as any material sent/received that
indicate or suggest pornography, unethical or illegal solicitation, racism, sexism, inappropriate
language and/or other issues described in our Acceptable Use Policy.)
All outgoing messages are certified virus-free by McAfee GroupShield Exchange 5.10.285.0
Phone: +64 6 843 5095 or Fax: +64 6 833 6759 or E-mail: [postmaster--colenso--school--nz]
[2/19] from: nitsch-lists:netcologne at: 11-Nov-2003 0:32
Am Montag, 10. November 2003 21:28 schrieb Andrew Martin:
> Thanks, Anton!
> You wrote:
<<quoted lines omitted: 20>>
> header. That way, the script application will create it's preferred
> environment, regardless of previously launched library programs.
I agree. Best way.
Ways for inserting are:
1) a script-merger as you suggest. The official one is %prebol.r
2) The main-script as archive, unpack in subdirectory and run.
> Of course, there can be a problem with what to do, when current and past
> Rebol interpreters have faults and need patching. Perhaps we should prod
> Rebol HQ into action? :) It would be nice to have defects fixed, and old
> versions of Rebol interpreters removed.
>
Primarily RT's job IMHO.
But a library of patches would be smaller than The Great Library Of
Everything. So may be manageable.
But the patches could be placed in the app too. A developer gets the patches,
integrates them in the app, releases update.
Also one can insist on a special rebol-version. thats what one does anyway
with sdk. so patching can be more specific. (Java does this now)
> What do you think about it? Is there something I've missed?
>
> Andrew J Martin
-Volker
[3/19] from: robert:muench:robertmuench at: 11-Nov-2003 16:08
On Tue, 11 Nov 2003 09:28:36 +1300, Andrew Martin
<[andrew--martin--colenso--school--nz]> wrote:
> When distributing a Rebol script,
> include all the functions (words) that the main script requires. Of
> course, the problem here is that most of us have nice toolkits of
> functions that we want to use in our main script applications, and it's
> pointless manually copying and pasting from our toolkit because that
> just produces multiple copies, with no definitive, authoritive source.
Hi, IMO that's they way to go: Include all stuff in one script. As long as
this particular script works, there is no need to update the included
part. How to do it? Well, include PREBOL in the core engine. I don't know
why this isn't done. Replace the #... PREBOL commands thru something like
$... and have the interpreter recognize this.
--
Robert M. Münch
Management & IT Freelancer
Mobile: +49 (177) 245 2802
http://www.robertmuench.de
[4/19] from: maximo:meteorstudios at: 11-Nov-2003 10:49
what do you do when the included scripts totalize more than 500k of code?
do you create a 501KB file for each script?
why is run-time linking so bad if the engine is standardized and the resources are centralized
and "official" in some way?
-MAx
---
You can either be part of the problem or part of the solution, but in the end, being
part of the problem is much more fun.
[5/19] from: greggirwin:mindspring at: 11-Nov-2003 9:44
Hi Max et al,
MOA> why is run-time linking so bad if the engine is standardized
MOA> and the resources are centralized and "official" in some way?
Run-time linking isn't bad, but being standardized in "some way" isn't
much help when it comes to reliability.
My opinion, FWIW, having lived through many years of VB development
(I believe you can credit Dan Appleman with the phrase "DLL Hell".
born, perhaps, from the SS3D.VBX fiasco and others that followed):
You can't solve this easily. Either you go all the way and create a
heavy solution or you go in knowing that things are going to break for
no good reason; with no clear source; and no easy way to find the
culprit.
There are probably a zillion ways to do checks, verifications, even
rollbacks with REBOL, but what's the cost versus benefit?
It's a different world now, so you have to figure out for *your* needs
what risk and consequences are acceptable. Will your users be OK with
Sorry, that screen is not available
, crashes, or results that might
look OK, but aren't correct? It's up to you.
-- Gregg
[6/19] from: maximo:meteorstudios at: 11-Nov-2003 13:11
I find it funny that there is so much differing opinions on this topic.
:-D which makes it lively a topic/list to follow and discuss :-)
python is built over a library standard and it is all the better for it. It allows a
large group of developpers to contribute to the package completely transparently. I'M
not saying I like python itself, only that I recognize how its modules ideology has helped
it.
There are things missing in its library methods which do make it a little dangerous to
use to share code, but if it gets placed into the core distribution, it becomes safe
cause its api has to get "locked".
I DO think that python has TOO many libraries and that a greater effort at reducing code
duplication and mismatch should have been done for the core distribution. One obvious
and basic problem is the fact that there are string functions AND string methods, but
NOT ALL methods have function equivalents, which is a bad design IMHO. I'm always wondering
if such and such an operation is a method or a function.... :-(
I'm trying to learn from other's mistake (but can't say I'm an all knowing guru ;-).
Like I said, I'll be releasing more information with more specific details of what I
want to provide as a linkable library system. Judgment by trial. ;-)
The loader's essential functionality is working on my system.
I need to work on a real setup/install application which actually can look up your setup.
this would handler both core and vid setups (text or vid install :-)
-MAx
---
You can either be part of the problem or part of the solution, but in the end, being
part of the problem is much more fun.
[7/19] from: petr:krenzelok:trz:cz at: 11-Nov-2003 19:57
Robert M. Münch wrote:
>On Tue, 11 Nov 2003 09:28:36 +1300, Andrew Martin
><[andrew--martin--colenso--school--nz]> wrote:
<<quoted lines omitted: 11>>
>why this isn't done. Replace the #... PREBOL commands thru something like
>$... and have the interpreter recognize this.
I just hope I don't understand you correctly robert, but aren't you
suggesting having rebol distributed with all of our scripts? That is MS
way of doing things, waste of bandwidth etc. There should be central
engine - rebol/whatever installed on your hd, it should check for its
updates and scripts should come as packages (as IOS desktop does). I
would hate to redownload 500KB each time just because someone changes
one function in script ...
-pekr-
[8/19] from: maximo:meteorstudios at: 11-Nov-2003 14:15
> -----Original Message-----
> From: Petr Krenzelok [mailto:[petr--krenzelok--trz--cz]]
<<quoted lines omitted: 18>>
> would hate to redownload 500KB each time just because someone changes
> one function in script ...
I think the main differentiation which is often missed, is that there is a line between
script and application.
Usually scripts handle one given and succinct task. These benefit from linking.
Applications usually include user-driven, long-standing executables which usually will
be several hundred kb in size. Not because they aren't well programmed, but because of
the sheer amount of things they do...
These don't... this is the target for which steel's library engine is meant.
-MAx
[9/19] from: nitsch-lists:netcologne at: 11-Nov-2003 21:30
Am Dienstag, 11. November 2003 19:11 schrieb Maxim Olivier-Adlhoch:
> I find it funny that there is so much differing opinions on this topic.
> :-D which makes it lively a topic/list to follow and discuss :-)
<<quoted lines omitted: 5>>
> dangerous to use to share code, but if it gets placed into the core
> distribution, it becomes safe cause its api has to get "locked".
In our case that would be, its in rebol-runtime. Fortunally or not, rebols
have decided Carl defines the /core.
Today with RT low on manpower.
Its a bit tricky to decide if something is not included because of manpower or
because it dilutes the core.
> I DO think that python has TOO many libraries and that a greater effort at
> reducing code duplication and mismatch should have been done for the core
> distribution. One obvious and basic problem is the fact that there are
> string functions AND string methods, but NOT ALL methods have function
> equivalents, which is a bad design IMHO. I'm always wondering if such and
> such an operation is a method or a function.... :-(
>
diluting is a good word, specially in connection with liquid, no? ;)
> I'm trying to learn from other's mistake (but can't say I'm an all knowing
> guru ;-).
>
> Like I said, I'll be releasing more information with more specific details
> of what I want to provide as a linkable library system. Judgment by trial.
> ;-)
>
> The loader's essential functionality is working on my system.
>
Another point about a loader is, Rebol has already one. Its called IOS.
Unfortunally its soo expensive.
so
+ building such stuff is fun
+ its a lot cheaper
- makes competition to RT based on its own products?
> I need to work on a real setup/install application which actually can look
> up your setup. this would handler both core and vid setups (text or vid
> install :-)
If its for fun, i am all for it. But you talk a lot about setting standards.
And rebol-standards should be RT's decision IMHO.
-Volker
[10/19] from: nitsch-lists:netcologne at: 12-Nov-2003 1:30
Am Dienstag, 11. November 2003 20:15 schrieb Maxim Olivier-Adlhoch:
> > one function in script ...
> I think the main differentiation which is often missed, is that there is a
<<quoted lines omitted: 6>>
> These don't... this is the target for which steel's library engine is
> meant.
to me scripting means programming fast. And then the requirements to a library
are similar to those to an app. only that i press the buttons with code.
so long-standing, predictable etc are features i like. while auto-updating,
trying to be backward-compatible (instead of using the old script) are a bit
cutting edge IMHO.
> -MAx
-Volker
[11/19] from: nitsch-lists:netcologne at: 11-Nov-2003 21:40
Am Dienstag, 11. November 2003 19:57 schrieb Petr Krenzelok:
> Robert M. Münch wrote:
> >On Tue, 11 Nov 2003 09:28:36 +1300, Andrew Martin
<<quoted lines omitted: 19>>
> would hate to redownload 500KB each time just because someone changes
> one function in script ...
The MS-way of providing everything and keep it out of the system works very
well. unfortunally its not the MS-way, some stuff is always placed in
system-dirs. Overwriting another version. (hmm, is this true today? not a
real windows-user).
The MS-way of providing 501k-applications to download? What do you smoking? ;)
5.01M maybe.
Thinking again, where did you find 501k-scripts? 50,1k-scripts are more
realistic.
Rebol enables us to provide apps this size. Why should we introduce risc of
malfunctions? If it does not work, user spends a lot more time fixing a
problem then downloading everything.
Regarding IOS, all scripts work standalone, there is no script which does
another. And that would be very simple with ios-distribution.
> -pekr-
-Volker
[12/19] from: atruter:labyrinth:au at: 12-Nov-2003 12:19
> Thinking again, where did you find 501k-scripts? 50,1k-scripts are more
> realistic.
Encapped VIEW scripts perhaps? Which raises an interesting terminology
question. If a source script is called a "script", what do we then call it
when it has been encapped? An "executable", "encapped script", "SDK
script", "bound script", "application", "program", etc?
Regards,
Ashley
[13/19] from: moliad:aei:ca at: 11-Nov-2003 22:11
diluting ...
LOL
subtle... I read it a few times before getting it ;-) I'm tired ;-)
I'll keep it my list of reserved words ;-)
Volker, I agree that RT should set the standards. But with so little official speak,
I am tired of waiting. I know Carl S. is protective of a specific plan he has outlined,
I understand, he needs to keep control.
But for x reason its not getting done. I am willing to put effort into it, I already
have, maybe it would be a good idea if We do our stuff and see if RT believes in it.
if so, maybe it will prompt RT to put more emphasis on something much more important,
since a "temporary" solution is available, supported and functional. I want to try and
get in direct contact with RT but not until I have a real release with specs and code
examples.
Would you rather have them put time on increasing view (forget about vid) fixing/improving
the network protocols, finishing IOS applets, etc, etc, etc.
I know I would.
I talk about the COMMUNITY adopting a specific code standard it finds resonable for loading
code dynamically without cause for namespace clash. I am working on a full-fledged tool
as part of the steel project, so I thought I'd at least give it a go to see how it holds
up to public scrutiny (more in terms of capacity/features than in pure code elegance.
This will take an hour or two to improve with all the geniuses on this list ;).
I'll stop repeating myself, but just add that I am the type of person that doesn't wait
on others, including for programming. I'm not saying I frown on RT or others on the
list with different opinions, I just can't sit and look at time pass, Steel has to move
on and it basically depends on linkable libraries, since its tools are so huge. Just
let me release the library tool and then, sink it if you hate it. ;-)
If an RT sanctionned module standard gets done in 6 months well hey, I guess I'll adapt
to it, if it does all I need. I mean the hole amiga os was built on the concept of REAL
shared libaries, it was one of its most attractive design features, I can't forget that.
I was brought-up on the good stuff... ;-)
-MAx
=== Original Message ===
Am Dienstag, 11. November 2003 19:11 schrieb Maxim Olivier-Adlhoch:
> I find it funny that there is so much differing opinions on this topic.
> :-D which makes it lively a topic/list to follow and discuss :-)
<<quoted lines omitted: 5>>
> dangerous to use to share code, but if it gets placed into the core
> distribution, it becomes safe cause its api has to get "locked".
In our case that would be, its in rebol-runtime. Fortunally or not, rebols
have decided Carl defines the /core.
Today with RT low on manpower.
Its a bit tricky to decide if something is not included because of manpower or
because it dilutes the core.
> I DO think that python has TOO many libraries and that a greater effort at
> reducing code duplication and mismatch should have been done for the core
> distribution. One obvious and basic problem is the fact that there are
> string functions AND string methods, but NOT ALL methods have function
> equivalents, which is a bad design IMHO. I'm always wondering if such and
> such an operation is a method or a function.... :-(
>
diluting is a good word, specially in connection with liquid, no? ;)
> I'm trying to learn from other's mistake (but can't say I'm an all knowing
> guru ;-).
>
> Like I said, I'll be releasing more information with more specific details
> of what I want to provide as a linkable library system. Judgment by trial.
> ;-)
>
> The loader's essential functionality is working on my system.
>
Another point about a loader is, Rebol has already one. Its called IOS.
Unfortunally its soo expensive.
so
+ building such stuff is fun
+ its a lot cheaper
- makes competition to RT based on its own products?
> I need to work on a real setup/install application which actually can look
> up your setup. this would handler both core and vid setups (text or vid
> install :-)
If its for fun, i am all for it. But you talk a lot about setting standards.
And rebol-standards should be RT's decision IMHO.
-Volker
[14/19] from: AJMartin:orcon at: 24-Dec-2003 22:46
Volker wrote:
> The MS-way of providing 501k-applications to download? What do you
smoking? ;) 5.01M maybe.
When last I looked at MS Visual Studio plus it's documentation, the total
space required was over 1 gigabyte!
Andrew J Martin
Speaking in tongues and performing miracles.
ICQ: 26227169
http://www.rebol.it/Valley/
http://valley.orcon.net.nz/
http://Valley.150m.com/
[15/19] from: petr:krenzelok:trz:cz at: 12-Nov-2003 9:16
Volker Nitsch wrote:
>Am Dienstag, 11. November 2003 19:57 schrieb Petr Krenzelok:
>>Robert M. Münch wrote:
<<quoted lines omitted: 35>>
>real windows-user).
>The MS-way of providing 501k-applications to download? What do you smoking? ;)
:-)) LSD - Liquid Steel Dialect?
>5.01M maybe.
>Thinking again, where did you find 501k-scripts? 50,1k-scripts are more
>realistic.
>
Well, that is missunderstanding. I thought that Robert is suggesting
encapping our apps, which imo leads to redundancy. I also heard
official places
stating, that it is not too much - but hey, who
started Rebol just because of being more efficient? What about mobile
devices? So you encap your app and you let your users redownload it each
time just because you change one color of a button? :-) I think that -
1) Rebol should become engine - sitting on our HDs, being able to update
itself eventually - kind of JVM. Then you could just distribute your scripts
2) You distribute your app, but rebol is separate and your app is kind
of compressed package, so you can redownload only your app.
Both points save you from redundancy, wasted bandwidth. If your tool
will be downloaded by 10K ppl, you will sing different song, if you are
supposed to 10K * 50x app, or 10K * x package
>Rebol enables us to provide apps this size. Why should we introduce risc of
>malfunctions?
>
When speaking of malfunction, I can tell you following - current
situation is just that - malfunction. View should imo take different
aproach - register/install into registry only when forced to. So, what
is your .r registered to? Base? Face? Core? Command? View? Which one?
1.2.1? 1.2.8? 1.2.10? Command? View/Command? Eh? I hope that if R# sees
the light of the day, there is the promise of ONE single executable kernel, and the rest
being modules. I remember Carl stating that he is
father of modular amiga system, but rebol is not modular, componentised
yet. And I also remember someone stating, that current state (product
diferentiation) is so because of marketing reasons. So - don't you hate
when marketing stands in the way of technology? ;-)
> If it does not work, user spends a lot more time fixing a
>problem then downloading everything.
>
You know better than me that it can be solved by semi-intelligent
system. Amiga works that way, libraries have their version number - what
is the problem? So you better like compromises like uncomplete sound
system, no support for mp3 etc., because it would make View big? Well -
that is way to nowhere. If sound component would be separate binary,
library, module, component, call it whatever - you would not mind it
having e.g. 200 kb, but with current state it would simply make View too
big for some ppl to like it.
>Regarding IOS, all scripts work standalone, there is no script which does
>another. And that would be very simple with ios-distribution.
>
IOS is different. And while it is nice architecture, its main drawback
is just that - all scripts work standalone and I hope competent ppl do
something about it to take IOS further. Complete isolation does not help
anybody ...
-pekr-
[16/19] from: antonr:iinet:au at: 12-Nov-2003 21:27
If you provide a script that just works, and
I don't have to think much about install issues,
then I won't hate it, I promise. :)
Anton.
[17/19] from: antonr:iinet:au at: 13-Nov-2003 13:23
That's not quite how I remember it.
Marketing reasons
means people asked for it.
Anton.
[18/19] from: robert:muench:robertmuench at: 13-Nov-2003 15:42
On Tue, 11 Nov 2003 10:49:21 -0500, Maxim Olivier-Adlhoch
<[maximo--meteorstudios--com]> wrote:
> what do you do when the included scripts totalize more than 500k of code?
> do you create a 501KB file for each script?
Yes. Why not?
> why is run-time linking so bad if the engine is standardized and the
> resources are centralized and "official" in some way?
...in some way
That's the problem. There is more than one way to do it.
One EXE file is simple to move, copy, distribute etc. Users just download
it, start it, use it. That's it. KISS. Robert
[19/19] from: maximo:meteorstudios at: 13-Nov-2003 11:19
In some way
has been quoted negatively, twice.
Note that it is preceded by "official" which means that there is yet, no official way
to do it, but if there was, THEN there would be no complication, there would be "a way"
to do it, supported, documented and used by more than one person. Much like rugby, make-doc(pro)
and many other tools have become rebol standards, through intersting featureset and adequate
support.
there is a lot of talk of the "dark side" of run-time linking and the fear it inspires...
here is one little proactive view of the good side of run-time linking:
--------
By leaving a library module external, the user can upgrade parts of his code without
you needing to tamper with newer/better/faster versions of other peoples tools, you use.
Remember that the point in creating an officially sharable module, is that it LOCKS an
api. much like amiga's APIs are locked yet frequently improved. If something cannot
be successfully patched, extend the api. This keeps older softwares using the library
still 100% functional, while leaving new options for more up to date users. When the
changes are too drastic, maybe its time for a big version number increase or a new library
altogether.
The library still is a rebol script, so (if the library's license permits it) you can
still just copy the code in your application if you prefer.
Also, something which is to be noted, is that some libraries could be meant for inter
process tasks, its much more stable if both apps use the same version of a library module,
which will not be the case if both include the code instead of linking to it at run-time.
Again, this all depends on the quality of the api which is included in the library a
script uses. If the author of a library keeps adding buggy changes, then yes, you are
better off copying his code, since you aren't confident that his next version will be
compatible... which would make your dependent app unstable. But by definition, creating
an "officialy released" library module means that you must put though and design in the
API of your tool.
I am not trying to prove you wrong, I'm just illustrating, for anyone listening to the
discussion, some of the real advantages of keeping code external, when the code itself
is well planned and implemented.
peace! ;-)
-MAx
---
You can either be part of the problem or part of the solution, but in the end, being
part of the problem is much more fun.
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted