<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1250"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">I think some interim release, of “get on with Modula-3 fast” kind, is better idea than to slow progress. And I don’t dislike this current state.<div><br></div><div>As for sommunity shrinking… Maybe some web facelift would be good idea… Anybody willing?</div><div><br></div><div>dd<br>
<br><div><div>On 23 Nov 2013, at 21:33, Rodney M. Bates <<a href="mailto:rodney_bates@lcwb.coop">rodney_bates@lcwb.coop</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 18px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br><br>On 11/23/2013 05:13 AM, Jay K wrote:<br><blockquote type="cite">This is deliberate, and slightly useful, and the warnings shouldn't occur in the head,<br>for several years now. Please upgrade more frequently.<br><br><br></blockquote><br>I feel very strongly that the latest release compiler should always build the head.<br>We have all too few Modula-3 users anyway.  If we don''t have this ability,<br>then we become an exclusive club with unreasonable barriers to outsiders.<br>There is hardly a better way to keep the community shrinking.<br><br>I know it can be a pain to maintain compatibility, but we really must do it.<br>Until we get a new release with a compiler that won't choke on WINAPI, we<br>need to keep different versions of the source.<br><br>Actually, I thought I had removed all occurrences of this problem a few<br>months ago.  How did I miss this one?<br><br><br><blockquote type="cite">In particular:<br><br><br> - It is useful because "much" of the interfaces are describing types,<br>   and types aren't just for function parameters, for functions that<br>   aren't available, but they are used as part of files, and you can,<br>   hypothetically, use them in your own functions (heck, you can<br>   write a Win32-on-Posix compatibility layer and provide the functions..).<br><br><br>   In particular, mklib uses these types and is fairly portable.<br>   It might have endian/alignment problems though, esp. endian.<br><br><br>   I do have a plan to get rid of mklib though...i was slow to realize it<br>   because mklib exports too much and I wanted a replacement wthout that flaw,<br>   but just matching it is adequate. The frontend/backends shall output<br>   the .def files instead of mklib. And then the usual lib/ar/link can/should<br>  make the libraries. If anyone wants to use LTCG  on NT with the C backend,<br>  this is the way (or put everything in one source file via the backend, not a bad idea)..<br><br><br>  - In the past 20 years or so, there is only one widely used<br>   platform that made the mistake of having multiple calling conventions<br>   and that is NT/x86. Not NT in general, but NT/x86 specifically.<br>   I expect nobody will make this mistake again.<br>   I'm not sure MIPSo32/MIPSn32 or ARM-mess count as the same mistake.<br>   On NT/x86, the calling convention does not bifurcate the entire target<br>   and force building everything multiple times, because you can sprinkle it around and<br>   each "type" can call each "type". This is good and bad.<br>   The other OS/processor combinations with multiple calling conventions<br>   define it as multiple ABIs with I believe no offical interop (except at the<br>   kernel level, for some of them).<br><br><br>   Therefore, callling conventions can be safely ignored on all platforms except NT/x86.<br>   Nobody will have any names to use here, overlapping the NT/x86 names or not.<br>   If the day comes where I am wrong and some target has multiple conventions,<br>  we should change the pragma to accept multiple. If the names overlap with NT/x86,<br>  we would put platform qualifiers on them. Never again should we have the Win32 SQL.i3<br>  and Posix SQL.i3 that are the same, except for calling convention. What a waste -- almost<br>  the same, but for one little difference that could be handled another way, they go duplicated.<br> That pattern bugs me.<br><br><br>  - Jay<br><br><br><br><br>----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------<br></blockquote>--<br><blockquote type="cite">From:<span class="Apple-converted-space"> </span><a href="mailto:dragisha@m3w.org">dragisha@m3w.org</a><br>Date: Fri, 22 Nov 2013 23:55:23 +0100<br>To:<span class="Apple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Subject: Re: [M3devel] missed the memo? LINUXLIBC6 building WinBase?<br><br>Yes, it was in a memo. Sorry for disruption :).<br><br>On 22 Nov 2013, at 23:31, Dragiša Durić <<a href="mailto:dragisha@m3w.org">dragisha@m3w.org</a><span class="Apple-converted-space"> </span><<a href="mailto:dragisha@m3w.org">mailto:dragisha@m3w.org</a>>> wrote:<br><br>   + ./scripts/do-pkg.sh buildship m3core libm3 tcp<br>   /root/rpmbuild/BUILD/cm3/scripts/pkgmap.sh -c cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3'   && cm3 -ship  -DROOT='/root/rpmbuild/BUILD/cm3'  m3core libm3 tc<br>   === package m3-libs/m3core ===<br>     +++ cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' $RARGS  && cm3 -ship $RARGS -DROOT='/root/rpmbuild/BUILD/cm3'  +++<br>   --- building in LINUXLIBC6 ---<br><br>   ignoring ../src/m3overrides<br><br>   new source -> compiling WinBase.i3<br>   "../src/win32/WinDef.i3", line 131: warning: unrecognized pragma (ignored) (WINAPI)<br>   "../src/win32/WinDef.i3", line 132: warning: unrecognized pragma (ignored) (WINAPI)<br>   "../src/win32/WinDef.i3", line 133: warning: unrecognized pragma (ignored) (WINAPI)<br>   "../src/win32/WinBase.i3", line 198: warning: unrecognized pragma (ignored) (WINAPI)<br>   "../src/win32/WinBase.i3", line 918: unsupported language or calling convention (WINAPI)<br>   "../src/win32/WinBase.i3", line 921: unsupported language or calling convention (WINAPI)<br>   "../src/win32/WinBase.i3", line 924: unsupported language or calling convention (WINAPI)<br>   "../src/win32/WinBase.i3", line 927: unsupported language or calling convention (WINAPI)<br>   "../src/win32/WinBase.i3", line 930: unsupported language or calling convention (WINAPI)<br>   "../src/win32/WinBase.i3", line 933: unsupported language or calling convention (WINAPI)<br>   "../src/win32/WinBase.i3", line 943: unsupported language or calling convention (WINAPI)<br>   "../src/win32/WinBase.i3", line 949: unsupported language or calling convention (WINAPI)<br>   "../src/win32/WinBase.i3", line 952: unsupported language or calling convention (WINAPI)<br>   "../src/win32/WinBase.i3", line 955: unsupported language or calling convention (WINAPI)<br><br>   --<br>   Dragiša Durić<br>   <a href="mailto:dragisha@m3w.org">dragisha@m3w.org</a><span class="Apple-converted-space"> </span><<a href="mailto:dragisha@m3w.org">mailto:dragisha@m3w.org</a>></blockquote></div></blockquote></div><br></div></body></html>