<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>I still really like this idea, but this turned out to be something else..<BR>
<BR>
- Jay<BR><BR>
<HR id=EC_stopSpelling>
From: jayk123@hotmail.com<BR>To: wagner@elegosoft.com; m3devel@elegosoft.com<BR>Date: Wed, 30 Apr 2008 00:19:51 +0000<BR>Subject: [M3devel] silenly allowing "WINAPI" on all targets? (wrt Popup Windows stalling regression tests on WinXP)<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>
I think cm3 can just make this call unconditionally.<BR> As long as the crash is bubbled up as a failure that is printed or something.<BR> There should also be a public interface for collecting and sending the reports without a prompt.<BR> Various command line tools (cl, link) now have switches to control this behavior.<BR>I know the crash is not in cm3 but what it runs -- the setting is inherited by child processes.<BR> <BR>So, I have a function that exists and I want to call on Win32, and doesn't exist anywhere else, in which case I want to do nothing.<BR> <BR>In my opinion, a good way to do this is:<BR> <BR>something.i3<BR> <* extern WINAPI *> PROCEDURE SetErrorMode(UINT32);<BR> <BR>I wouldn't mind a way to write this in Modula-3, but the naming is in the way.<BR>common/something.c<BR> void SetErrorMode(UINT32 a) { /* do nothing */ }<BR> <BR>and only compile something.c on non-Win32.<BR> <BR>This raises some issues, that I have raised before.<BR> <BR>I think WINAPI should be silently ignored for all but NT386.<BR>It's a small change. It lets this kind of thing work.<BR> <BR>I know there are other ideas, like <* extern NT386:WINAPI LINUXLIBC:FOOAPI *><BR>or <* extern SYSAPI *><BR> <BR>but really I think what I propose is sufficient (and simplest).<BR>I doubt that a generalization or renaming has any point.<BR>In fact I'd argue for removing all the synonyms and supporting just __stdcall, __cdecl, __fastcall, and __thiscall, possibly as STDCALL, CDECL, FASTCALL, THISCALL, since Modula-3 doesn't like identifiers to start with underscore, and the last two are optional.<BR> <BR>As I said/implied before, having multiple calling conventions on one target is a terrible idea and I don't expect it to occur again, not at this level at least. I know, for example, you could describe the Linux kernel as exposing two calling conventions, depending on if there is a "small" or "large" number of parameters, but really, even neither of these two are the "normal" convention and such things always get wrapped up in a little wrapper with the "standard" calling convention of the platform (except on NT386, sort of, where the wrapper is one of a few conventions).<BR> <BR>Precedent is that calling conventions are allowed in source for other Windows platforms, but are ignored.<BR>They might be #defined away sometimes, but I bet the compiler ignores them.<BR>This provides better source compatibility.<BR>As x86 <EM>gradually </EM>goes away, people will stop putting these things in.<BR> <BR>I guess the alternative to my proposal is an extra level of wrapping behind some made up "portable" interface:<BR> <BR>something.i3:<BR> PROCEDURE SetErrorMode(UINT32);<BR> <BR>win32/something.m3<BR> PROCEDURE SetErrorMode(UINT32 a) = BEGIN WinBase.<FONT face="">SetErrorMode</FONT>(a); END SetErrorMode;<BR> <BR>posix/something.m3<BR> PROCEDURE SetErrorMode(UINT32 <* unused *> a) = BEGIN (* do nothing *); END SetErrorMode;<BR> <BR>The alternative does have more flexibility, obviously, if the Posix implementation is anything other than "do nothing", such as even having to return a value, which might be the case here, then it'd go this way. Also this saves there from being a .c file.<BR> <BR>Is that sleazy to use the same function name in two modules? I know Modula-3 prepends module names always. It seems like a feature more than a bug.<BR> <BR>Anyway, as before, a gain here would be to reduce the doubled up odbc and maybe opengl .i3 files, which vary only in calling convention.<BR> <BR> - Jay<BR><BR><BR>
<BLOCKQUOTE>
<BLOCKQUOTE>
<HR id=EC_EC_stopSpelling>
From: jayk123@hotmail.com<BR>To: wagner@elegosoft.com; m3devel@elegosoft.com<BR>Subject: RE: [M3devel] Popup Windows stalling regression tests on WinXP<BR>Date: Tue, 29 Apr 2008 22:01:51 +0000<BR><BR>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Tahoma;}
</STYLE>
ps: Olaf, the debugger install is incredibly fast and small.<BR>This isn't Visual Studio.<BR>I get, but hadn't previously considered, that future regressions would hang the machine, so a fix is only "temporary", but hey...maybe a process needs to monitor the tests and kill them if they take too long?<BR> <BR>SetErrorMode will probably fix this, now that I think more.<BR>We can add a switch to cm3 and it can call that on itself, and it always gets inherited by child processes. Or we can have a trivial wrapper .exe to run the tests, if the switch to cm3 is not liked. But I have to test it out.<BR>Suggest an .exe or switch name? :)<BR>If indeed it is SetErrorMode, I'd do<BR>seterrormode.exe <number> <command line to run...><BR>Though this is a low level name.<BR>It could be testwrapper.exe or quashpopups.exe.<BR> -Jay<BR><BR><BR><BR><BR><BR> <BR>
<BLOCKQUOTE>
<HR>
From: jayk123@hotmail.com<BR>To: wagner@elegosoft.com; m3devel@elegosoft.com<BR>Date: Tue, 29 Apr 2008 21:38:14 +0000<BR>Subject: Re: [M3devel] Popup Windows stalling regression tests on WinXP<BR><BR>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Tahoma;}
</STYLE>
Yes, this might be it.<BR>My x86 Windows machine is out on loan this week, my AMD64 Windows machine needed a reinstall, and I was deep into debugging the AMD64_LINUX problem (on same machine, multi-boot), so I punted. Now I've reinstalled AMD64 Windows and can debug to see what the problem is, to decide if it is quashable..<BR>There should be a way without global changes to the machine, but if that's ok, ok. (If this even it.)<BR> <BR> - Jay<BR><BR><BR><BR>> Date: Tue, 29 Apr 2008 17:11:17 +0200<BR>> From: wagner@elegosoft.com<BR>> To: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] Popup Windows stalling regression tests on WinXP<BR>> <BR>> Quoting "Daniel Alejandro Benavides D." <dabenavidesd@yahoo.es>:<BR>> <BR>> > Hi all:<BR>> > Olaf, I don't have the Win box here (just a Kubuntu one). But even <BR>> > if you don't want to send the file, one can see the report file in <BR>> > a window. Should be with two steps: The first click on the blue <BR>> > label "Click here " in the first pop up window. That throws another <BR>> > window with a label that you can click-on and actually see it<BR>> > Well I found with google the instruction to disable that error pop up:<BR>> > http://pcsupport.about.com/od/windowsxp/ht/disableerror.htm<BR>> > I hope this helps to you.<BR>> <BR>> Thanks, that sounds good, I'll try it tonight.<BR>> <BR>> Olaf<BR>> <BR>> ><BR>> > Thanks<BR>> ><BR>> > Olaf Wagner <wagner@elegosoft.com> escribió: Quoting "Daniel <BR>> > Alejandro Benavides D." :<BR>> ><BR>> >> Hi all:<BR>> >> Olaf, but in the case is not even the cm3 process, but a sub process<BR>> >> of it, maybe the linker or/and the assembler (what VS version do<BR>> >> you have?) which in turn throws the fault, how do you know from<BR>> >> sure is cm3 only causing that?, Can you check the label of "Click<BR>> >> here for more information". Then you can click on see the files<BR>> >> involved in the fault. There you should see the list of files like<BR>> >> dll or lib and executable involved, can you send that info?<BR>> ><BR>> > I'll restart the tests after some more obvious fixes later this<BR>> > evening and may be able to send more information tomorrow.<BR>> > IIRC there was no label `click here for more information', but<BR>> > just `send report to Microsoft' and `do not send'.<BR>> ><BR>> > Currently we're working hard on a completely different release...<BR>> ><BR>> > Olaf<BR>> > --<BR>> > Olaf Wagner -- elego Software Solutions GmbH<BR>> > Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<BR>> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<BR>> > http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<BR>> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR>> ><BR>> ><BR>> ><BR>> ><BR>> > ---------------------------------<BR>> ><BR>> > Enviado desde Correo Yahoo!<BR>> > La bandeja de entrada más inteligente.<BR>> ><BR>> <BR>> <BR>> <BR>> -- <BR>> Olaf Wagner -- elego Software Solutions GmbH<BR>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<BR>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<BR>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<BR>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR>> <BR><BR></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></body>
</html>