Skip to content
This repository has been archived by the owner on Jul 11, 2021. It is now read-only.

allow multiple .dyna files on command line #40

Open
jeisner opened this issue Jul 3, 2013 · 6 comments
Open

allow multiple .dyna files on command line #40

jeisner opened this issue Jul 3, 2013 · 6 comments
Assignees

Comments

@jeisner
Copy link
Collaborator

jeisner commented Jul 3, 2013

jasoneis@a14:~$ ls *5.dyna
anagram5.dyna  subst5.dyna  swap5.dyna  swapadj5.dyna
jasoneis@a14:~$ dyna -i *5.dyna
usage: interpreter.py [-h] [-i] [--plan] [-o OUTPUT]
                      [--post-process [POST_PROCESS [POST_PROCESS ...]]]
                      [--load [LOAD [LOAD ...]]]
                      [source]
interpreter.py: error: unrecognized arguments: subst5.dyna swap5.dyna swapadj5.dyna
Saving crash as jasoneis:2013-07-03:17:38:09:32508.log ...
@timvieira timvieira reopened this Jul 3, 2013
@timvieira
Copy link
Collaborator

With the same interpretation as concatenating them together?

@jeisner
Copy link
Collaborator Author

jeisner commented Jul 4, 2013

Yeah, concatenated in the order given. Seems a pretty standard Unix
interpretation of giving a list of files to something that reads stdin.

(There are times when one might want to load multiple dynabases under
different names, but that should probably require a little extra
command-line syntax to specify the names. Or a command-line flag to
indicate that default dynabase names should be derived from the filenames;
these names would have to be single-quoted if they are not ok as
identifiers. We could also define aliases of the form $loaded(0),
$loaded(1), ... as well as $loaded("foo.dyna"), $loaded("bar.dyna"), etc.
I'm thinking that we'd like to support generic processing of a list of
files; have to work out the details.)

@nwf
Copy link
Owner

nwf commented Jul 4, 2013

Working on making the compiler understand. Amusingly enough, the parser framework does not seem to have this right; investigating.

@ghost ghost assigned nwf Jul 4, 2013
@timvieira
Copy link
Collaborator

I don't understand why we want this. (Python doesn't take multiple files. gcc/javac do, but they do something different with it.)

In your example of loading multiple dynabases, you should either type those in at the repl our write a file which imports them and give them names.

@jeisner
Copy link
Collaborator Author

jeisner commented Jul 10, 2013

We don't have multiple dynabases yet (that comment was looking ahead). All we have is concatenation of stuff specified in different .dyna files. So in fact, this is a lot like providing multiple files to javac, with different parts of the program defined in different files but intended to work together.

At the moment, I want to run forward-backward (encapsulated in forward_backward.dyna) on various data and initial HMM parameters (encapsulated elsewhere). E.g.,

dyna icecream_data.dyna icecream_hmm.dyna forward_backward.dyna

Each file is short enough to be comprehensible by itself, and I can easily invoke the command line with different choices for the first two files -- trying different initial parameters, or switching from weather reconstruction to POS tagging.

Right now, I have to cat the files together and make up a name for the result and then run dyna on that, which is a pain.

Note: The load command doesn't yet make it possible to suck in new rules from a .dyna file (even though I think you can use a load command at any time to suck in new facts from any non-.dyna file). How about an "include" command for this, by analogy with C's #include? I am suggesting that .dyna files on the command line are included.

@jeisner
Copy link
Collaborator Author

jeisner commented Jul 10, 2013

Right now, I have to cat the files together and make up a name for the result and then run dyna on that, which is a pain.

Especially since error messages give line numbers in the concatenated file. They should refer to one of the original source files (which of course is impossible in the current design).

timvieira added a commit that referenced this issue Jul 10, 2013
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants