Kara-Moon Forum

mma-gb does not process the .mmarc. Should it? Maybe...

In my setup, .mmarc adds some additional library locations to $_LibPath. Since mma-gb does not process .mmarc, grooves that are in the additional libraries are not available to mma-gb.

mma-gb should process the .mmarc, but probably it is better to call mma and ask for the actual library locations. Something similar to -Dk.

Good thought. I've added this to the TODO file for mma. Problems:

  - don't want to duplicate the search/read from mma to mma-gb. Really should keep things like that in one place, and only one place

  - no way, just now, to get mma to report a specific search path. Maybe have a command like "mma -paths" to report?

Anyway, leave it with me and I'll look at it all. Thanks for the idea

This is a close I can get:


For serious purposes, maybe writing out the complete config (which will still be small) in JSON?

Of course the big question is "at what point do we grab the config" to print out? After all the config files have been processed or right after the initial setting of paths (which would be before reading a .mmarc file)?

Definitely after processing the .mmarc... That's what started this discussion.

What do you think of this ...

Add a -x option "Print" which will take all the things passed, expand them, and simply print out the values. So, we could do:
 
    bob$ mma -xprint "\$_libpath \$_incPath"

and, magically, get the values.

Note: the "\" is just to protect the "$" from the shell.

Code (not debugged!) is simple. Just make the end of xtra.py look like this:

 
Next, it's simple to add code to mma-gb to query mma for the needed path info.

This will do the job, for the time being... As long as there are no spaces in path names.

Alternative: --xqvars that takes a list of variables and dumps a json:

This is getting quite complicated :) The problem is reading the RC file before reporting. MMA really needs some kind of input file and creating one is getting, well, "creative". Much simpler is to:

1. Create a simple MMA file with PRINT lines in it. Simple enough for mma-gb to create a temp file with this (or even do it via stdin)

2. Call mma with the temp filename (or - and send that back, but I'm not sure if that is system independent).

3. Capture the output from the temp file, delete the temp file, process the output and live happily ever after.

If all we need are system variables ($_Libpath, $_mmapath, etc) then we don't need to read any RC files. Simple.

But, if we need to read the RC then mma's insistence on having an input file complicates life. If it were important, I'd certainly do the coding (and generate bugs), but the "read temp file" certainly seems much easier and (?) bullet proof.

Just getting a list of MMA's paths and then have the application read the RCs means that the application needs to know how to read a .mma file :)

Comment?

Agreed.

Well, this is what triggered the question. I change LibPath and MMAPath in my .mmarc.


Maybe we should take this back to the drawing board.

Originally MMA was developed to be run from a single place, with a single library of modules and grooves etc.

I am probably the first user to maintain a set of private grooves, plugins, and so on in my home folder.

A first complication is that when I run mma -g it complains about me not having write access to the system files (e.g. /usr/share/mma). That is okay, but what I usually want is to update the .mmaDB files in my home folder. So it would be nice if MMA would skip the system folders. So instead of enumerating all files that were skipped:

just a simple


To get back to the mma-gb issue: Maybe introduce two environment variables MMA_LIBRARY (or MMA_LIBPATH) and MMA_PLUGINS (MMA_PLUGPATH) that take a list of directories to be prepended to $_LibPath and $_PlugPath? It would be rather straightforward for mma and mma-gb to deal with.

Maybe MMA_LIB as well? MMA processes a fixed list of directories and considers the first directory with a subdirectory MMA to be the MMA library. It really should use a list of paths instead of a fixed dir.

Okay. Let's do one or two things at a time.

First, the -g behaviour can be changed. I'll do it later ... don't see any problems.

Second, adding MMA_LIBPATH and MMA_PLUGPATH env variables. Again, no problem ... I think that prepending the values makes as much sense as anything else. I'll add the appropriate calls in main.py around line 64 after the call to paths.init().

Great, thanks!

Related...

mma -I myplugin fails if myplugin resides in a path set (or augmented) by .mmarc.

I'll have to look at that later today ... well, just did :) Not that this helps, but it works here.

I created a new directory ~/mmaplugs and added, to my .mmarc file,

   setplugpath ~/mmaplugs $_plugpath

moved a plugin directory to ~/mmaplugs and ran a test file. No problems.

 ... are you sure the mmarc file is being read?
 ... did you check the command?
 ... in your song file, could you do a print $_PlugPath
 

Oh yes, that all works...

What doesn't seem to work is the -I option (mma -I plugin). It is shortcut in options.py.

Oh, sorry ... guess I was not doing proper reading :) I'll look into this.

Oh, I see what's happening ... and it's not a pretty answer  >:D

The problem is simple: the option parser handles the printing of the help requested by -I<name>. And, this is long before any env variables are set or RC files are read.

There are some "solutions" that I can see:

 - Simply leave it as is and document the behavior. This is my preferred option
   since it leaves working code working. I could also suggest that the -I<plugin>
   function can be accessed from a file ...

 - Have the option set a flag and handle that in main after the RC file is read and
   the env variables are handled. I _think_ it could be done right after the reading
   of the initial RC file around line 103 of main.py. My niggly here is the creation of
   one-more-flag ... and I hate using one-shot flags ... but that's probably not the
   end of the world. HOWEVER, we also have the other problem on not having an
   input filename. One more test and workaround :)

Comment: would it make sense to have a special filename signaling that no input is expected? I'm thinking that this might set the input filename and setting the nooutput (mma -n) flag at the same time. Maybe force stdin if no filename is set? Sounds like ugly musing.

Question: how important is this feature?

I think there is a design flaw in the way options are handled: Comments/ideas/input are needed.