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

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