Re: Libraries and effiency
Re: Libraries and effiency
- Subject: Re: Libraries and effiency
- From: Tommy Bollman <email@hidden>
- Date: Wed, 11 Aug 2010 21:08:41 +0200
On 9 Aug 2010, at 07:44, Tetsuro KURITA wrote:
> Thanks for comments on ModuleLoader.
>
>> Last night I looked at Tetsuros code, and his way of make this mechanism work, taking for granted that the code does what it is supposed to do. It is all very clever, but IMHO, this approach is dangerous.
>> The things I find dangerous is that you can't hardcode paths to libraries, and that the module loader will search several libraries and use the script library found in the latest path. It is stuff like this that creates situations where it is very hard to detect what is really going on when something is at err.
>
> The way of finding libraries of ModuleLoader is similar to other script
> language i.e. Perl, Ruby and so on. Also AppleMods have same way. This is
> widely adapted.
>
> Off cause, Using hardcode paths is simple but cause a tough problem that
> you must manage library locations by hand.
>
> History and other systems show that it's a good way to avoid hardcode paths
> to libraries.
The system is very good for developers, no doubt about that. But for users… not so good, when their base - framework is out of sync, as a matter of fact I think we should aim higher, than the scripting frameworks of perl and ruby, just lets face it, the average AppleScript user, isn't that into it at all, we need something simpler and easier to resolve shall we make people into using others libraries.
AppleMods solution is by the way both worser, and better than yours. The part with using the item from the newest folder, is definitively a much worser idea, than specifying the order. The idea of using versioning numbers in the paths is much butter.
What I'd really like would have been your Osaxes and loaders to just override the load script command of applescript. -If you can.
That load script command should of course fall back to the normal behavior of load script - and run script, if it detects that the path is hardcoded or don't reside within a realm, where loadable modules are to be found.
We really need something simple. :)
>
>> Predefined paths and all that, is really modern,, and gives AppleScript a load mechanism like all other languages. But the names of the libraries loaded should always be unique if they are to be loaded by such an implicit method. It should as a matter of fact be disallowed to use the same name for a library residing in two different directories.
>
> ModuleLoader allows duplicated libraries's name, because libraries can be specified by a sub paths from predefined paths.
>
> For example;
>
> property ModuleA1 : module "subfolder1:ModuleA"
> property ModuleA2 : module "subfolder2:ModuleA"
>
I didn't think you could do that.
>
>> I have a very different approach, and a different idea. I also use predefined paths in the Library Loader to pick the library you want to create a load statement for. -The Library Loader then creates a hardcoded statement for you. And you don't have to load the library from any of the predefined paths, you can pretty much pick it from wherever you like, if you are testing something.
> ModuleLoader have "Local loader" function for such requirements.
>
> http://homepage.mac.com/tkurita/scriptfactory/software/OSAX/ModuleLoader/manual/en/06_local_loader/contents.html
You can't really compare the two solutions, as mine ends up with hardcoded paths, -with their problems, but they are never any doubt about what you tried to load.
>
>> The LibraryLister, which will be updated in the near future, will need Tetsuros permission to render his code at MacScripter.net, If I am to support the dependencies, This goes for AppleMods as well.
>
> Off course you can reuse my code if you follows the ModuleLoader's license
> i.e. GPL. But before building your original system, you should try to improve
> existing system. I believe ModuleLoader have enough flexibility to meet your requirements.
>
> In my case, I tried to modify AppleMods's LoaderServer before starting own
> project. There was no development activity and no responses from AppleMods'
> s community (at least when I tried to make a contact.). Also I felt differences
> of technical preferences. Then I have developed own system from the scratch.
> ModuleLoader have many advantages and easy of use compared with AppleMods.
> Because I respected AppleMods and learned many ideas from it.
Then I will put in a statement that your code is GPL, -your licensing statement, and not use more than I have to if I use it. -I will use Spotlight.
>
>> Here dropping the needs for tracking dependencies and from which path the library script is taken from is obvious.
>
> Tracing dependencies is very important.
> The system without resolving dependencies is not useful.
> Don't drop it.
I can't. Both you and Hamish rely on it.
>
>> As the hardcoding of paths saves a fair amount of processing time and disk IO.
>
> You should judge depending on actual impact on the performance.
> If libraries are loaded at compile time, no performance loss.
> Even if libraries are loaded at run time, no big impact on performance in
> many cases.
>
> You should remembers things lost by using hardcoded paths.
>
Well, part of what I do, is listing the stuff that are in the code on the fly, while you code, will it is being written, and there is certainly a performance loss, in having to resolve dependencies. -In addition, to figuring out which modules to use under resolution of the build. :-)
I have thought it basically through, and I might be able to speed the process up, as much as possible, without rescanning more than necessary after the first scan is done.
>> The idea here is to list everything in a script which contains something, except for script objects which only contain properties, and the ability to automatically open that file for inspection.
>
> I could not find your system.
> I hope a download package to confirm your system.
My system is not quite finished yet, but it works for hardcoded library paths as we speak, but without resolving dependencies of any kind, it can be found in parts and will be integrated into a whole.
< http://www.macscripter.net/viewtopic.php?id=33712 > Server and script for listing handlers.
< http://www.macscripter.net/viewtopic.php?id=33487 > Script and sound server ! to insert loadstatments, open scripts from predefined paths , show them in finder.
< http://www.macscripter.net/viewtopic.php?id=33763 > show differences between to applescript files.
< http://www.macscripter.net/viewtopic.php?id=33821 > scripts which opens hardcoded paths in editor.
< http://www.macscripter.net/viewtopic.php?id=33808 > script server skeleton
I would like to add is that the ideal solution as I see it, is that you and Hamish collaborated on creating one common loader system,
which uses his versioning number system. but your loader mechanism. Any overriding of anything, for developer purposes should be done
in a project specific property.list file, any user specific changes to the system should be done as specified by Philip. Aker. Your osax's loader command should override the load script command, to make it tackle both hardcoded paths and direct implicit paths to module directories.
This would be the ideal situation to this whole debacle. -And I hope for some support on this view.
>
> =======================================================
> Tetsuro KURITA
> E-mail: email@hidden
> http://homepage.mac.com/tkurita/scriptfactory/en/
> =======================================================
>
>
>
Best regards
Tommy Bollman
--------------------------------------------------------------------------------------------------
Mollison's Bureaucracy Hypothesis:
If an idea can survive a bureaucratic review
and be implemented it wasn't worth doing.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden