[Os-project-managers] Fwd: Re: interactive shell

[Kipp Martin]

-------- Original Message --------
Subject: Re: interactive shell
Date: Tue, 20 Dec 2011 21:33:54 -0400
From: Horand Gassmann <Horand.Gassmann at Dal.Ca>
To: Kipp Martin <kmartin at chicagobooth.edu>

Kipp Martin <kmartin at chicagobooth.edu> wrote:

> Hi Gus:
>
>>
>> I have thought about it some, and I think we can get away with three
>> arrays. I propose to use commandArray and optionArray in much the same
>> way as now, except that commandArray is going to have only six entries,
>> corresponding to the six service methods. The optionArray corresponds to
>> the command line options. A third array corresponds to what I would call
>> actionItems, help, version, reset, quit, exit, printModel, printRow.
>> These are items that are acted upon right away, without going to
>> InvokeServiceMethod. Items in the optionArray are added to the command
>> line, and when a commandArray item is encountered, we add the
>> appropriate serviceMethod to the command line and call InvokeServiceMethod.
>
> My initial reaction is that I really like this breakdown, I think it
> is significant progress. What I don't understand is how the
> interaction with the OSSolver object works. I think the way we
> thought about the OSSolver object was passing its constructor a
> command line. But that no longer seems sufficient. Consider the
> following steps a user might want to do in the interactive shell:
>
> Step 1: Specify an OSiL file
>
> Step 2: Print the corresponding model.
>
> Step 3: Solve the model.
>
> I certainly think the above is logical, or at least not totally
> crazy. I can see why a user might want to look at the algebraic form
> of a model before calling the solver. In order to print the model,
> the OSiL file has to get transformed into an OSInstance. This is
> absolutely required. But isn't this transformation done by the
> OSSolver object? So the OSSolver object needs to see the command
> line as it currently exists. Now the user wants to solve, so do we
> again we send a command line back to the OSSolver object? Now what
> if we have
>
> Step 2.5 Speficy and OSoL file.
>
> I can't get my hands on what the OSSover API should look like.

I am not so sure either. It is clear that we should not parse the same
osil file into an OSInstance twice. So if we print the model, we will
have to keep the OSInstance. The most likely place would be as an
object in OSSolver.

But have a look at the current OSSolverService.cpp, line 1722. We are
calling the scanner after every iteration, and we use that to populate
the OSOptionsStruc object. Myabe this is some feature we have to keep.
Maybe we have to hide a bunch of stuff behind set() methods. I don`t
know. I am just throwing out ideas. It also seems that we should have
an OSInstance and OSOption object inside OSSolver, and perhaps we
should fold the entire OSOptionsStruc into the OSSolver class.

Cheers

gus