Meet the Community
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Global application repository

Post new topic   Reply to topic    The Falcon Programming Language Forum Index -> Tech Jargon
View previous topic :: View next topic  
Author Message
Site Admin
Site Admin

Joined: 08 Oct 2006
Posts: 200
Location: Milan

PostPosted: Sat Jan 12, 2008 8:56 pm    Post subject: Global application repository Reply with quote

From a letter of mine to Jeremy...

One of mine ideas Smile

Do you remember the talk about the load path that a script may be willing to know?

The effect is this:

gian@hplin:~/Progetti/falcon/projects/faldoc/tests/samples$ falcon -L ../../src ../../src/faldoc.fal simple.fd
faldoc - Falcon documentation tool.
Part of the Falcon Programming language.
Version 1.0.0
faldoc: FATAL ERROR - Cannot find or load module (faldoc_output_)html

It's obvious; the load directive works because I passed -L ../../src on the command line, but the script (and it's Compiler() instance) has not this information.

On firsts, I just thought to add a falconLoadPath global variable to be filled as it's done now with args[], scriptName and scriptPath.

This would work, would be enough and would be easy to do, but I thought a step forward: it would be nice to have a more flexible interface called vmInfo(); you may pass "loadPath" to it to get the "expected" load path, and so on.

Then I thought a step forward again. The point is, what happens in the "final stage", when we install faldoc on the target machine?
We'll have faldoc.fal somewhere in the system, possibly not on the standard load path; its static
modules (i.e. in this moment faldoc_version and faldoc_parser) *should* not be in the standard load path anyhow (this for code cleanness) and finally the dynamic modules (as i.e. the output modules) may still be somewhere else.

Who has this informations? -- the installer.

How can we pass those informations to a deep script creating an instance of the Compiler() class?

One way would be that of add everything to the load path through a .sh in the bin/ dir; something that may call

falcon -L<path_to_faldoc>;<path_to_faldoc_mods>;<path_to_faldoc_dyn_mods> faldoc.fal $*

But this is tricky and far from portable. Also, this would solve the problem when we just have a path to pass, but what about other resources?

So, how can the installer pass the informations to the script?

One way would be that of messing up with the sources, and hardcoding the parameters into them at installation. But I would hate such a solution, as it would prevent using pre-packed binary archives.

For once, a good idea came from Windows.

What about a central registry of application information?

The file /etc/falcon.ini (or any other file) may contain sections holding variables that may be accessed by scripts through a common interface, as i.e. an extension of the config parser.

I.e. a SysConfigParser() instance would automatically detect the system-wide configuration, searching <scriptName>.ini and then falcon.ini in sensible places, automatically loading a configuration and importing configuration dictionary as sensible.

In this way, each falcon "application" may be known at system level, and it may access those information read-only; then the application may still configure itself for finer tasks.

For the moment, I am just adding the variable, as we must concentrate on making the loader to work, but i would like to have more opinions.[/i]
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    The Falcon Programming Language Forum Index -> Tech Jargon All times are GMT
Page 1 of 1

Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by php B B © 2001, 2005 php BB G r o u p