[Os-project-managers] Question about OSxLParserdata, OSInstance, OSOption

[Kipp Martin]

Hi Gus:


> 
> Ah!!! I had not taken this point onboard. This is indeed significant.

Well actually there still is a problem but I don't have time to write 
out a detailed email because I am taking off soon for the day. We can 
discuss next Wednesday. Right now, "in theory" one never ever modifies 
the "original" OSInstance object. Of course theory is different than 
practice and we can discuss.  The OSModification will be for modifying 
an OSInstance. I envision OSModification as storing a set of 
modification objects that can be applied to an OSInstance object. It 
would work much like a word processor where you can edit your document 
but then under the "edit" menu item hit "undo" multiple times to get 
back to where you were.
> 
>>> Can I summarize the state of affairs as follows: The constitution
>>> requires OSInstance, OSResult and OSOption, but for efficiency it may
>>> be more expeditious to switch to a flat storage scheme. Is that fair?
>> Yes, absolutely, Jun has made this point a number of times.
> 
> OK. Hope I will remember this time...
> 
>>> Can I also ask about set() methods? I noticed that OSParseosil.y
>>> stores things into the OSInstance object directly; for example in line
>>> 1109:
>>>
>>> osinstance->instanceHeader->name = pelementText;
>>>
>>> or in line 1440:
>>> 					osinstance->instanceData->variables->var[varcount]->lb
>>>          = atofmod1( osillineno,attText, attTextEnd);
>>>
>>> One of the things that is slowing me down is the endless writing and
>>> invoking of set() methods to get the data into the OSOption object.
>>> Was that even necessary? Should I have left in the old
>> No it was not necessary.
>>> osoption->general->serviceURI = $3;
>>>
>>> in place of
>>>
>>> if (osoption->setServiceURI($3) == false)
>>>         osolError(...)
>> Yes, probably so.  I even asked you about this specific point and we
>> discussed it. I was surprised you wanted to use the set methods but did
>> not object.
> 
> I clearly misunderstood. I was under the impression that the set()  
> methods would be prefereable, and that`s what you wanted me to use. My  
> bad. Could have saved enormous amounts of time...

I don't think it is a big deal for OSOption or OSResult.  That is why I 
did not object.
> 
> But it`s too late now to switch. I will continue doing what I have  
> been doing so that we get something out of the door.


I agree, do not change at this point.


Sorry for all this confusion.

Cheers
> 
> Cheers
> 
> gus
> 
> _______________________________________________
> Os-project-managers mailing list
> Os-project-managers at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/os-project-managers


-- 
Kipp Martin
Professor of Operations Research
and Computing Technology
Booth School of Business
University of Chicago
5807 South Woodlawn Avenue
Chicago, IL 60637
773-702-7456
kmartin at chicagobooth.edu
http://www.chicagobooth.edu/faculty/bio.aspx?person_id=12825325568
http://projects.coin-or.org/OS