<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
> 3. A drawback to using command-line<BR>
> variables (and env vars) is that it shifts<BR>
> the responsibility from the programmer to<BR>
> the user. IMO, this type of behavior is something<BR>
> that is "designed" and documented as part of the<BR>
> program, so it should not be changeable by the user. For example, if the <BR>
<BR>
What is constant behavior and what is settable by the user is obviously one of the big sets of questions any programmer must face. No one behavior suits everyone, and too many configurable options are confusing and harder to test. If you make everything configurable, you just ship the consumer nothing and let him "configure" it to do what he wants. Consumer can have any color Ford Model T as long as it is black...<BR>
<BR>
Anyway, I think the compiler command line option is reasonable, and implementing via "customizing" main to pass down the switch to runtime, while I expressed possible misgivings about it, I think is reasonable. Adapting quake to output different modules and all that I think is overkill.<BR>
<BR>
The main <=> RTLinker interface should probably be a little self describing anyway.<BR>
And this might be main talking right to ProcessWin32 anyway.<BR>
<BR>
One thing I don't understand is how much Modula-3 code can be run before RTLinker.<BR>
How much runtime linking does Modula-3 do itself, vs. how much code comes in from disk already ready to run. It could, heck, be C code or data if that helped. But just as well, it could flow through RTLinker en route to ProcessWin32, if that is necessary and the C and data exports are to be avoided.<BR>
RTLinker does seem to do a lot more work than is "normal", in the C build model.<BR>
That is, it *appears* you can't make cross Modula-3 module calls, even within the same .so/.exe/.dll. Kind of lame if true, given that many intra-module calls are already going unnecessarily through runtime linking a the C level (that problem I hit on AMD64_LINUX where the static link gets trashed by this unnecessary indirection; as well as where I believe I have deliberately removed this unnecessary indirection in my SOLsun configuration files).<BR>
(This is that simpler focused email I owe...)<BR>
<BR>
- Jay<BR>
<BLOCKQUOTE>
<HR>
From: jayk123@hotmail.com<BR>To: rcoleburn@scires.com; m3devel@elegosoft.com<BR>Date: Sat, 21 Jun 2008 16:04:27 +0000<BR>Subject: Re: [M3devel] proposal for dealing with lazy console--please review and comment!<BR><BR>
<META content="Microsoft SafeHTML" name=Generator>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Tahoma;}
</STYLE>
4 (compiler switch) and 5 (adapt your code) are easy enough, though 4 I have *possible* misgivings about.<BR> <BR>There is in fact an interface whose data flows like so:<BR> run the compiler <BR> it produces "startup" code (_m3main.o/_m3main.obj/_m3main.c) <BR> that startup code passes data to the runtime (RTLinker) <BR> <BR>I mucked around here to fix environment variables.<BR> <BR>The "problem" here is that compiler <=> runtime interfaces must be carefully dealt with..perhaps.<BR>I am not sure what our compatibility requires are. I don't think Modula-3 binaries are really deployed so far and wide, and old and new .dlls/.so mixed much. So probably this interface can be churned without much concern for what it was in the past. Perhaps.<BR> <BR>Whatever data flows around here should probably be a record that starts with a size and contains a "set of int" (ie: bitflags) for every field, or every field added after a certain point, and reserve enough room for there to be enough bit flags for a long time. This is a part of a path to "release to release binary compatibility". Or maybe the type fingerprints are it and there isn't really such "adaptivity" around types changing? In C and C++, it is common to runtime link where the types on either side are different, but where there is some little amount of ability to discover some aspects of the types and adapt. As stated, via a size at the start of a record and/or bitfields to indicate which fields are present. Of course, it is limited. You only ever "grow" types. You never delete or rearrange.<BR> <BR>At the very least, you need to be able to bootstrap from one version to the next.<BR>A new compiler has to work at least once against an old statically linked runtime.<BR> <BR>At the very most, new compilers have to output binaries that work with old dynamically linked runtimes. I doubt this works much really but I am curious as to everyone else's opionions and assertions.<BR> <BR>Rather than set them to nil, what about typecasing them and then replacing with a non-nil instance that ignores writes? That will save you unhandled exceptions, right?<BR> <BR>Eventually I could/would probably just sit down and solve this but I haven't had much time and have been working on other Modula-3 things -- bringing up existing/new platforms (I uploaded SOLsun archives recently, still trying to bring up gcc on Solaris (not even SOLgnu, just gcc), and lots more on the radar..), debugging the 64 bit hosted cm3cg bug(s), etc.<BR> <BR>The quake code you propose sounds trivial, yes.<BR>But lately I think more should be in cm3 and less in quake (or sh or Python).<BR>Very gradually I am folding my Python into quake and my quake into cm3.<BR> Esp. as it proves stable and useful.<BR>For example, cm3 now reveals its own platform to Quake (HOST_PLATFORM), so Quake can default to a native build, without the user telling it or it sniffing around. All the use of uname et. al. can probably go away. (see also gcc's various -print-foo switches, that let wrappers introspect about gcc already knows about the target; cm3 could perhaps use similar)<BR> <BR>My Python wrappers accept a target platform name anywhere on the command line. cm3 should probably just do that. My Quake sniffs around for a config file based on platform, next to itself or in the source tree. Cm3 should probably just do that, esp. next to itself, less clear about in the source tree. It is kind of reasonable to go around implementing things multiple times, as the initial implementations serve as prototypes to try on for size, see if they work out well. The whole mechanism where "packages" are discovered by groveling the source tree could/should probably be merged into cm3, perhaps driven by a hand authored file or files, either like Randy did for Win32, or a more hierarchical tree full of small files linking together directories, like the Windows DDK "dirs" files.<BR> <BR> - Jay<BR><BR>
<HR>
Date: Sat, 21 Jun 2008 11:41:09 -0400<BR>From: rcoleburn@scires.com<BR>To: m3devel@elegosoft.com<BR>Subject: Re: [M3devel] proposal for dealing with lazy console--please review and comment!<BR><BR><BR>
<BLOCKQUOTE>
<DIV>Thanks Rodney and Jay for your comments.</DIV>
<DIV> </DIV>
<DIV>Here are a few points I'd like to add to this discussion.</DIV>
<DIV> </DIV>
<DIV>1. I agree with Jay that command line arguments would be better than environment variables.</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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?</DIV>
<DIV> </DIV>
<DIV>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?</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Randy<BR><BR>>>> "rodney.bates" <rodney.bates@wichita.edu> 6/21/2008 10:18 AM >>><BR>I guess I am on a somewhat different wavelength on this. I do<BR>agree that a complete set of queries by the application should<BR>be supported, concerning lazy allocated streams. But to me,<BR>applications need to have either very little or nothing in the<BR>way of ability to change behaviour.<BR><BR>For one thing, it makes sense for the lazy property to apply<BR>only to stdout/stderr, on win32 platforms, compiled as -gui.<BR>This is why I was questioning getting a stream from FileWr.Open,<BR>and then setting it lazy. Laziness doesn't make any sense on<BR>a disk file.<BR><BR>Beyond that, I think at the most, an application should be able <BR>to change the laziness property only before any data has been<BR>written to the stream. After that, the window is already popped,<BR>and the semantics would get ugly.<BR><BR>In fact, I am very skeptical about the need for an application <BR>to change laziness at all. If it can query this property, then<BR>it can just refrain from writing to the steam, if it doesn't want<BR>the window to pop up.<BR><BR>Hence my objection to making the properties variables, not because<BR>of general principal, but because an application could assign to<BR>them at any time.<BR><BR>>===== Original Message From Jay <jayk123@hotmail.com> =====<BR>>set CM3_ConsoleBehavior=4.1<BR>>m3guiapp<BR>>console behavior still changed<BR>><BR>>m3guiapp @M3ConsoleBehavior=4.1<BR>>console behavior back to "default"<BR>> - Jay><BR><BR>Rodney Bates<BR>Retired assistant professor<BR>Computer Science<BR><BR><BR></DIV></BLOCKQUOTE></BLOCKQUOTE></body>
</html>