[M3devel] silenly allowing "WINAPI" on all targets? (wrt Popup Windows stalling regression tests

Wed Apr 30 14:40:17 CEST 2008

I still really like this idea, but this turned out to be something else..

 - Jay

From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Wed, 30 Apr 2008 00:19:51 +0000Subject: [M3devel] silenly allowing "WINAPI" on all targets? (wrt Popup Windows stalling regression tests on WinXP)

I think cm3 can just make this call unconditionally.  As long as the crash is bubbled up as a failure that is printed or something.  There should also be a public interface for collecting and sending the reports without a prompt.  Various command line tools (cl, link) now have switches to control this behavior.I know the crash is not in cm3 but what it runs -- the setting is inherited by child processes. 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. In my opinion, a good way to do this is: something.i3  <* extern WINAPI *> PROCEDURE SetErrorMode(UINT32); I wouldn't mind a way to write this in Modula-3, but the naming is in the way.common/something.c   void SetErrorMode(UINT32 a) { /* do nothing */ } and only compile something.c on non-Win32. This raises some issues, that I have raised before. I think WINAPI should be silently ignored for all but NT386.It's a small change. It lets this kind of thing work. I know there are other ideas, like <* extern NT386:WINAPI LINUXLIBC:FOOAPI *>or <* extern SYSAPI *> but really I think what I propose is sufficient (and simplest).I doubt that a generalization or renaming has any point.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. 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). Precedent is that calling conventions are allowed in source for other Windows platforms, but are ignored.They might be #defined away sometimes, but I bet the compiler ignores them.This provides better source compatibility.As x86 gradually goes away, people will stop putting these things in. I guess the alternative to my proposal is an extra level of wrapping behind some made up "portable" interface: something.i3:   PROCEDURE SetErrorMode(UINT32); win32/something.m3   PROCEDURE SetErrorMode(UINT32 a) = BEGIN WinBase.SetErrorMode(a); END SetErrorMode; posix/something.m3   PROCEDURE SetErrorMode(UINT32 <* unused *> a) = BEGIN (* do nothing *); END SetErrorMode; 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. 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. 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.  - Jay

From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comSubject: RE: [M3devel] Popup Windows stalling regression tests on WinXPDate: Tue, 29 Apr 2008 22:01:51 +0000

ps: Olaf, the debugger install is incredibly fast and small.This isn't Visual Studio.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? SetErrorMode will probably fix this, now that I think more.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.Suggest an .exe or switch name? :)If indeed it is SetErrorMode, I'd doseterrormode.exe <number> <command line to run...>Though this is a low level name.It could be testwrapper.exe or quashpopups.exe. -Jay 

From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Tue, 29 Apr 2008 21:38:14 +0000Subject: Re: [M3devel] Popup Windows stalling regression tests on WinXP

Yes, this might be it.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..There should be a way without global changes to the machine, but if that's ok, ok. (If this even it.)  - Jay> Date: Tue, 29 Apr 2008 17:11:17 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] Popup Windows stalling regression tests on WinXP> > Quoting "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>:> > > Hi all:> > Olaf, I don't have the Win box here (just a Kubuntu one). But even > > if you don't want to send the file, one can see the report file in > > a window. Should be with two steps: The first click on the blue > > label "Click here " in the first pop up window. That throws another > > window with a label that you can click-on and actually see it> > Well I found with google the instruction to disable that error pop up:> > http://pcsupport.about.com/od/windowsxp/ht/disableerror.htm> > I hope this helps to you.> > Thanks, that sounds good, I'll try it tonight.> > Olaf> > >> > Thanks> >> > Olaf Wagner <wagner at elegosoft.com> escribió: Quoting "Daniel > > Alejandro Benavides D." :> >> >> Hi all:> >> Olaf, but in the case is not even the cm3 process, but a sub process> >> of it, maybe the linker or/and the assembler (what VS version do> >> you have?) which in turn throws the fault, how do you know from> >> sure is cm3 only causing that?, Can you check the label of "Click> >> here for more information". Then you can click on see the files> >> involved in the fault. There you should see the list of files like> >> dll or lib and executable involved, can you send that info?> >> > I'll restart the tests after some more obvious fixes later this> > evening and may be able to send more information tomorrow.> > IIRC there was no label `click here for more information', but> > just `send report to Microsoft' and `do not send'.> >> > Currently we're working hard on a completely different release...> >> > Olaf> > --> > Olaf Wagner -- elego Software Solutions GmbH> > Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> > http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> >> >> >> >> > ---------------------------------> >> > Enviado desde Correo Yahoo!> > La bandeja de entrada más inteligente.> >> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080430/b4085596/attachment-0002.html>