[M3devel] proposal for dealing with lazy console--please review and comment!

[Randy Coleburn]

Thanks Rodney and Jay for your comments.
 
Here are a few points I'd like to add to this discussion.
 
1.  I agree with Jay that command line arguments would be better than environment variables.
 
2.  I agree with Rodney that the "laziness property" must be set before data gets read/written and that it should be set only once, not changed during execution.
 
3.  A drawback to using command-line variables (and env vars) is that it shifts the responsibility from the programmer to the user.  IMO, this type of behavior is something that is "designed" and documented as part of the program, so it should not be changeable by the user.  For example, if the user fails to put the appropriate parameter on the command-line, the program's behavior changes.  In effect, this is sort of what has happened to me, that is, the behavior of my cm3 v4.1 gui-mode program(s) has changed from its design because the underlying implementation changed to use lazy console allocation and I have no way of getting the old behavior back without changing the implementation.
 
4.  Perhaps a better approach would be to devise a new option for the compiler.  For example, "-gui" works as now and uses lazy console allocation.  "-gui_no_lazy" works the way -gui did in 4.1 where the Stdio.stdin/stderr/stdout would be NIL for a gui-mode program.  The problem here is I'm not sure exactly how to implement it.  In effect, use of this option would mean we would need to swap (i.e., choose) the implementation of Process.m3 at compile time, OR we would need some way to ensure the Stdio variables get set to NIL after the current Process.m3 initialization (thereby undoing the lazy allocation).  Maybe one of these methods can be done via quake somehow, but I'm not sure how to go about it.  Any ideas?
 
5.  If I'm the only person having this issue with the lazy allocation, perhaps I can adapt my programs.  Perhaps I can just set the Stdio variables to be NIL at the beginning of my mainline code for programs I know should be compiled as -gui.  This brings to mind an idea for how to implement -gui_no_lazy.  Do you think we could write some quake code that causes a new module implementation to be included in the program whenever the target is NT386 AND the -gui_no_lazy option is set?  This new implementation would import from Stdio and all it would do is set the Stdio vars to be NIL.  Since it imports from Stdio and Stdio imports Process, I would tend to think that Process and Stdio module initializations would be run before this new module initialization thereby ensuring the lazy allocated consoles get set to NIL.  What do you think?
 
Regards,
Randy

>>> "rodney.bates" <rodney.bates at wichita.edu> 6/21/2008 10:18 AM >>>
I guess I am on a somewhat different wavelength on this.  I do
agree that a complete set of queries by the application should
be supported, concerning lazy allocated streams.  But to me,
applications need to have either very little or nothing in the
way of ability to change behaviour.

For one thing, it makes sense for the lazy property to apply
only to stdout/stderr, on win32 platforms, compiled as -gui.
This is why I was questioning getting a stream from FileWr.Open,
and then setting it lazy.  Laziness doesn't make any sense on
a disk file.

Beyond that, I think at the most, an application should be able 
to change the laziness property only before any data has been
written to the stream.  After that, the window is already popped,
and the semantics would get ugly.

In fact, I am very skeptical about the need for an application 
to change laziness at all.  If it can query this property, then
it can just refrain from writing to the steam, if it doesn't want
the window to pop up.

Hence my objection to making the properties variables, not because
of general principal, but because an application could assign to
them at any time.

>===== Original Message From Jay <jayk123 at hotmail.com> =====
>set CM3_ConsoleBehavior=4.1
>m3guiapp
>console behavior still changed
>
>m3guiapp @M3ConsoleBehavior=4.1
>console behavior back to "default"
> - Jay>

Rodney Bates
Retired assistant professor
Computer Science


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080621/33b3ae00/attachment-0002.html>