[Os-project-managers] responsetokipp

[Kipp Martin]

-------- Original Message --------
Subject: Re: update
Date: Mon, 9 Jan 2012 21:11:02 -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:
>
> A few things:
>
> 1) I feel very strongly that the OSCommandLine object should never
> ever create an OSInstance. I think the OSCommandLineReader should
> take the command line and put the various command line values into a
> data structure. In this case OSCommandLine is taking the place of
> the old OSOptionsStruc. End of story. That is all it should do.
> Store what was on the command line in a convenient fashion so that
> calling programs can get at the data.

Well, that is fine. However, in order to get from nl to osil you have
to go via an OSInstance, as well as an OSOption. You simply have no
choice in the matter. And I feel very strongly that going to an
OSInstance is *not* something you do just to pass the time. There has
to be a reason for it, and when you get an OSInstance, you should not
squander it and do it again. It just makes no sense that you would
throw away information like that.

> 2) So now there is the issue needing an OSInstance object in both
> OSServiceMethods and OSSolverService if you want to print. I don't
> think the OSServiceMethods should ever print. I think only
> OSSolverService should print.

Again, no problem, but then you have to have a place to store the
OSInstance necessary to facilitate that print, and you have to have
the logic (and complicated logic it is) to make the OSInstance from
the other pieces of information you might have. We currently have this
logic replicated in four different places. This is unmaintainable.

> 3) I don't think the OSServiceMethods should ever have an
> OSInstance. Why would it ever need it? It takes the oscommandline
> object and either does a remote solve, send, or whatever or a local
> solve. Why does it need an OSInstance? It certainly can't send an
> OSInstance over the Web, and it can call a local solver and give it
> OSiL.

It needs an OSInstance to create the proper osol string (and osil) if
you started out with something other than OSiL format.

> 4) Now for the print problem. Let's take OSSolverService. It passes
> a command line string to OSCommandLineReader and gets an
> OSCommandLine object back. If there is an OSiL file present, it
> parses it with an OSiLReader, creates an OSInstance and prints the
> model in infix format.

The print command is small potatoes. I view the nl to os conversation
to be far more crucial, and that requires an OSInstance. *As a
byproduct* you get the OSInstance also, essentially for free, in cases
where you need to do a print, *as long as you store the OSInstance in
the right place*.

> 5) It should be the responsibility of the calling program to
> create/destroy and OSInstance or do the printing. OSServiceMethods
> and OSCommandLine should never be creating an OSInstance. Unless I
> am missing something it seems totally unnecessary.

I want to make sure that the code to go from the input in file format
to an OSInstance/OSOption is kept in one place. I don't care if that
place is in an include file somewhere or a new class, I don't care
what it is called; I just want to eliminate the proliferation of
complicated logic all over the place, and I want to make sure that the
conversion is done once only. If you have to print a row, you should
not have to pay the price of parsing a multi-million
byte file hat gets deleted as soon as the print is done. This is just
too wasteful for words.

> My philosophy is that OSCommandLine, OSCommandLineReader, and
> OSSolverServices should be light weight. I am not at all bothered by
> the fact the there may have to be some duplication of code in the
> calling programs.

It does bug me tremendously, because it is not just "some
duplication"; it is pretty complicated logic, cascading down the
possible input files (OS, MPS, nl, dat, etc., etc.) That stuff *has*
to be in a single spot.

> I also understand that it could be the case that we do a local solve
> in which case an OSInstance is created in the OSSolverInterface, and
> a second OSInstance is created in OSSolverService if we need to do a
> print. I don't care! I much rather have something like this and keep
> the architecture simple. Also, I don't think I have ever done both a
> print and solve from the OSSolverService. Is see this as a nonissue.
>
> Tuesday for me is a teaching, workshop, and faculty recruiting day.
> Do you want to talk on Wednesday? Or is that your bad teaching day?
> I seem to recall Monday and Wednesday are your teaching days and
> Tuesday and Thursday mine.

Unfortunately we seem to be working on more or less orthogonal
schedules for the next few weeks. On Wednesday I teach (central times)
from 8:00 to 9:30, from 11:00 to 12:30 and from 2:00 to 3:30. I have
office hours from 12:30 to 2:00, but I see a few students in the first
few minutes, and I could perhaps squeeze in a call during that time,
as long as we can keep it to half an hour or so. After my last class,
I am pretty wiped, and I am expected home.

Cheers

gus