From jkrell at elego.de Thu Jan 1 01:02:45 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jan 2009 1:02:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090101000246.4E23210D5F06@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/01 01:02:45 Modified files: cm3/m3-libs/m3core/src/: Uwaitpid.quake m3makefile cm3/m3-libs/m3core/src/thread/: m3makefile cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile Added files: cm3/m3-libs/m3core/src/: thread.quake Log message: Remove the Sleep from [Process]Wait in sysutils, as it was removed from libm3, at least for non-user threads platforms. This should accomplish some speedup, but not measured. NOTE: historically m3core is built for userthreads or kernelthreads; now sysutils is too. Ideally such "switches" are contained within one .dll and then exported to others that adapt. In this case, both .dlls contain the constant. The roundabout structuring here, as well as the previous non-ideal situation, is in the interest of letting sysutils work against old m3core, while still getting this fix. Another approach to consider, if it can be easily reliably achieved, is to only do the "copying" when building against an old m3core, and go ahead and use the usual share-by-call mechanisms when building against newer m3core. Another approach is..what is this import_pkg quake feature? It seems to allow sharing-by-automated-copy instead of sharing-by-call, like static linking vs. dynamic linking. There does seem to be a bunch of redundancy in sysutils compared to m3core or libm3..but the compiler works with older m3core/libm3 whereas there sort of is no such thing as an 'old' sysutils, since it was introduced relatively recently. Really just need to bump forward the bootstrap start?? From jkrell at elego.de Thu Jan 1 01:55:29 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jan 2009 1:55:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090101005529.A85E510D5F02@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/01 01:55:29 Modified files: cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 Log message: share some common code From jkrell at elego.de Thu Jan 1 08:51:02 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jan 2009 8:51:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090101075102.B8A9710D4524@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/01 08:51:02 Added files: cm3/scripts/: lzma.sh Log message: make-dist helper -- for any *.tar.gz in current directory, produce equiv .tar.lzma; my current thinking is to always release both, folks that have lzma can spare the download bandwidth, of course one of the downsides is that people might be confused or lazy and download both From jkrell at elego.de Thu Jan 1 09:31:37 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jan 2009 9:31:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090101083138.9FE3B10D5E61@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/01 09:31:37 Modified files: cm3/m3-libs/m3core/src/unix/Common/: m3unix.h Log message: fix newlines From jkrell at elego.de Thu Jan 1 09:43:06 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jan 2009 9:43:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090101084306.57E8110D4524@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/01 09:43:06 Modified files: cm3/m3-libs/m3core/src/unix/Common/: m3unix.h UdirC.c Log message: having done some research on the myriad macros guiding 64 vs. 32 bit file offsets/sizes, this should suffice From jkrell at elego.de Thu Jan 1 09:44:50 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jan 2009 9:44:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090101084450.653A110D4524@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/01 09:44:50 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UstatC.c Log message: fix one newline From jkrell at elego.de Fri Jan 2 01:21:20 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 1:21:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102002120.D5FF610D5D5D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 01:21:20 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c cm3/m3-libs/m3core/src/unix/cygwin/: Unix.i3 Usignal.i3 Usocket.i3 Ustat.i3 Utime.i3 Utypes.i3 Uutsname.i3 m3makefile Added files: cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 Removed files: cm3/m3-libs/m3core/src/unix/cygwin/: Utime.m3 Log message: tighten up UtimeC.c a little, perhaps unnecessarily in particular, function that takes [0..1] assert its parameter, and in the unlikely case that doesn't suffice (compile with -DNDEBUG?), truncate it as well. If the extern function is declared as taking [0..1], presumably the range checks are on the caller side and not the callee side??? That is more bloated, but seems better, maybe. Remove some unused prototypes. Dubious to put them here. Might have quashed compiler warnings(as errors) in some contexts, will put them back as needed, probably in m3unix.h. The code is definitely standard-correct, but might not pass all command lines, like gcc -Wmissing-prototypes or such. (Er, at least Metrowerks was the worst here, making you prototype functions that were implemented prior to use, or not even used.., gcc hopefully only complains about used stuff..?) First round of moving Unix constants and types into new Usysdep.i3, and then exporting those from files that contain some portable content. plan: do this one platform at a time (cygwin, linux, openbsd) do each platform twice it is very tedious, copy/paste intensive, error-prone first round not commited, just saved away and then compared to second round once each platform done, go back and extract the common parts the intention is that every file but Usysdep.i3 is identical, but this is best verified and acted upon only once they are all three there and seeming to work Here just Cygwin. This should significantly reduce the system dependent content, even though it may lead to more lines over all, since sysdep content must be declared AND forwarded. Note that this discovered duplicate declarations of timezone or such, one in Utime.i3, the other in Utypes.i3. Investigate this more later. As well, Usysdep probably contains some portable content, to be whittled down later. As well, the resulting portable files -- Unix.i3 and such -- are likely to be in varying order after the first round, and Cygwin's suffers (arguably) from a lack of comments and unreadable order (flags/types/functions not near relatives). At some point this was to reduce the size of the cloned headers, but once their duplication is reduced, the trade off starts shifting. Merge Utime.m3 into UtimeC.c. Perhaps not ideal. Cygwin is the only Posix platform that needs this C wrapper. Perhaps the calling Modula-3 should be modified to either ignore errors, or ignore errors on Cygwin (you can do runtime checks of what platform you are on, after all, some code does). From jkrell at elego.de Fri Jan 2 02:58:52 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 2:58:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102015852.5F47F10D5D5E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 02:58:52 Modified files: cm3/m3-libs/m3core/src/Csupport/: m3makefile cm3/m3-libs/m3core/src/Csupport/libgcc/: libgcc.c Log message: Account for NT386 and NT386GNU clashing over /cm3/lib/hand.obj, which should probably be moved. As well, this will be needed for any 32bit system that doesn't use gcc as the compiler/linker (AIX, HP-UX, IRIX, etc.). It is already needed/used by SOLsun. From jkrell at elego.de Fri Jan 2 06:00:55 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 6:00:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102050055.4096D10D5EDB@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 06:00:55 Modified files: cm3/m3-ui/zeus/src/: m3zume.tmpl Log message: % % Allow native I386_NT (NT386) cm3 to run I386_CYGWIN (NT386GNU) m3zume. % This is a fairly real scenario in my workflow that I was ignoring. % I386_CYGWIN does not like commands like: % m3zume ..\foo\bar => invalid extension, it probably % thinks \foo\bar is the extension. % This is a more general problem, not fully solved here. % For this to be OK on native Win32 depends on that / are now accepted on Win32. % (Which I question from time to time, if it was a good idea.) % % % A problem is that on "biarch" systems, such as NT386 + NT386GNU, or % LINUXLIBC6 + AMD64_LINUX, /cm3/bin/cm3 can bounce back and forth between the two, % leading to the two worlds to come together somewhat, and perhaps interop. % % Probably there should be /cm3/bin/target/cm3, and a "portable" /cm3/bin/cm3 that % figures out which one to call. On Posix it would be an extensionless sh % that ends with "exec". It could sniff host platform with uname, like sysinfo.sh does, % though sysinfo.sh would also compute it, allowing skipping running the sniffing repeatedly. % On NT it would be nice if it could be .cmd, but more likely an NT386 binary. % On uniarch systems, just link the two. % % This way the systems don't have to interop, nor would the general problem of differing % slashes have to be dealt with. Though, it is a dilemna beyond Modula-3 as to interop % of Cygwin binaries with Win32 binaries. % From jkrell at elego.de Fri Jan 2 08:28:23 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 8:28:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102072823.705C810D5EDD@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 08:28:23 Removed files: cm3/m3-libs/m3core/src/unix/solaris-2-x/: Udir.m3 Log message: remove unused file From jkrell at elego.de Fri Jan 2 09:06:26 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 9:06:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102080626.93D0210D5F04@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 09:06:26 Modified files: cm3/m3-libs/m3core/src/time/POSIX/: m3makefile Log message: add missing SPARC64_OPENBSD; and put all the OPENBSD platforms next to each other From jkrell at elego.de Fri Jan 2 09:10:50 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 9:10:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102081050.BE50210D5EDC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 09:10:50 Modified files: cm3/m3-libs/m3core/src/unix/openbsd-common/: Udir.i3 Unix.i3 Upthread.i3 Usignal.i3 Usocket.i3 Utime.i3 Utypes.i3 Uucontext.i3 Uutsname.i3 m3makefile Added files: cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 Log message: refactor system dependent lines (ie: types and constants) into Usysdep, with the intent that all the other files will be identical across all targets and move into the Common directory (and even still, then and Usysdep might be further reduced, and Usysdep.i3 generated automatically) Note that Uerror.i3 is left alone (as it was for Cygwin, but forgot to mention that); it has a /very/ high density of sysdep lines, like essentially every line; unless we wrap the constants up in accessor functions written in C, then it becomes completely portable. (Other files like Uucontext are also highly sysdep, and might become more so when make/set/get/swapcontext supported added; we'll see; also, most of the stat values are sysdep, except a few that Cygwin uses zero for; again, this is just a step, more before and after.) From jkrell at elego.de Fri Jan 2 21:08:56 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 21:08:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102200856.3960610D5CFC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 21:08:56 Modified files: cm3/m3-libs/libm3/src/os/WIN32/: OSConfigWin32.m3 cm3/m3-libs/libm3/src/os/POSIX/: OSConfigPosix.m3 Log message: eliminate race condition that could occur if the code is highly optimized -- don't depend on write ordering From jkrell at elego.de Fri Jan 2 21:22:55 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 21:22:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102202255.9177E10D5D00@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 21:22:55 Modified files: cm3/m3-libs/libm3/src/os/WIN32/: OSConfigWin32.m3 Log message: add in some missing architectures, though arguably this should be either GetEnv(PROCESSOR_ARCHITECTURE) (does it work on CE?) or a constant determined at build time; the historical code goes obsolete automatically and quietly From jkrell at elego.de Fri Jan 2 21:36:45 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 21:36:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102203645.6902110D5D00@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 21:36:45 Modified files: cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 m3makefile cm3/m3-libs/libm3/src/os/POSIX/: OSConfigPosix.m3 m3makefile cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 m3makefile Added files: cm3/m3-libs/libm3/src/os/POSIX/: OSConfigPosixC.c OSConfigPosixC.i3 Removed files: cm3/m3-libs/m3core/src/unix/cygwin/: Uutsname.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Uutsname.i3 Log message: eliminate lone Uutsname.i3 usage and then system-dependent Uutsname.i3 itself, via portable C wrapper The vast bulk of OSConfig appears dead within cm3 anyway. All I see is OSConfig.LineSep (for writing only; readers should accept any of the three usages) and OSConfig.UserName(). So maybe we should just aggressively prune it down? Could be users outside the tree, granted. From jkrell at elego.de Fri Jan 2 21:49:31 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 21:49:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102204931.4718610D461B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 21:49:31 Modified files: cm3/m3-libs/m3core/src/unix/linux-common/: m3makefile Removed files: cm3/m3-libs/m3core/src/unix/linux-common/: Uutsname.i3 Log message: delete this one too From jkrell at elego.de Fri Jan 2 23:04:54 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 23:04:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102220454.B9EF910D5481@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 23:04:54 Modified files: cm3/m3-libs/m3core/src/unix/Common/: m3makefile Log message: fix newlines From jkrell at elego.de Fri Jan 2 23:07:05 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 23:07:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102220705.3EA0810D5481@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 23:07:05 Modified files: cm3/m3-libs/m3core/src/unix/linux-common/: Unix.i3 Upthread.i3 Usignal.i3 Usocket.i3 Utime.i3 Utypes.i3 m3makefile Log message: refactor linux-common using Usysdep a little more needed for Usignal and Usocket due to linux-sparc variant (should be ok, just hasn't achieved as much commonality as in the openbsd-common change) From jkrell at elego.de Fri Jan 2 23:38:40 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 23:38:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102223840.CB17110D542A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 23:38:40 Modified files: cm3/m3-libs/m3core/src/C/Common/: m3makefile Log message: fix newlines From jkrell at elego.de Fri Jan 2 23:40:45 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 23:40:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102224045.734F510D542A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 23:40:45 Added files: cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 Log message: forgot to add this From jkrell at elego.de Sat Jan 3 00:49:44 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 0:49:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102234944.CA23510D4D19@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 00:49:44 Modified files: cm3/m3-libs/m3core/src/unix/cygwin/: m3makefile Log message: forgot to delete Uutsname.i3 here From jkrell at elego.de Sat Jan 3 00:52:05 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 0:52:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102235205.995B110D4D19@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 00:52:05 Modified files: cm3/m3-libs/m3core/src/unix/openbsd-common/: Utypes.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Utypes.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Utypes.i3 Log message: make these three files identical From jkrell at elego.de Sat Jan 3 01:57:20 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 1:57:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103005721.001F410D54EF@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 01:57:20 Modified files: cm3/m3-libs/m3core/src/unix/hpux-7-0/: Utime.i3 cm3/m3-libs/m3core/src/unix/irix-5.2/: Utime.i3 cm3/m3-libs/m3core/src/unix/linux/: Utime.i3 Log message: go ahead and break these three old dormant platforms rather than determine interfaces regarding timezones, alt timezones, daylight savings, etc.; will probably actually repair Irix and HPUX in the next few months (! I have Irix running at home and HP-UX maybe soon) but Linux 1.x a.out not likely; this is part of other Utime-related cleanup. From jkrell at elego.de Sat Jan 3 01:59:30 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 1:59:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103005930.4A0F010D569E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 01:59:30 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c cm3/m3-libs/m3core/src/unix/cygwin/: Utime.i3 cm3/m3-libs/m3core/src/unix/linux-libc6/: Utime.i3 cm3/m3-libs/m3core/src/unix/solaris-2-x/: Utime.i3 Log message: 1: put "m3_" in front of the functions we implement outselves, for clarity, and in case there are "real" functions with these names 2: add comments indicating what should perhaps be re-investigated no "real" change From jkrell at elego.de Sat Jan 3 02:51:36 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 2:51:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103015136.1C9BC10D458D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 02:51:36 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c cm3/m3-libs/m3core/src/unix/cygwin/: Utime.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Utime.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Utime.i3 Log message: make these three files identical too From jkrell at elego.de Sat Jan 3 06:22:25 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 6:22:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103052225.413CA170400C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 06:22:25 Modified files: cm3/m3-sys/cm3/src/: M3Build.m3 Log message: (* Host and Target paths sometimes get confused, leading to many warnings such as: package "libm3" is already overridden to C:\dev2\cm3.2/m3-libs, ignoring new override to C:/dev2/cm3.2/m3-libs PathEqual is defined as Text.Equal or Text.Equal(replacing backward slashes with forward slashes). It would also be reasonable to be case insensitive if the path contains any backward slashes, or if they both contain colon as the second character. *) From jkrell at elego.de Sat Jan 3 06:36:43 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 6:36:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103053644.E810410D4624@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 06:36:43 Modified files: cm3/m3-ui/juno-2/juno-app/src/: m3makefile Log message: Fix more substantial cross build scenarios. Previously fixed cross scenarios where host and target could run on the same machine (NT386/NT386GNU, LINUXLIBC6/AMD64_LINUX). This fixes 'normal' cross scenarios, where they can't. Why are we even using unshipped binaries here? How about just trust $PATH, knowing that binaries ship next to cm3, and that cm3 is probably in $PATH? (Granted, it need not be, and perhaps PklFonts doesn't ship?) Also, why are we cd'ing around? Why doesn't the the package whose output directory we are stomping in do this, or why don't we just stay in our own output directory? It seems like a generally bad idea what is going on here -- you know, imagine a multithreaded build..packages should keep to themselves. This does impact all builds but should be simply correct. From jkrell at elego.de Sat Jan 3 06:52:54 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 6:52:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103055254.A161A10D582F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 06:52:53 Modified files: cm3/m3-libs/m3core/src/unix/openbsd-common/: Usocket.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usocket.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Usocket.i3 Log message: three more identical files, they almost already were save for whitespace, and an int vs. size_t but in cygwin/recvfrom; and get size_t from Cstddef instead of Utypes From jkrell at elego.de Sat Jan 3 13:07:00 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 13:07:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103120700.D0D7F10D5E88@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 13:07:00 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile Log message: fix newlines From jkrell at elego.de Sat Jan 3 13:07:34 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 13:07:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103120734.31A5110D5E88@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 13:07:34 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile Log message: use Common on all platforms From jkrell at elego.de Sat Jan 3 14:14:18 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 14:14:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103131421.6B73D10D5E9E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 14:14:18 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: don't leak attributes used for setting thread stack size From jkrell at elego.de Sat Jan 3 14:54:38 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 14:54:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103135438.CB44A10D43B4@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 14:54:38 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: ProcessCygwin.m3 cm3/m3-libs/m3core/src/unix/Common/: m3makefile cm3/m3-libs/m3core/src/unix/cygwin/: Unix.i3 Usysdep.i3 Utypes.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Unix.i3 Upthread.i3 Usignal.i3 Usysdep.i3 Utypes.i3 m3makefile cm3/m3-libs/m3core/src/unix/linux-sparc/: Usignal.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Unix.i3 Upthread.i3 Usignal.i3 Usysdep.i3 Utypes.i3 Added files: cm3/m3-libs/m3core/src/unix/Common/: UnixC.c Log message: on going header cleanup/merge (in non-mainstream platforms) some lengths were incorrectly int instead of size_t flesh out cygwin's Usignal (not used, but need to be the same) add wrappers for anything dealing with off_t or opening files so that we can be sure to get 64bit off_t and O_LARGEFILE, even on 32bit platforms, and with common headers; otherwise we'd have to fiddle with the <*extern*> name on 32bit Linux and Solaris (Solaris not yet relevant here, but it will be) Darwin does very similar. start adding comments back; they won't be so annoyingly bloated when we only have one copy of them instead of per-platform add mode_t; we were using the wrong type there in a few places (int) remove bogus sigaction type, some editing error problem, it is a field not a type cleanup the NDELAY / NONBLOCK / M3_NONBLOCK stuff /somewhat/ still leaving stuff around for compat cleanup is that Usysdep only defines NDELAY, and then portable layer aliases all three as one Cygwin will hold back with its own Usignal.i3. In particular, pthreads platforms need more in Usignal than non-pthreads. Cygwin also won't have pthreads.i3 at all, unless/until we use it. From jkrell at elego.de Sat Jan 3 15:00:20 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 15:00:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103140025.DC62010D5E88@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 15:00:20 Modified files: cm3/m3-libs/m3core/src/unix/linux-common/: Unix.i3 Log message: missed a spot of semantically meaningless diff From jkrell at elego.de Sat Jan 3 15:01:05 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 15:01:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103140106.1947B10D5E88@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 15:01:05 Modified files: cm3/m3-libs/m3core/src/unix/cygwin/: Utypes.i3 Log message: fix newlines From jkrell at elego.de Sat Jan 3 16:15:38 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 16:15:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103151538.4BE6C10D458D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 16:15:38 Modified files: cm3/m3-libs/m3core/src/unix/Common/: m3makefile Added files: cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Usignal.i3 Usocket.i3 Utime.i3 Utypes.i3 Removed files: cm3/m3-libs/m3core/src/unix/cygwin/: Unix.i3 Usocket.i3 Utime.i3 Utypes.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Unix.i3 Upthread.i3 Usignal.i3 Usocket.i3 Utime.i3 Utypes.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Unix.i3 Upthread.i3 Usignal.i3 Usocket.i3 Utime.i3 Utypes.i3 Log message: move 2-way or 3-say identical files to Common From jkrell at elego.de Sat Jan 3 16:19:14 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 16:19:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103151915.BDB1C10D458D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 16:19:14 Modified files: cm3/m3-libs/m3core/src/unix/openbsd-common/: m3makefile cm3/m3-libs/m3core/src/unix/linux-common/: m3makefile cm3/m3-libs/m3core/src/unix/cygwin/: m3makefile Log message: move (partly) common files to common From jkrell at elego.de Sat Jan 3 16:25:24 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 16:25:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103152525.25FB610D458D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 16:25:24 Added files: cm3/m3-libs/m3core/src/unix/Common/: Upthread.i3 Log message: forgot to add this From jkrell at elego.de Sat Jan 3 17:03:31 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 17:03:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103160332.0C5AC10D5AF4@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 17:03:31 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: fix the fallback; this never affects me because the probing finds my unshipped codegenerators From jkrell at elego.de Sat Jan 3 17:03:53 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 17:03:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103160354.0332A10D5AF4@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 17:03:53 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: fix the disabled debugprint too From jkrell at elego.de Sun Jan 4 01:43:42 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 1:43:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104004342.B1BD310D5E9A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 01:43:42 Modified files: cm3/m3-libs/m3core/src/unix/irix-5.2/: Unix.i3 Log message: tediously convert to base 8 for easier comparison to other platforms, though base 16 really is far more natural than base 8 except for permission bits.. From jkrell at elego.de Sun Jan 4 01:47:39 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 1:47:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104004739.711E3F04010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 01:47:39 Modified files: cm3/m3-libs/m3core/src/unix/irix-5.2/: Ustat.i3 Log message: ditto: tediously convert to base 8 for easier comparison to other platforms, though base 16 really is far more natural than base 8 except for permission bits.. From jkrell at elego.de Sun Jan 4 01:53:03 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 1:53:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104005303.84C7110D5E9A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 01:53:03 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utypes.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 Log message: significant reduction in sysdep content off_t is always 64 bits (or at least let's hope so) the dir/stat flags are mostly all the same, except for a few that are zero on cygwin M[RWX][OWNER GROUP OTHER] [FXWR]_OK F_SETFD, F_GETFL, F_SETFL FIONREAD ITIMER_REAL ITIMER_VIRTUAL Some of this might be by chance and not by-standard, so under review for new platforms, and probably should be verified during native builds. note that OS/2 has a different S_IFMT but not quite relevant here From jkrell at elego.de Sun Jan 4 02:09:58 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 2:09:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104010959.29D922200044@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 02:09:57 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Utime.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 Log message: struct_itimerval is always the same From jkrell at elego.de Sun Jan 4 02:13:22 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 2:13:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104011323.4603610D5EB1@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 02:13:22 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Utime.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 Log message: struct_timezone is always the same From jkrell at elego.de Sun Jan 4 02:56:16 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 2:56:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104015616.F307E10D5C54@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 02:56:16 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Utime.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 Log message: struct_timespec is always the same From hosking at cs.purdue.edu Sun Jan 4 02:57:28 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 4 Jan 2009 12:57:28 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20090104005303.84C7110D5E9A@birch.elegosoft.com> References: <20090104005303.84C7110D5E9A@birch.elegosoft.com> Message-ID: <13927A2A-F535-48EB-9A33-4813E2B74442@cs.purdue.edu> On some platforms off_t is not 64 bits. This from Solaris (see off_t==long): #if defined(_LARGEFILE_SOURCE) || defined(_XPG5) #ifndef _OFF_T #define _OFF_T #if defined(_LP64) || _FILE_OFFSET_BITS == 32 typedef long off_t; #else typedef __longlong_t off_t; #endif #ifdef _LARGEFILE64_SOURCE #ifdef _LP64 typedef off_t off64_t; #else typedef __longlong_t off64_t; #endif #endif /* _LARGEFILE64_SOURCE */ #endif /* _OFF_T */ #endif /* _LARGEFILE_SOURCE * Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 4 Jan 2009, at 01:53, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/01/04 01:53:03 > > Modified files: > cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utypes.i3 > cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 > > Log message: > significant reduction in sysdep content > > off_t is always 64 bits (or at least let's hope so) > the dir/stat flags are mostly all the same, > except for a few that are zero on cygwin > > M[RWX][OWNER GROUP OTHER] > [FXWR]_OK > F_SETFD, F_GETFL, F_SETFL > FIONREAD > ITIMER_REAL > ITIMER_VIRTUAL > > Some of this might be by chance and not by-standard, > so under review for new platforms, and probably should be verified > during native builds. > > note that OS/2 has a different S_IFMT but not quite relevant here -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 4 03:22:22 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 4 Jan 2009 02:22:22 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <13927A2A-F535-48EB-9A33-4813E2B74442@cs.purdue.edu> References: <20090104005303.84C7110D5E9A@birch.elegosoft.com> <13927A2A-F535-48EB-9A33-4813E2B74442@cs.purdue.edu> Message-ID: But how about if we always #define _FILE_OFFSET_BITS 64 and use C wrappers? As I have done. Or externs with "64" appended, but that prevents me from using one set of .i3 files. I mean, I know there are "modes" with 32 bit off_t, but we should really strive not to use them, if given a choice, eh? You think there are any systems we will ever care about that don't offer a 64 bit off_t (or off64_t, or whatever). - Jay From: hosking at To: jkrell at Date: Sun, 4 Jan 2009 12:57:28 +1100CC: m3commit at elegosoft.comSubject: Re: [M3commit] CVS Update: cm3On some platforms off_t is not 64 bits. This from Solaris (see off_t==long): #if defined(_LARGEFILE_SOURCE) || defined(_XPG5) #ifndef _OFF_T #define _OFF_T #if defined(_LP64) || _FILE_OFFSET_BITS == 32 typedef long off_t; #else typedef __longlong_t off_t; #endif #ifdef _LARGEFILE64_SOURCE #ifdef _LP64 typedef off_t off64_t; #else typedef __longlong_t off64_t; #endif #endif /* _LARGEFILE64_SOURCE */ #endif /* _OFF_T */ #endif /* _LARGEFILE_SOURCE * Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 4 Jan 2009, at 01:53, Jay Krell wrote: CVSROOT: /usr/cvsChanges by: jkrell at birch. 09/01/04 01:53:03Modified files:cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utypes.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 Log message:significant reduction in sysdep contentoff_t is always 64 bits (or at least let's hope so)the dir/stat flags are mostly all the same,except for a few that are zero on cygwinM[RWX][OWNER GROUP OTHER][FXWR]_OKF_SETFD, F_GETFL, F_SETFLFIONREADITIMER_REALITIMER_VIRTUALSome of this might be by chance and not by-standard,so under review for new platforms, and probably should be verifiedduring native builds.note that OS/2 has a different S_IFMT but not quite relevant here -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Sun Jan 4 07:10:59 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 7:10:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104061100.33872904003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 07:10:59 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Utime.i3 Log message: fix newlines From jkrell at elego.de Sun Jan 4 07:12:01 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 7:12:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104061201.D8FEE10D5EC8@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 07:12:01 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Utime.i3 Log message: messed this up earlier -- fix ITIMER_REAL and ITIMER_VIRTUAL From jkrell at elego.de Sun Jan 4 07:14:31 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 7:14:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104061431.A8CEC10D5EC8@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 07:14:31 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Utime.i3 Log message: fix.. From jkrell at elego.de Sun Jan 4 08:03:58 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 8:03:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104070359.010CE10D5EC7@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 08:03:58 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: FilePosixC.c Log message: use correct define for 64 bit file offsets; not sure if it matters here or not From jkrell at elego.de Sun Jan 4 08:04:33 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 8:04:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104070433.68A5010D5EC7@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 08:04:33 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: FSPosix.m3 m3makefile Added files: cm3/m3-libs/libm3/src/os/POSIX/: FSPosixC.c FSPosixC.i3 Log message: replace the lone use of wrapped readdir with a smaller bit of C From jkrell at elego.de Sun Jan 4 08:07:13 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 8:07:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104070713.E95A410D5EC7@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 08:07:13 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Udir.i3 m3makefile cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 Removed files: cm3/m3-libs/m3core/src/unix/Common/: UdirC.c cm3/m3-libs/m3core/src/unix/openbsd-common/: Udir.i3 Log message: remove dirent and varyingly wrapped readdir, having removed the only use pkgtools also uses dirent, but in a way that has 'never' worked on many platforms (e.g. LINUXLIBC), it uses a non-opaque DIR, which POSIX doesn't allow for, and none of the pkgtools directories currently builds; the code using non-opaque DIR could use realpath or something else From jkrell at elego.de Sun Jan 4 08:32:10 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 8:32:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104073211.7FC2810D5EC8@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 08:32:10 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Log message: fix PPC_LINUX, AMD64_LINUX, *_OPENBSD, I thought I already done this -- give them the m3_setitimer function From hosking at cs.purdue.edu Sun Jan 4 05:54:48 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 4 Jan 2009 15:54:48 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20090104005303.84C7110D5E9A@birch.elegosoft.com> <13927A2A-F535-48EB-9A33-4813E2B74442@cs.purdue.edu> Message-ID: <40684423-F337-4C58-BC88-7A0AB7085CF9@cs.purdue.edu> Why not just switch between 32-bit and 64-bit versions. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 4 Jan 2009, at 13:22, Jay wrote: > But how about if we always #define _FILE_OFFSET_BITS 64 and use C > wrappers? > As I have done. > Or externs with "64" appended, but that prevents me from using one > set of .i3 files. > > I mean, I know there are "modes" with 32 bit off_t, but we should > really strive not to use them, if given a choice, eh? > > You think there are any systems we will ever care about that don't > offer a 64 bit off_t (or off64_t, or whatever). > > - Jay > > > From: hosking@ > To: jkrell@ > Date: Sun, 4 Jan 2009 12:57:28 +1100 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > On some platforms off_t is not 64 bits. This from Solaris (see > off_t==long): > > #if defined(_LARGEFILE_SOURCE) || defined(_XPG5) > #ifndef _OFF_T > #define _OFF_T > #if defined(_LP64) || _FILE_OFFSET_BITS == 32 > typedef long off_t; > #else > typedef __longlong_t off_t; > #endif > #ifdef _LARGEFILE64_SOURCE > #ifdef _LP64 > typedef off_t off64_t; > #else > typedef __longlong_t off64_t; > #endif > #endif /* _LARGEFILE64_SOURCE */ > #endif /* _OFF_T */ > #endif /* _LARGEFILE_SOURCE * > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > On 4 Jan 2009, at 01:53, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/01/04 01:53:03 > > Modified files: > cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utypes.i3 > cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 > > Log message: > significant reduction in sysdep content > > off_t is always 64 bits (or at least let's hope so) > the dir/stat flags are mostly all the same, > except for a few that are zero on cygwin > > M[RWX][OWNER GROUP OTHER] > [FXWR]_OK > F_SETFD, F_GETFL, F_SETFL > FIONREAD > ITIMER_REAL > ITIMER_VIRTUAL > > Some of this might be by chance and not by-standard, > so under review for new platforms, and probably should be verified > during native builds. > > note that OS/2 has a different S_IFMT but not quite relevant here > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 4 09:35:40 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 4 Jan 2009 08:35:40 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <40684423-F337-4C58-BC88-7A0AB7085CF9@cs.purdue.edu> References: <20090104005303.84C7110D5E9A@birch.elegosoft.com> <13927A2A-F535-48EB-9A33-4813E2B74442@cs.purdue.edu> <40684423-F337-4C58-BC88-7A0AB7085CF9@cs.purdue.edu> Message-ID: Exactly how? Like off_t == word? That isn't right. Switch which files? I want to reduce switching more than what is needed. Can the string in an extern be "forwarded"? That would be the ideal granularity here. Darwin does stuff very similar or maybe the same as I am doing -- wrapper functions in C for reasons related to off_t, though the wrappers are a bit dubious, e.g.: int m3_pread(int d, void *buf, size_t nbytes, int offset){ off_t off = (off_t)offset; return pread(d, buf, nbytes, offset);} int m3_profil(char *samples, size_t size, u_long offset, u_int scale){ off_t off = (off_t)offset; return profil(samples, size, offset, scale);} int m3_pwrite(int d, const void *buf, size_t nbytes, int offset){ off_t off = (off_t)offset; return pwrite(d, buf, nbytes, offset);} int m3_ftruncate(int fd, int length){ off_t len = (off_t) length; return ftruncate(fd, length);} What does the first line of each of those accomplish? voidm3_assignOffT (off_t* dest, long src){ *dest = (off_t)src;} Is that widening or narrowing, and if it is narrowing, silent truncation? Granted, Modula-3 doesn't check for integer overflow anyway, so silent truncation I guess is "ok". Ideally, every system would have a 64 bit off_t, if not the default, at least via #defines, or using function names with "64" appended (or both). The case for 32bit off_t would be interop with existing code. Otherwise, it seems clear that it should always, if possible, be 64 bits. time_t should be 64 bits too, but that's another matter. I did just check and DJGPP seems limited to 32bit off_t. So eventually it might have to go back to Usysdep.i3, but ok. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Sun, 4 Jan 2009 15:54:48 +1100CC: m3commit at elegosoft.comSubject: Re: [M3commit] CVS Update: cm3Why not just switch between 32-bit and 64-bit versions. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 4 Jan 2009, at 13:22, Jay wrote: But how about if we always #define _FILE_OFFSET_BITS 64 and use C wrappers? As I have done. Or externs with "64" appended, but that prevents me from using one set of .i3 files. I mean, I know there are "modes" with 32 bit off_t, but we should really strive not to use them, if given a choice, eh? You think there are any systems we will ever care about that don't offer a 64 bit off_t (or off64_t, or whatever). - Jay From: hosking at To: jkrell at Date: Sun, 4 Jan 2009 12:57:28 +1100CC: m3commit at elegosoft.comSubject: Re: [M3commit] CVS Update: cm3On some platforms off_t is not 64 bits. This from Solaris (see off_t==long): #if defined(_LARGEFILE_SOURCE) || defined(_XPG5) #ifndef _OFF_T #define _OFF_T #if defined(_LP64) || _FILE_OFFSET_BITS == 32 typedef long off_t; #else typedef __longlong_t off_t; #endif #ifdef _LARGEFILE64_SOURCE #ifdef _LP64 typedef off_t off64_t; #else typedef __longlong_t off64_t; #endif #endif /* _LARGEFILE64_SOURCE */ #endif /* _OFF_T */ #endif /* _LARGEFILE_SOURCE * Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 4 Jan 2009, at 01:53, Jay Krell wrote: CVSROOT: /usr/cvsChanges by: jkrell at birch. 09/01/04 01:53:03Modified files:cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utypes.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 Log message:significant reduction in sysdep contentoff_t is always 64 bits (or at least let's hope so)the dir/stat flags are mostly all the same,except for a few that are zero on cygwinM[RWX][OWNER GROUP OTHER][FXWR]_OKF_SETFD, F_GETFL, F_SETFLFIONREADITIMER_REALITIMER_VIRTUALSome of this might be by chance and not by-standard,so under review for new platforms, and probably should be verifiedduring native builds.note that OS/2 has a different S_IFMT but not quite relevant here -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Jan 4 11:02:18 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 4 Jan 2009 21:02:18 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20090104005303.84C7110D5E9A@birch.elegosoft.com> <13927A2A-F535-48EB-9A33-4813E2B74442@cs.purdue.edu> <40684423-F337-4C58-BC88-7A0AB7085CF9@cs.purdue.edu> Message-ID: Darwin no longer uses wrapper functions for pread etc. I figured a static switch at build time. On 4 Jan 2009, at 19:35, Jay wrote: > Exactly how? > Like off_t == word? > That isn't right. > > Switch which files? > I want to reduce switching more than what is needed. > Can the string in an extern be "forwarded"? > That would be the ideal granularity here. > Darwin does stuff very similar or maybe the same as I am doing -- > wrapper functions in C for reasons related to off_t, though the > wrappers are a bit dubious, e.g.: > > int m3_pread(int d, void *buf, size_t nbytes, int offset) > { > off_t off = (off_t)offset; > return pread(d, buf, nbytes, offset); > } > > int m3_profil(char *samples, size_t size, u_long offset, u_int scale) > { > off_t off = (off_t)offset; > return profil(samples, size, offset, scale); > } > > int m3_pwrite(int d, const void *buf, size_t nbytes, int offset) > { > off_t off = (off_t)offset; > return pwrite(d, buf, nbytes, offset); > } > > int m3_ftruncate(int fd, int length) > { > off_t len = (off_t) length; > return ftruncate(fd, length); > } > > What does the first line of each of those accomplish? > > void > m3_assignOffT (off_t* dest, long src) > { > *dest = (off_t)src; > } > > Is that widening or narrowing, and if it is narrowing, silent > truncation? > Granted, Modula-3 doesn't check for integer overflow anyway, so > silent truncation I guess is "ok". > > Ideally, every system would have a 64 bit off_t, if not the default, > at least via #defines, or using function names with "64" appended > (or both). The case for 32bit off_t would be interop with existing > code. Otherwise, it seems clear that it should always, if possible, > be 64 bits. time_t should be 64 bits too, but that's another matter. > > I did just check and DJGPP seems limited to 32bit off_t. > So eventually it might have to go back to Usysdep.i3, but ok. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Sun, 4 Jan 2009 15:54:48 +1100 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Why not just switch between 32-bit and 64-bit versions. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > On 4 Jan 2009, at 13:22, Jay wrote: > > But how about if we always #define _FILE_OFFSET_BITS 64 and use C > wrappers? > As I have done. > Or externs with "64" appended, but that prevents me from using one > set of .i3 files. > > I mean, I know there are "modes" with 32 bit off_t, but we should > really strive not to use them, if given a choice, eh? > > You think there are any systems we will ever care about that don't > offer a 64 bit off_t (or off64_t, or whatever). > > - Jay > > > From: hosking@ > To: jkrell@ > Date: Sun, 4 Jan 2009 12:57:28 +1100 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > On some platforms off_t is not 64 bits. This from Solaris (see > off_t==long): > > #if defined(_LARGEFILE_SOURCE) || defined(_XPG5) > #ifndef _OFF_T > #define _OFF_T > #if defined(_LP64) || _FILE_OFFSET_BITS == 32 > typedef long off_t; > #else > typedef __longlong_t off_t; > #endif > #ifdef _LARGEFILE64_SOURCE > #ifdef _LP64 > typedef off_t off64_t; > #else > typedef __longlong_t off64_t; > #endif > #endif /* _LARGEFILE64_SOURCE */ > #endif /* _OFF_T */ > #endif /* _LARGEFILE_SOURCE * > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > On 4 Jan 2009, at 01:53, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/01/04 01:53:03 > > Modified files: > cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utypes.i3 > cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 > > Log message: > significant reduction in sysdep content > > off_t is always 64 bits (or at least let's hope so) > the dir/stat flags are mostly all the same, > except for a few that are zero on cygwin > > M[RWX][OWNER GROUP OTHER] > [FXWR]_OK > F_SETFD, F_GETFL, F_SETFL > FIONREAD > ITIMER_REAL > ITIMER_VIRTUAL > > Some of this might be by chance and not by-standard, > so under review for new platforms, and probably should be verified > during native builds. > > note that OS/2 has a different S_IFMT but not quite relevant here > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Mon Jan 5 04:53:07 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 4:53:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105035307.89FBE220043C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 04:53:07 Modified files: cm3/m3-libs/m3core/src/: Uwaitpid.quake m3makefile cm3/m3-libs/m3core/src/runtime/POSIX/: m3makefile Log message: try again to deal with m3unix.h, perhaps in a way that works with cross bootstrapping From jkrell at elego.de Mon Jan 5 05:19:08 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 5:19:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105041908.CC15010D582F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 05:19:08 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Udir.i3 Uexec.i3 Unetdb.i3 Unix.i3 Uprocess.i3 Upthread.i3 Upwd.i3 Uresource.i3 Usched.i3 Usem.i3 Usignal.i3 Usocket.i3 Ustat.i3 Utime.i3 Uugid.i3 Uuio.i3 Log message: Well, what do you know..I go looking into the compiler for a purpose too much to describe here, and I find that entire interfaces can be marked external, cool. From jkrell at elego.de Mon Jan 5 05:28:20 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 5:28:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105042820.B0BAB10D582F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 05:28:20 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: FilePosix.m3 Log message: remove a few tabs From jkrell at elego.de Mon Jan 5 05:37:13 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 5:37:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105043713.783AD10D5E5B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 05:37:13 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: FilePosix.m3 Log message: reduce but don't eliminate race condition; before there was a race in a multithreaded code, now there is 'only' a race in multithreaded code under optimization that reorders writes (we need MemoryBarrier() for this kind of lock free on demand initialization of globals..) From jkrell at elego.de Mon Jan 5 06:38:01 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 6:38:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105053802.B6F6710D5E65@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 06:38:01 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 Log message: remove a few tabs From jkrell at elego.de Mon Jan 5 06:46:28 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 6:46:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105054628.7E69C10D5E65@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 06:46:28 Modified files: cm3/m3-libs/m3core/src/unix/linux-sparc/: Usocket.i3 Usignal.i3 Log message: make it more like common, for later merge/refactor From jkrell at elego.de Mon Jan 5 07:58:35 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 7:58:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105065835.4E31710D5DD1@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 07:58:35 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile Log message: fix win32, it has its own minimal Unix/Uuio, probably useless From jkrell at elego.de Mon Jan 5 08:25:48 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 8:25:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105072548.AB46610D5D2A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 08:25:48 Modified files: cm3/m3-sys/m3front/src/builtinOps/: Adr.m3 Log message: minor cleanup; should see about switching this? Or removing it? Looks like some indecisiveness and that the switched off way is more type-safe.. From jkrell at elego.de Mon Jan 5 10:37:21 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 10:37:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105093721.E382810D5E7C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 10:37:21 Modified files: cm3/scripts/python/: pylib.py Log message: port CheckForLinkSwitch from scripts/win/sysinfo.cmd, but then, oops, it is redundant, print to make that clearer From jkrell at elego.de Mon Jan 5 10:43:43 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 10:43:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105094343.DA5E110D5E68@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 10:43:43 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Log message: keep the timezone/daylight code out of FreeBSD (tinderbox error) From jkrell at elego.de Mon Jan 5 10:48:34 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 10:48:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105094835.10F7110D5E68@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 10:48:34 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Log message: and NetBSD From jkrell at elego.de Mon Jan 5 10:53:02 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 10:53:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105095302.0802210D5E68@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 10:53:02 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Log message: fix comment From jkrell at elego.de Mon Jan 5 20:10:55 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 20:10:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105191055.CAA2C10D5AF4@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 20:10:55 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: FilePosix.m3 Log message: fix (tinderbox, all posix platforms, I must not have compiled) From jkrell at elego.de Mon Jan 5 20:46:11 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 20:46:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105194611.6CA0B10D5C41@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 20:46:11 Modified files: cm3/m3-libs/m3core/src/runtime/common/: m3makefile Log message: forgot this earlier, only non-mainstream platforms affected From jkrell at elego.de Mon Jan 5 20:54:24 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 20:54:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105195424.0B8ED10D5C41@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 20:54:24 Modified files: cm3/m3-libs/m3core/src/runtime/: m3makefile Removed files: cm3/m3-libs/m3core/src/runtime/AMD64_LINUX/: RTMachine.i3 RTSignal.m3 m3makefile Log message: I thought I commited this last night -- move fairly common files to common directory. Only non-mainstream (so far) platforms affected. RTMachine.i3 might become platform-dependent with user therad support but RTSignal.m3 is quite identical/similar across all platforms, though will shortly be rewritten in C so that we can remove more platform-dependent "cloned headers". From jkrell at elego.de Mon Jan 5 21:04:04 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 21:04:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105200404.B479410D5C41@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 21:04:04 Added files: cm3/m3-libs/m3core/src/runtime/common/: RTMachine.i3 RTSignal.m3 Log message: try try again to add these files (one problem I have is that cvs commit usually crashes on one machine so I have to copy to another) From jkrell at elego.de Mon Jan 5 21:05:33 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 21:05:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105200533.190D110D5C41@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 21:05:33 Added files: cm3/m3-libs/m3core/src/runtime/common/: RTError.h RTProcess.h RTSignalC.c RTSignalC.h m3text.h Log message: work in progress -- rewriting RTSignal.m3 in C saves us from declaring several system-depenedant things in cloned headers, and is easy and portable enough From jkrell at elego.de Mon Jan 5 21:07:51 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 21:07:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105200751.8450810D5C41@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 21:07:51 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTSignal.m3 Log message: the correct version of this -- written in Modula-3 for now From jkrell at elego.de Mon Jan 5 21:33:38 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 21:33:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105203338.0987310D5C41@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 21:33:38 Modified files: cm3/m3-libs/m3core/src/: Uwaitpid.quake Log message: give up on sharing the header and just copy the two lines, alas From jkrell at elego.de Mon Jan 5 23:33:05 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 23:33:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105223305.8F54D10D59A7@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 23:33:05 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTSignal.m3 Log message: fix paste error From jkrell at elego.de Mon Jan 5 23:34:43 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 23:34:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105223443.9EB2610D59A7@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 23:34:43 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTLinkerC.c Log message: remove tab From jkrell at elego.de Tue Jan 6 00:33:06 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 6 Jan 2009 0:33:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105233322.4C3E510D582D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/06 00:33:05 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: fix newline From jkrell at elego.de Tue Jan 6 12:07:04 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 6 Jan 2009 12:07:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090106110704.5AFAC10D5CFC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/06 12:07:04 Modified files: cm3/m3-libs/m3core/src/: Uwaitpid.quake Log message: need sys/types on Linux From jkrell at elego.de Thu Jan 8 01:02:02 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 8 Jan 2009 1:02:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090108000202.8643E904006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/08 01:02:01 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile Log message: sort the list From hosking at elego.de Fri Jan 9 04:43:17 2009 From: hosking at elego.de (Antony Hosking) Date: Fri, 9 Jan 2009 4:43:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090109034317.8FD97220004B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 09/01/09 04:43:17 Modified files: cm3/m3-libs/m3core/src/convert/: CConvert.i3 CConvert.m3 Convert.m3 Log message: Fix space leak in calls to dtoa. The result must be freed using freedtoa. From hosking at elego.de Fri Jan 9 21:43:00 2009 From: hosking at elego.de (Antony Hosking) Date: Fri, 9 Jan 2009 21:43:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090109204300.E5218904007@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 09/01/09 21:43:00 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: dtoa.h Log message: Oops, forgot this which has m3_freedtoa. From jkrell at elego.de Sat Jan 10 14:02:13 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 10 Jan 2009 14:02:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090110130219.4A91790403A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/10 14:02:08 Modified files: cm3/scripts/python/: pylib.py Log message: AMD64_FREEBSD support; put .SUFFIXES in boot makefile to avoid a bunch of warnings about circularity (there is a builtin rule for these suffixes?); add RTSignalC.c to bootstrap packages (if it exists, as usual) From jkrell at elego.de Sat Jan 10 14:36:57 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 10 Jan 2009 14:36:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090110133657.203E810D4E24@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/10 14:36:57 Modified files: cm3/scripts/python/: pylib.py Log message: SPARC64_LINUX needs -Av9 switch on gas to assemble, though the result still hangs (-64 selects 64 bit ELF, -Av9 selects V9 architecture; there is also V9a and V9b, but V9 seems to suffice) From jkrell at elego.de Sun Jan 11 00:19:00 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 0:19:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090110231900.228A5904006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 00:19:00 Modified files: cm3/m3-libs/m3core/src/unix/freebsd-4/: Upthread.i3 Log message: remove unused import to remove warning From jkrell at elego.de Sun Jan 11 00:19:38 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 0:19:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090110231938.7B813904006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 00:19:38 Modified files: cm3/m3-libs/m3core/src/unix/openbsd-common/: m3makefile Log message: Udir not here any longer From jkrell at elego.de Sun Jan 11 00:43:18 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 0:43:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090110234318.24C6010D458D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 00:43:18 Modified files: cm3/m3-libs/m3core/src/runtime/common/: m3text.h RTError.h RTProcess.h RTSignalC.c RTSignalC.h Added files: cm3/m3-libs/m3core/src/runtime/common/: RTSignalC.i3 Log message: add extern "C" prepare for more Usignal reduction and AMD64_FREEBSD port From jkrell at elego.de Sun Jan 11 00:46:42 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 0:46:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090110234642.A060710D458D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 00:46:42 Added files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThreadC.c ThreadPThreadC.i3 Log message: prepare for Usignal reduction and AMD64_FREEBSD port From jkrell at elego.de Sun Jan 11 00:48:55 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 0:48:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090110234855.A764610D535B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 00:48:55 Added files: cm3/m3-sys/cminstall/src/config-no-install/: FreeBSD4 AMD64_FREEBSD Log message: AMD64_FREEBSD support and at least partial FreeBSD4 (for some significant level of verification via cross building) From jkrell at elego.de Sun Jan 11 01:00:38 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 1:00:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111000039.2EB80904006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 01:00:38 Added files: cm3/m3-libs/m3core/src/C/AMD64_FREEBSD/: m3makefile Csetjmp.i3 Log message: add files for AMD64_FREEBSD; diffs later From jkrell at elego.de Sun Jan 11 01:01:15 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 1:01:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111000116.0835A10D5D5D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 01:01:15 Added files: cm3/m3-libs/m3core/src/unix/freebsd-common/: m3makefile Uerror.i3 Usysdep.i3 Uucontext.i3 Log message: add files for AMD64_FREEBSD; diffs later From jkrell at elego.de Sun Jan 11 01:44:47 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 1:44:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111004447.5014E10D535B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 01:44:47 Modified files: cm3/m3-libs/m3core/src/C/PPC_LINUX/: Csetjmp.i3 Log message: remove use of sigset_t so we can prune Usignal; just make the thing properly sized with opaque data; note that it is declared in C as being aligned to 16 bytes but we can't declare that and the comments in the C header say that is ok From jkrell at elego.de Sun Jan 11 01:45:08 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 1:45:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111004509.461AE10D535B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 01:45:08 Modified files: cm3/m3-libs/m3core/src/C/PPC_LINUX/: Csetjmp.i3 Log message: opaque From jkrell at elego.de Sun Jan 11 14:35:04 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 14:35:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111133509.AF03F10D5DA3@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 14:35:04 Modified files: cm3/m3-ui/ui/src/xvbt/: XSharedMem.m3 Log message: workaround fatal error starting up remoted X apps on FreeBSD by cloning underlying function and indicating if it would raise its fatal error; more insight would be welcome here; note that for local X apps (ie: if $DISPLAY is not set) there is no impact, other than allocating a lock From jkrell at elego.de Sun Jan 11 14:50:57 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 14:50:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 14:50:57 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: OSConfigPosix.m3 cm3/m3-libs/libm3/src/random/: m3makefile cm3/m3-libs/m3core/src/: thread.quake cm3/m3-libs/m3core/src/C/Common/: m3makefile cm3/m3-libs/m3core/src/Csupport/: m3makefile cm3/m3-libs/m3core/src/float/: m3makefile cm3/m3-libs/m3core/src/runtime/: m3makefile cm3/m3-libs/m3core/src/runtime/common/: Compiler.tmpl RTLinkerC.c RTMachine.i3 RTSignal.m3 m3makefile cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 ThreadPThreadC.c ThreadPThreadC.i3 m3makefile cm3/m3-libs/m3core/src/time/POSIX/: m3makefile cm3/m3-libs/m3core/src/unix/: m3makefile cm3/m3-libs/m3core/src/unix/Common/: Usem.i3 Usignal.i3 m3makefile cm3/m3-libs/m3core/src/unix/freebsd-common/: Usysdep.i3 m3makefile cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-sparc/: Usignal.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 m3makefile cm3/m3-sys/m3cc/src/: m3makefile cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 cm3/scripts/python/: pylib.py cm3/www/uploaded-archives/: targets.txt Added files: cm3/m3-libs/m3core/src/unix/Common/: Uucontext.i3 Removed files: cm3/m3-libs/m3core/src/unix/freebsd-common/: Uucontext.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Uucontext.i3 Log message: AMD64_FREEBSD port add a few more files to bootstrap archives Usignal reduction, remove: SIGHUP SIGQUIT SIGABRT SIGSEGV SIGPIPE SIGTERM NSIG (Linux specific) SA_RESTART SA_SIGINFO SignalHandler sigset_t siginfo_t_star struct_sigaction (important) sigaction (would be ok, but no longer used) sigdelset (would be ok, but no longer used) sigemptyset (would be ok, but no longer used) sigfillset (would be ok, but no longer used) sigpending (would be ok, but no longer used) sigprocmask (would be ok, but no longer used) make common: SignalActionHandler Uucontext, just ucontext_t_star = ADDRESS; sigset_t removed have Usysdep define SIG_SUSPEND instead of going through Usignal intermediate remove sem_t header clone; declare the variable in C likewise Upthread.mask speculatively add some more targets to m3-sys/m3cc/src/m3makefile, some of which have had backends built, but not all From jkrell at elego.de Sun Jan 11 15:20:14 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 15:20:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111142016.98AB410D5D5D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 15:20:14 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: outputing to _m3.log failing for some reason on SPARC32_LINUX, remove (temporary?) From jkrell at elego.de Sun Jan 11 15:29:16 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 15:29:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111142916.72D7B714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 15:29:16 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 ThreadPThreadC.i3 Log message: Some platforms call SignalActionHandler just 'SignalAction'. Drop the Usignal depdenency and just declare it ourselves here. From jkrell at elego.de Sun Jan 11 15:31:25 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 15:31:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111143125.B7E2B10D5C59@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 15:31:25 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: remove unused import Uucontext From jkrell at elego.de Sun Jan 11 15:32:36 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 15:32:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111143236.2C55B10D5C59@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 15:32:36 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThreadC.c Log message: fix newlines From jkrell at elego.de Sun Jan 11 23:46:40 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 23:46:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111224641.4BD58714574@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 23:46:40 Modified files: cm3/m3-libs/m3core/src/unix/Common/: m3makefile cm3/www/uploaded-archives/: targets.txt Log message: fix newlines From jkrell at elego.de Sun Jan 11 23:48:04 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 23:48:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111224804.5855C714573@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 23:48:04 Modified files: cm3/m3-libs/m3core/src/unix/linux-32/: m3makefile Removed files: cm3/m3-libs/m3core/src/unix/linux-32/: Uucontext.i3 Log message: no more platform specific Uucontext (in some ports) From jkrell at elego.de Mon Jan 12 00:08:24 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 0:08:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111230824.8F8E710D5FAD@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 00:08:24 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: if ROOT is not defined (the root of the source tree), don't probe, rather than erroring for lack of ROOT From jkrell at elego.de Mon Jan 12 00:08:39 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 0:08:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111230839.AEC1910D5FAD@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 00:08:39 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: backwards From jkrell at elego.de Mon Jan 12 00:34:41 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 0:34:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111233442.57DE510D5FB1@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 00:34:41 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThreadC.c Log message: make the assertions actually check each call, not just the first, duh From jkrell at elego.de Mon Jan 12 01:49:11 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 1:49:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112004911.D509F10D5FB5@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 01:49:11 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: SocketPosix.m3 Log message: change switches to if ladders so that Uerror can change constants to variables and replace system dependent cloned headers with portable C From hosking at cs.purdue.edu Mon Jan 12 01:59:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 11:59:07 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20090112004911.D509F10D5FB5@birch.elegosoft.com> References: <20090112004911.D509F10D5FB5@birch.elegosoft.com> Message-ID: <7F816AC4-68DD-4881-97A8-08C973E97E1A@cs.purdue.edu> Jay, I really don't like this. What's wrong with constants again? On 12 Jan 2009, at 01:49, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/01/12 01:49:11 > > Modified files: > cm3/m3-libs/libm3/src/os/POSIX/: SocketPosix.m3 > > Log message: > change switches to if ladders so that Uerror can change constants > to variables and replace system dependent cloned headers with > portable C From jay.krell at cornell.edu Mon Jan 12 07:44:20 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 06:44:20 +0000 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> Message-ID: I basically agree here. I view thread.quake as temporary. Once m3core (that you bootstrap from) has SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. Or some other fix involving sysutils not knowing this (it sounds like you an easy one that I missed). And then the code that is generated when building m3core can be the exact checked in code, was my intention. I guess what I could/should have done is just put in SchedulerPosix.DoesWaitYield, wait some amount of time, and then move sysutils over it, not fix sysutils asap. I can go ahead and do that now -- "fix" m3core, re-"break" (slow down) sysutils, and then at whatever time, have sysutils use the new function. I had noticed cygwin builds seeming to take way way longer than I remember, like >12 hours instead of <1hour. I didn't track down if this is the cause. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:18:29 +1100> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > I really hate the idea that thread.quake exists.> > Screw sysutils working against old m3core versions. sysutils doing > thread-related scheduling is a big hack, and should be killed now > before it infects others. I don't want to see thread-dependent code > outside of m3core. We really need to come to consensus on this before > you do more damage to the core thread libraries.> > I feel strongly about this!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 07:49:55 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 17:49:55 +1100 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> Message-ID: <2599269D-3447-4D5C-8D8B-2A535027EBCF@cs.purdue.edu> Why do you need DoesWaitPidYield? As I mentioned in another post, fixing sysutils to use a properly scheduled version of waitpid is trivial. I don't think you need all this DoesWaitPidYield junk. Frankly, I think the threads code is now a mess and needs to be reverted. On 12 Jan 2009, at 17:44, Jay wrote: > I basically agree here. > I view thread.quake as temporary. > Once m3core (that you bootstrap from) has > SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. > Or some other fix involving sysutils not knowing this (it sounds > like you an easy one that I missed). > > And then the code that is generated when building m3core can be the > exact checked in code, was my intention. > > I guess what I could/should have done is just put in > SchedulerPosix.DoesWaitYield, wait some amount of time, and then > move sysutils over it, not fix sysutils asap. > > I can go ahead and do that now -- "fix" m3core, re-"break" (slow > down) sysutils, and then at whatever time, have sysutils use the new > function. > > I had noticed cygwin builds seeming to take way way longer than I > remember, like >12 hours instead of <1hour. I didn't track down if > this is the cause. > > - Jay > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:18:29 +1100 > > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > I really hate the idea that thread.quake exists. > > > > Screw sysutils working against old m3core versions. sysutils doing > > thread-related scheduling is a big hack, and should be killed now > > before it infects others. I don't want to see thread-dependent code > > outside of m3core. We really need to come to consensus on this > before > > you do more damage to the core thread libraries. > > > > I feel strongly about this! > > > > -- Tony > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 08:01:50 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 07:01:50 +0000 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: <2599269D-3447-4D5C-8D8B-2A535027EBCF@cs.purdue.edu> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <2599269D-3447-4D5C-8D8B-2A535027EBCF@cs.purdue.edu> Message-ID: I need to go back and study that. It implies I missed something big when I made the change. I could have sworn I looked at the functions and decided one could not be implemented on top of the other but it sounds like I missed one. Hold on. DoesWaitPidYield is not the problem really though. We agree, at its worst, it would be cloned, in regular Modula-3 code (not quake). At its best, it would be gone. The bigger change is sharing the SchedulerPosix implementation on Win32 threads for Cygwin. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 17:49:55 +1100CC: m3devel at elegosoft.com; m3commit at elegosoft.comSubject: Re: [M3commit] [M3devel] CVS Update: cm3Why do you need DoesWaitPidYield? As I mentioned in another post, fixing sysutils to use a properly scheduled version of waitpid is trivial. I don't think you need all this DoesWaitPidYield junk. Frankly, I think the threads code is now a mess and needs to be reverted. On 12 Jan 2009, at 17:44, Jay wrote: I basically agree here.I view thread.quake as temporary.Once m3core (that you bootstrap from) has SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. Or some other fix involving sysutils not knowing this (it sounds like you an easy one that I missed). And then the code that is generated when building m3core can be the exact checked in code, was my intention. I guess what I could/should have done is just put in SchedulerPosix.DoesWaitYield, wait some amount of time, and then move sysutils over it, not fix sysutils asap. I can go ahead and do that now -- "fix" m3core, re-"break" (slow down) sysutils, and then at whatever time, have sysutils use the new function. I had noticed cygwin builds seeming to take way way longer than I remember, like >12 hours instead of <1hour. I didn't track down if this is the cause. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:18:29 +1100> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > I really hate the idea that thread.quake exists.> > Screw sysutils working against old m3core versions. sysutils doing > thread-related scheduling is a big hack, and should be killed now > before it infects others. I don't want to see thread-dependent code > outside of m3core. We really need to come to consensus on this before > you do more damage to the core thread libraries.> > I feel strongly about this!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 08:05:48 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 18:05:48 +1100 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <2599269D-3447-4D5C-8D8B-2A535027EBCF@cs.purdue.edu> Message-ID: <7A6A105A-B305-4F14-91D2-1D2DC6F09BEC@cs.purdue.edu> I think the whole DoesWaitPidYield thing is a red herring. Can you just wait for me to put in my fix to the CVS head and you can look and see what you think? I would really like to reinstate the original structure for m3core/src/thread too, but I don't know what the constraints are w.r.to your C header file hacking and the need for Cygwin to have a SchedulerPosix implementation. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 12 Jan 2009, at 18:01, Jay wrote: > I need to go back and study that. It implies I missed something big > when I made the change. > I could have sworn I looked at the functions and decided one could > not be implemented > on top of the other but it sounds like I missed one. Hold on. > > DoesWaitPidYield is not the problem really though. > We agree, at its worst, it would be cloned, in regular Modula-3 code > (not quake). > At its best, it would be gone. > > The bigger change is sharing the SchedulerPosix implementation on > Win32 threads for Cygwin. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 17:49:55 +1100 > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > Subject: Re: [M3commit] [M3devel] CVS Update: cm3 > > Why do you need DoesWaitPidYield? As I mentioned in another post, > fixing sysutils to use a properly scheduled version of waitpid is > trivial. I don't think you need all this DoesWaitPidYield junk. > > Frankly, I think the threads code is now a mess and needs to be > reverted. > > On 12 Jan 2009, at 17:44, Jay wrote: > > I basically agree here. > I view thread.quake as temporary. > Once m3core (that you bootstrap from) has > SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. > Or some other fix involving sysutils not knowing this (it sounds > like you an easy one that I missed). > > And then the code that is generated when building m3core can be the > exact checked in code, was my intention. > > I guess what I could/should have done is just put in > SchedulerPosix.DoesWaitYield, wait some amount of time, and then > move sysutils over it, not fix sysutils asap. > > I can go ahead and do that now -- "fix" m3core, re-"break" (slow > down) sysutils, and then at whatever time, have sysutils use the new > function. > > I had noticed cygwin builds seeming to take way way longer than I > remember, like >12 hours instead of <1hour. I didn't track down if > this is the cause. > > - Jay > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:18:29 +1100 > > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > I really hate the idea that thread.quake exists. > > > > Screw sysutils working against old m3core versions. sysutils doing > > thread-related scheduling is a big hack, and should be killed now > > before it infects others. I don't want to see thread-dependent code > > outside of m3core. We really need to come to consensus on this > before > > you do more damage to the core thread libraries. > > > > I feel strongly about this! > > > > -- Tony > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 08:07:18 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 18:07:18 +1100 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> Message-ID: <66E87543-8486-4377-9405-2912E14CD96E@cs.purdue.edu> PS What is the name ThreadPScheduler supposed to connote? On 12 Jan 2009, at 17:44, Jay wrote: > I basically agree here. > I view thread.quake as temporary. > Once m3core (that you bootstrap from) has > SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. > Or some other fix involving sysutils not knowing this (it sounds > like you an easy one that I missed). > > And then the code that is generated when building m3core can be the > exact checked in code, was my intention. > > I guess what I could/should have done is just put in > SchedulerPosix.DoesWaitYield, wait some amount of time, and then > move sysutils over it, not fix sysutils asap. > > I can go ahead and do that now -- "fix" m3core, re-"break" (slow > down) sysutils, and then at whatever time, have sysutils use the new > function. > > I had noticed cygwin builds seeming to take way way longer than I > remember, like >12 hours instead of <1hour. I didn't track down if > this is the cause. > > - Jay > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:18:29 +1100 > > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > I really hate the idea that thread.quake exists. > > > > Screw sysutils working against old m3core versions. sysutils doing > > thread-related scheduling is a big hack, and should be killed now > > before it infects others. I don't want to see thread-dependent code > > outside of m3core. We really need to come to consensus on this > before > > you do more damage to the core thread libraries. > > > > I feel strongly about this! > > > > -- Tony > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 08:13:35 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 07:13:35 +0000 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: <7A6A105A-B305-4F14-91D2-1D2DC6F09BEC@cs.purdue.edu> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <2599269D-3447-4D5C-8D8B-2A535027EBCF@cs.purdue.edu> <7A6A105A-B305-4F14-91D2-1D2DC6F09BEC@cs.purdue.edu> Message-ID: I can wait but I really don't think this structure is so awful, rehosting one SchedulerPosix implementation on top of two different threading libraries. Maybe just let Cygwin die? Was the restructuring to use "spawn" sometimes instead of fork/exec also so bad? I actually find that hard to read, but it is theoretically a very large improvement.Cygwin really fails badly compared to "Posix" in fork perf, even if the semantic matches. (and vfork, which is what Modula-3 uses, doesn't help. Cygwin's vfork == fork, both slow.) It is contorted also, but you know, we can't use a line by line #ifdef, so we have to break stuff up into separate files, which often seems less clear (but sometimes is more clear, it depends on how much is different and how much the same; the more that is the same, the better to have #ifdef, the more that is different, the better to have separate files). Or, can I replit out SchedulerPosix after you apply your "actual" changes -- you know, just a way to avoid the merge, but keep the contituent diffs? - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:05:48 +1100CC: m3devel at elegosoft.com; m3commit at elegosoft.comSubject: Re: [M3commit] [M3devel] CVS Update: cm3I think the whole DoesWaitPidYield thing is a red herring. Can you just wait for me to put in my fix to the CVS head and you can look and see what you think? I would really like to reinstate the original structure for m3core/src/thread too, but I don't know what the constraints are w.r.to your C header file hacking and the need for Cygwin to have a SchedulerPosix implementation. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 12 Jan 2009, at 18:01, Jay wrote: I need to go back and study that. It implies I missed something big when I made the change.I could have sworn I looked at the functions and decided one could not be implementedon top of the other but it sounds like I missed one. Hold on. DoesWaitPidYield is not the problem really though.We agree, at its worst, it would be cloned, in regular Modula-3 code (not quake).At its best, it would be gone. The bigger change is sharing the SchedulerPosix implementation on Win32 threads for Cygwin. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 17:49:55 +1100CC: m3devel at elegosoft.com; m3commit at elegosoft.comSubject: Re: [M3commit] [M3devel] CVS Update: cm3Why do you need DoesWaitPidYield? As I mentioned in another post, fixing sysutils to use a properly scheduled version of waitpid is trivial. I don't think you need all this DoesWaitPidYield junk. Frankly, I think the threads code is now a mess and needs to be reverted. On 12 Jan 2009, at 17:44, Jay wrote: I basically agree here.I view thread.quake as temporary.Once m3core (that you bootstrap from) has SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. Or some other fix involving sysutils not knowing this (it sounds like you an easy one that I missed). And then the code that is generated when building m3core can be the exact checked in code, was my intention. I guess what I could/should have done is just put in SchedulerPosix.DoesWaitYield, wait some amount of time, and then move sysutils over it, not fix sysutils asap. I can go ahead and do that now -- "fix" m3core, re-"break" (slow down) sysutils, and then at whatever time, have sysutils use the new function. I had noticed cygwin builds seeming to take way way longer than I remember, like >12 hours instead of <1hour. I didn't track down if this is the cause. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:18:29 +1100> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > I really hate the idea that thread.quake exists.> > Screw sysutils working against old m3core versions. sysutils doing > thread-related scheduling is a big hack, and should be killed now > before it infects others. I don't want to see thread-dependent code > outside of m3core. We really need to come to consensus on this before > you do more damage to the core thread libraries.> > I feel strongly about this!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 08:15:41 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 07:15:41 +0000 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: <66E87543-8486-4377-9405-2912E14CD96E@cs.purdue.edu> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <66E87543-8486-4377-9405-2912E14CD96E@cs.purdue.edu> Message-ID: It is ambiguous, I admit. Feel free to suggest another name. It is PosixScheduler.i3 implementation for Cygwin and pthreads. You could call it PosixSchedulerKernel.m3? PosixScheduler.i3 for threads that are kernel threads? You know -- what does "pthreads" mean -- posix threads, but we have ThreadPThread and ThreadPosix. Also wierd. But ok. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:07:18 +1100CC: jkrell at elego.de; m3devel at elegosoft.com; m3commit at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3PS What is the name ThreadPScheduler supposed to connote? On 12 Jan 2009, at 17:44, Jay wrote: I basically agree here.I view thread.quake as temporary.Once m3core (that you bootstrap from) has SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. Or some other fix involving sysutils not knowing this (it sounds like you an easy one that I missed). And then the code that is generated when building m3core can be the exact checked in code, was my intention. I guess what I could/should have done is just put in SchedulerPosix.DoesWaitYield, wait some amount of time, and then move sysutils over it, not fix sysutils asap. I can go ahead and do that now -- "fix" m3core, re-"break" (slow down) sysutils, and then at whatever time, have sysutils use the new function. I had noticed cygwin builds seeming to take way way longer than I remember, like >12 hours instead of <1hour. I didn't track down if this is the cause. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:18:29 +1100> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > I really hate the idea that thread.quake exists.> > Screw sysutils working against old m3core versions. sysutils doing > thread-related scheduling is a big hack, and should be killed now > before it infects others. I don't want to see thread-dependent code > outside of m3core. We really need to come to consensus on this before > you do more damage to the core thread libraries.> > I feel strongly about this!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 08:16:34 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 07:16:34 +0000 Subject: [M3commit] FW: [M3devel] CVS Update: cm3 In-Reply-To: <7A6A105A-B305-4F14-91D2-1D2DC6F09BEC@cs.purdue.edu> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <2599269D-3447-4D5C-8D8B-2A535027EBCF@cs.purdue.edu> <7A6A105A-B305-4F14-91D2-1D2DC6F09BEC@cs.purdue.edu> Message-ID: [important points/question truncated -- request permission to reapply scheduler split after you apply your diff] From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.com; m3commit at elegosoft.comSubject: RE: [M3commit] [M3devel] CVS Update: cm3Date: Mon, 12 Jan 2009 07:13:35 +0000 I can wait but I really don't think this structure is so awful, rehosting one SchedulerPosix implementation on top of two different threading libraries. Maybe just let Cygwin die? Was the restructuring to use "spawn" sometimes instead of fork/exec also so bad?I actually find that hard to read, but it is theoretically a very large improvement.Cygwin really fails badly compared to "Posix" in fork perf, even if the semantic matches.(and vfork, which is what Modula-3 uses, doesn't help. Cygwin's vfork == fork, both slow.) It is contorted also, but you know, we can't use a line by line #ifdef, so we have to break stuff up into separate files, which often seems less clear (but sometimes is more clear, it depends on how much is different and how much the same; the more that is the same, the better to have #ifdef, the more that is different, the better to have separate files). Or, can I replit out SchedulerPosix after you apply your "actual" changes -- you know, just a way to avoid the merge, but keep the contituent diffs? - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:05:48 +1100CC: m3devel at elegosoft.com; m3commit at elegosoft.comSubject: Re: [M3commit] [M3devel] CVS Update: cm3I think the whole DoesWaitPidYield thing is a red herring. Can you just wait for me to put in my fix to the CVS head and you can look and see what you think? I would really like to reinstate the original structure for m3core/src/thread too, but I don't know what the constraints are w.r.to your C header file hacking and the need for Cygwin to have a SchedulerPosix implementation. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 12 Jan 2009, at 18:01, Jay wrote: I need to go back and study that. It implies I missed something big when I made the change.I could have sworn I looked at the functions and decided one could not be implementedon top of the other but it sounds like I missed one. Hold on. DoesWaitPidYield is not the problem really though.We agree, at its worst, it would be cloned, in regular Modula-3 code (not quake).At its best, it would be gone. The bigger change is sharing the SchedulerPosix implementation on Win32 threads for Cygwin. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 17:49:55 +1100CC: m3devel at elegosoft.com; m3commit at elegosoft.comSubject: Re: [M3commit] [M3devel] CVS Update: cm3Why do you need DoesWaitPidYield? As I mentioned in another post, fixing sysutils to use a properly scheduled version of waitpid is trivial. I don't think you need all this DoesWaitPidYield junk. Frankly, I think the threads code is now a mess and needs to be reverted. On 12 Jan 2009, at 17:44, Jay wrote: I basically agree here.I view thread.quake as temporary.Once m3core (that you bootstrap from) has SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. Or some other fix involving sysutils not knowing this (it sounds like you an easy one that I missed). And then the code that is generated when building m3core can be the exact checked in code, was my intention. I guess what I could/should have done is just put in SchedulerPosix.DoesWaitYield, wait some amount of time, and then move sysutils over it, not fix sysutils asap. I can go ahead and do that now -- "fix" m3core, re-"break" (slow down) sysutils, and then at whatever time, have sysutils use the new function. I had noticed cygwin builds seeming to take way way longer than I remember, like >12 hours instead of <1hour. I didn't track down if this is the cause. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:18:29 +1100> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > I really hate the idea that thread.quake exists.> > Screw sysutils working against old m3core versions. sysutils doing > thread-related scheduling is a big hack, and should be killed now > before it infects others. I don't want to see thread-dependent code > outside of m3core. We really need to come to consensus on this before > you do more damage to the core thread libraries.> > I feel strongly about this!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 08:22:31 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 18:22:31 +1100 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <66E87543-8486-4377-9405-2912E14CD96E@cs.purdue.edu> Message-ID: ThreadPosix is a historic name for threads built on top of simple POSIX primitives. The name was given before POSIX pthreads were even defined. ThreadPThread describes an implementation of threads built on top of POSIX pthreads. ThreadWin32 describes an implementation of threads built on top of Win32 threads. SchedulerPosix is indeed a misnomer, but again that name is a historic artefact. On 12 Jan 2009, at 18:15, Jay wrote: > It is ambiguous, I admit. > Feel free to suggest another name. > It is PosixScheduler.i3 implementation for Cygwin and pthreads. > You could call it PosixSchedulerKernel.m3? PosixScheduler.i3 for > threads that are kernel threads? > > You know -- what does "pthreads" mean -- posix threads, but we have > ThreadPThread and ThreadPosix. > Also wierd. But ok. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 18:07:18 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com; m3commit at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > PS What is the name ThreadPScheduler supposed to connote? > > > On 12 Jan 2009, at 17:44, Jay wrote: > > I basically agree here. > I view thread.quake as temporary. > Once m3core (that you bootstrap from) has > SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. > Or some other fix involving sysutils not knowing this (it sounds > like you an easy one that I missed). > > And then the code that is generated when building m3core can be the > exact checked in code, was my intention. > > I guess what I could/should have done is just put in > SchedulerPosix.DoesWaitYield, wait some amount of time, and then > move sysutils over it, not fix sysutils asap. > > I can go ahead and do that now -- "fix" m3core, re-"break" (slow > down) sysutils, and then at whatever time, have sysutils use the new > function. > > I had noticed cygwin builds seeming to take way way longer than I > remember, like >12 hours instead of <1hour. I didn't track down if > this is the cause. > > - Jay > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:18:29 +1100 > > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > I really hate the idea that thread.quake exists. > > > > Screw sysutils working against old m3core versions. sysutils doing > > thread-related scheduling is a big hack, and should be killed now > > before it infects others. I don't want to see thread-dependent code > > outside of m3core. We really need to come to consensus on this > before > > you do more damage to the core thread libraries. > > > > I feel strongly about this! > > > > -- Tony > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Mon Jan 12 08:29:56 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 8:29:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112072956.A51FF10D5FCF@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 08:29:56 Modified files: cm3/m3-libs/sysutils/src/POSIX/: m3makefile Log message: use a relative path instead of the ROOT variable that all the scripts define From jkrell at elego.de Mon Jan 12 08:45:00 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 8:45:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112074500.5B02410D5FD0@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 08:45:00 Modified files: cm3/m3-libs/sysutils/src/POSIX/: m3makefile Added files: cm3/m3-libs/sysutils/src/POSIX/: Sysutils_DoesWaitPidYield.i3 Sysutils_Uwaitpid.c Sysutils_Uwaitpid.i3 Log message: checkin the generated/duplicated code, at least temporarily From jkrell at elego.de Mon Jan 12 08:55:09 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 8:55:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112075509.793CF10D5FD0@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 08:55:09 Modified files: cm3/m3-libs/m3core/src/: thread.quake cm3/m3-libs/m3core/src/unix/Common/: m3makefile Added files: cm3/m3-libs/m3core/src/unix/Common/: Uwaitpid.c Uwaitpid.i3 Removed files: cm3/m3-libs/m3core/src/: Uwaitpid.quake Log message: checkin generated code From hosking at cs.purdue.edu Mon Jan 12 09:13:38 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 19:13:38 +1100 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: <66E87543-8486-4377-9405-2912E14CD96E@cs.purdue.edu> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <66E87543-8486-4377-9405-2912E14CD96E@cs.purdue.edu> Message-ID: <4FC3FD8A-6992-4B4B-97AB-E68F8CA26B4C@cs.purdue.edu> What clients of waitpid actually care about the status bits? On 12 Jan 2009, at 18:07, Tony Hosking wrote: > PS What is the name ThreadPScheduler supposed to connote? > > On 12 Jan 2009, at 17:44, Jay wrote: > >> I basically agree here. >> I view thread.quake as temporary. >> Once m3core (that you bootstrap from) has >> SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. >> Or some other fix involving sysutils not knowing this (it sounds >> like you an easy one that I missed). >> >> And then the code that is generated when building m3core can be the >> exact checked in code, was my intention. >> >> I guess what I could/should have done is just put in >> SchedulerPosix.DoesWaitYield, wait some amount of time, and then >> move sysutils over it, not fix sysutils asap. >> >> I can go ahead and do that now -- "fix" m3core, re-"break" (slow >> down) sysutils, and then at whatever time, have sysutils use the >> new function. >> >> I had noticed cygwin builds seeming to take way way longer than I >> remember, like >12 hours instead of <1hour. I didn't track down if >> this is the cause. >> >> - Jay >> >> > From: hosking at cs.purdue.edu >> > To: jkrell at elego.de >> > Date: Mon, 12 Jan 2009 11:18:29 +1100 >> > CC: m3devel at elegosoft.com; m3commit at elegosoft.com >> > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 >> > >> > I really hate the idea that thread.quake exists. >> > >> > Screw sysutils working against old m3core versions. sysutils doing >> > thread-related scheduling is a big hack, and should be killed now >> > before it infects others. I don't want to see thread-dependent code >> > outside of m3core. We really need to come to consensus on this >> before >> > you do more damage to the core thread libraries. >> > >> > I feel strongly about this! >> > >> > -- Tony >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 09:30:58 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 08:30:58 +0000 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: <4FC3FD8A-6992-4B4B-97AB-E68F8CA26B4C@cs.purdue.edu> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <66E87543-8486-4377-9405-2912E14CD96E@cs.purdue.edu> <4FC3FD8A-6992-4B4B-97AB-E68F8CA26B4C@cs.purdue.edu> Message-ID: Asking me? I don't know. What sysutils does, sort of does. Right? You know -- there is the exit code or the exit signal. It seems to be using roughly (exit signal << 8) | exit code. I tried to "just" read the code (~ two weeks) but I might have read it wrong and I don't remember what I found, only that I meant to retain semantics, except for the efficiency of the wait. I don't think that explains the repacking though. I have to read it again (again, again). That's what m3core was hiding, the exit signal? I'll check. - Jay From: hosking at cs.purdue.eduTo: hosking at cs.purdue.eduDate: Mon, 12 Jan 2009 19:13:38 +1100CC: m3devel at elegosoft.com; m3commit at elegosoft.com; jay.krell at cornell.eduSubject: Re: [M3commit] [M3devel] CVS Update: cm3What clients of waitpid actually care about the status bits? On 12 Jan 2009, at 18:07, Tony Hosking wrote: PS What is the name ThreadPScheduler supposed to connote? On 12 Jan 2009, at 17:44, Jay wrote: I basically agree here.I view thread.quake as temporary.Once m3core (that you bootstrap from) has SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. Or some other fix involving sysutils not knowing this (it sounds like you an easy one that I missed). And then the code that is generated when building m3core can be the exact checked in code, was my intention. I guess what I could/should have done is just put in SchedulerPosix.DoesWaitYield, wait some amount of time, and then move sysutils over it, not fix sysutils asap. I can go ahead and do that now -- "fix" m3core, re-"break" (slow down) sysutils, and then at whatever time, have sysutils use the new function. I had noticed cygwin builds seeming to take way way longer than I remember, like >12 hours instead of <1hour. I didn't track down if this is the cause. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:18:29 +1100> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > I really hate the idea that thread.quake exists.> > Screw sysutils working against old m3core versions. sysutils doing > thread-related scheduling is a big hack, and should be killed now > before it infects others. I don't want to see thread-dependent code > outside of m3core. We really need to come to consensus on this before > you do more damage to the core thread libraries.> > I feel strongly about this!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 09:51:55 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 19:51:55 +1100 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <66E87543-8486-4377-9405-2912E14CD96E@cs.purdue.edu> <4FC3FD8A-6992-4B4B-97AB-E68F8CA26B4C@cs.purdue.edu> Message-ID: Well, I find the repacking somewhat dubious, but without knowing what the clients of Process.Wait and System.Wait expect, perhaps we should leave it that way for now. Certainly, client code that has endian- ness assumptions built in regarding the status value is clearly broken and should be fixed at source, rather than relying on some weird underlying repacking hack. I will retain the current packings. As I understand it, the current contortions are to provide an implementation of SchedulerPosix for Win32 threads platforms like Cygwin that are otherwise POSIX. Correct? On 12 Jan 2009, at 19:30, Jay wrote: > Asking me? I don't know. > What sysutils does, sort of does. Right? > You know -- there is the exit code or the exit signal. > It seems to be using roughly (exit signal << 8) | exit code. > > I tried to "just" read the code (~ two weeks) but I might have read > it wrong and I don't remember what I found, only that I meant to > retain semantics, except for the efficiency of the wait. > > I don't think that explains the repacking though. > I have to read it again (again, again). > > That's what m3core was hiding, the exit signal? > I'll check. > > - Jay > > > From: hosking at cs.purdue.edu > To: hosking at cs.purdue.edu > Date: Mon, 12 Jan 2009 19:13:38 +1100 > CC: m3devel at elegosoft.com; m3commit at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3commit] [M3devel] CVS Update: cm3 > > What clients of waitpid actually care about the status bits? > > > On 12 Jan 2009, at 18:07, Tony Hosking wrote: > > PS What is the name ThreadPScheduler supposed to connote? > > On 12 Jan 2009, at 17:44, Jay wrote: > > I basically agree here. > I view thread.quake as temporary. > Once m3core (that you bootstrap from) has > SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. > Or some other fix involving sysutils not knowing this (it sounds > like you an easy one that I missed). > > And then the code that is generated when building m3core can be the > exact checked in code, was my intention. > > I guess what I could/should have done is just put in > SchedulerPosix.DoesWaitYield, wait some amount of time, and then > move sysutils over it, not fix sysutils asap. > > I can go ahead and do that now -- "fix" m3core, re-"break" (slow > down) sysutils, and then at whatever time, have sysutils use the new > function. > > I had noticed cygwin builds seeming to take way way longer than I > remember, like >12 hours instead of <1hour. I didn't track down if > this is the cause. > > - Jay > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:18:29 +1100 > > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > I really hate the idea that thread.quake exists. > > > > Screw sysutils working against old m3core versions. sysutils doing > > thread-related scheduling is a big hack, and should be killed now > > before it infects others. I don't want to see thread-dependent code > > outside of m3core. We really need to come to consensus on this > before > > you do more damage to the core thread libraries. > > > > I feel strongly about this! > > > > -- Tony > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 10:06:12 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 09:06:12 +0000 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <66E87543-8486-4377-9405-2912E14CD96E@cs.purdue.edu> <4FC3FD8A-6992-4B4B-97AB-E68F8CA26B4C@cs.purdue.edu> Message-ID: Right, the point was to provide a correct seeming SchedulerPosix.i3 on Cygwin, using Win32 threads. It, and NT386 (same code -- ThreadWin32.m3), had a dummy one before. I probably put that dummy in myself without thinking about it. I can't say that I really tested the implementation or measure anything before/after. (in fact, I can say I did not). But it definitely looks better (functionality, not structure). Maybe time to test Cygwin pthreads again? - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 19:51:55 +1100CC: m3devel at elegosoft.com; m3commit at elegosoft.comSubject: Re: [M3commit] [M3devel] CVS Update: cm3 Well, I find the repacking somewhat dubious, but without knowing what the clients of Process.Wait and System.Wait expect, perhaps we should leave it that way for now. Certainly, client code that has endian-ness assumptions built in regarding the status value is clearly broken and should be fixed at source, rather than relying on some weird underlying repacking hack. I will retain the current packings. As I understand it, the current contortions are to provide an implementation of SchedulerPosix for Win32 threads platforms like Cygwin that are otherwise POSIX. Correct? On 12 Jan 2009, at 19:30, Jay wrote: Asking me? I don't know.What sysutils does, sort of does. Right?You know -- there is the exit code or the exit signal.It seems to be using roughly (exit signal << 8) | exit code. I tried to "just" read the code (~ two weeks) but I might have read it wrong and I don't remember what I found, only that I meant to retain semantics, except for the efficiency of the wait. I don't think that explains the repacking though.I have to read it again (again, again). That's what m3core was hiding, the exit signal?I'll check. - Jay From: hosking at cs.purdue.eduTo: hosking at cs.purdue.eduDate: Mon, 12 Jan 2009 19:13:38 +1100CC: m3devel at elegosoft.com; m3commit at elegosoft.com; jay.krell at cornell.eduSubject: Re: [M3commit] [M3devel] CVS Update: cm3What clients of waitpid actually care about the status bits? On 12 Jan 2009, at 18:07, Tony Hosking wrote: PS What is the name ThreadPScheduler supposed to connote? On 12 Jan 2009, at 17:44, Jay wrote: I basically agree here.I view thread.quake as temporary.Once m3core (that you bootstrap from) has SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. Or some other fix involving sysutils not knowing this (it sounds like you an easy one that I missed). And then the code that is generated when building m3core can be the exact checked in code, was my intention. I guess what I could/should have done is just put in SchedulerPosix.DoesWaitYield, wait some amount of time, and then move sysutils over it, not fix sysutils asap. I can go ahead and do that now -- "fix" m3core, re-"break" (slow down) sysutils, and then at whatever time, have sysutils use the new function. I had noticed cygwin builds seeming to take way way longer than I remember, like >12 hours instead of <1hour. I didn't track down if this is the cause. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:18:29 +1100> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > I really hate the idea that thread.quake exists.> > Screw sysutils working against old m3core versions. sysutils doing > thread-related scheduling is a big hack, and should be killed now > before it infects others. I don't want to see thread-dependent code > outside of m3core. We really need to come to consensus on this before > you do more damage to the core thread libraries.> > I feel strongly about this!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at elego.de Mon Jan 12 10:20:33 2009 From: hosking at elego.de (Antony Hosking) Date: Mon, 12 Jan 2009 10:20:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112092033.2748010D5FD1@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 09/01/12 10:20:33 Modified files: cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 ThreadPWait.m3 cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 m3makefile cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile Log message: Try to clean up mess with Process.Wait and System.Wait based on waitpid. Packing is now returned to Process.Wait and System.Wait where it used to be. Not sure if this re-packing is needed by clients, but should verify. From jay.krell at cornell.edu Mon Jan 12 11:11:17 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 10:11:17 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20090112092033.2748010D5FD1@birch.elegosoft.com> References: <20090112092033.2748010D5FD1@birch.elegosoft.com> Message-ID: > relies on particular endian-ness of the status > word they return. Really, those clients should > be using proper bit-shifts and bit-masks to extract > the right values rather than some endian- dependent RECORD layout defined in Uexec Wasn't Uwaitpid.c a good portable way to do exactly that? I guess it can be written in Modula-3 though, if the headers are cloned as they are. Aren't {I386,AMD64}_DARWIN broken here? Besides all "my" ports, which don't define those types. Yeah yeah, all I have to do is switch on endian and I can introduce them.. I'll see about Cygwin pthreads. - Jay> Date: Mon, 12 Jan 2009 10:20:33 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 09/01/12 10:20:33> > Modified files:> cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > ThreadPWait.m3 > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > m3makefile > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > Log message:> Try to clean up mess with Process.Wait and System.Wait based on waitpid.> > Packing is now returned to Process.Wait and System.Wait where it used to be.> > Not sure if this re-packing is needed by clients, but should verify.> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 11:28:10 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 10:28:10 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20090112092033.2748010D5FD1@birch.elegosoft.com> References: <20090112092033.2748010D5FD1@birch.elegosoft.com> Message-ID: Eek, was this really the way to go? It really seemed better before to me. Before it was automatically portable without declaring the packed return type or NOHANG. - Jay From: jay.krell at cornell.eduTo: hosking at elego.de; m3commit at elegosoft.comSubject: RE: [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 10:11:17 +0000 > relies on particular endian-ness of the status > word they return. Really, those clients should > be using proper bit-shifts and bit-masks to extract > the right values rather than some endian- dependent RECORD layout defined in Uexec Wasn't Uwaitpid.c a good portable way to do exactly that? I guess it can be written in Modula-3 though, if the headers are cloned as they are. Aren't {I386,AMD64}_DARWIN broken here? Besides all "my" ports, which don't define those types. Yeah yeah, all I have to do is switch on endian and I can introduce them.. I'll see about Cygwin pthreads. - Jay> Date: Mon, 12 Jan 2009 10:20:33 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 09/01/12 10:20:33> > Modified files:> cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > ThreadPWait.m3 > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > m3makefile > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > Log message:> Try to clean up mess with Process.Wait and System.Wait based on waitpid.> > Packing is now returned to Process.Wait and System.Wait where it used to be.> > Not sure if this re-packing is needed by clients, but should verify.> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Mon Jan 12 11:41:36 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 11:41:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112104136.707C210D5FCF@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 11:41:36 Modified files: cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 Log message: remove unused type to fix warning From hosking at cs.purdue.edu Mon Jan 12 12:25:25 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 22:25:25 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20090112092033.2748010D5FD1@birch.elegosoft.com> Message-ID: <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> On 12 Jan 2009, at 21:11, Jay wrote: > > relies on particular endian-ness of the status > > word they return. Really, those clients should > > be using proper bit-shifts and bit-masks to extract > > the right values rather than some endian- dependent RECORD layout > defined in Uexec > > Wasn't Uwaitpid.c a good portable way to do exactly that? I didn't look too closely at that. I wanted something that retained the simplicity of calling waitpid as: PROCEDURE waitpid(pid: int; VAR status: int; options: int): int; > I guess it can be written in Modula-3 though, if the headers are > cloned as they are. > Aren't {I386,AMD64}_DARWIN broken here? I don't think so -- Uexec is still there. > Besides all "my" ports, which don't define those types. > Yeah yeah, all I have to do is switch on endian and I can introduce > them.. But really, clients of waitpid/SchedulerPosix.WaitProcess should be prepared to shift the status return value correctly! After all, the interface doc for Process.Wait indicates that the return value is the status word. > I'll see about Cygwin pthreads. Yes, it would be a more coherent solution. > > > - Jay > > > Date: Mon, 12 Jan 2009 10:20:33 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 09/01/12 10:20:33 > > > > Modified files: > > cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > > ThreadPWait.m3 > > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > > m3makefile > > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > > > Log message: > > Try to clean up mess with Process.Wait and System.Wait based on > waitpid. > > > > Packing is now returned to Process.Wait and System.Wait where it > used to be. > > > > Not sure if this re-packing is needed by clients, but should verify. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 12:26:01 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 22:26:01 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20090112092033.2748010D5FD1@birch.elegosoft.com> Message-ID: <3F2E7A20-E9AE-4D3D-8262-032F356E0253@cs.purdue.edu> Eek, what? On 12 Jan 2009, at 21:28, Jay wrote: > Eek, was this really the way to go? > It really seemed better before to me. > Before it was automatically portable without declaring the packed > return type or NOHANG. > > - Jay > > > > From: jay.krell at cornell.edu > To: hosking at elego.de; m3commit at elegosoft.com > Subject: RE: [M3commit] CVS Update: cm3 > Date: Mon, 12 Jan 2009 10:11:17 +0000 > > > relies on particular endian-ness of the status > > word they return. Really, those clients should > > be using proper bit-shifts and bit-masks to extract > > the right values rather than some endian- dependent RECORD layout > defined in Uexec > > Wasn't Uwaitpid.c a good portable way to do exactly that? > I guess it can be written in Modula-3 though, if the headers are > cloned as they are. > Aren't {I386,AMD64}_DARWIN broken here? > Besides all "my" ports, which don't define those types. > Yeah yeah, all I have to do is switch on endian and I can introduce > them.. > > I'll see about Cygwin pthreads. > > - Jay > > > Date: Mon, 12 Jan 2009 10:20:33 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 09/01/12 10:20:33 > > > > Modified files: > > cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > > ThreadPWait.m3 > > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > > m3makefile > > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > > > Log message: > > Try to clean up mess with Process.Wait and System.Wait based on > waitpid. > > > > Packing is now returned to Process.Wait and System.Wait where it > used to be. > > > > Not sure if this re-packing is needed by clients, but should verify. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Mon Jan 12 12:28:31 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 12:28:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112112831.5F3C810D5E8B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 12:28:31 Modified files: cm3/m3-libs/m3core/src/unix/big-endian/: m3makefile cm3/m3-libs/m3core/src/unix/little-endian/: m3makefile cm3/m3-libs/m3core/src/unix/Common/: m3makefile Added files: cm3/m3-libs/m3core/src/unix/big-endian/: Uexec.i3 cm3/m3-libs/m3core/src/unix/little-endian/: Uexec.i3 Log message: clone more headers to account for non portable waitpid reintroduction; what was wrong with what was here? Aren't several ports wrong e.g. {I386,AMD64}_DARWIN, PPC_LINUX? I guess the point is to stop anyone from using this data at all, so as to not need to return it one way or the other? From hosking at cs.purdue.edu Mon Jan 12 12:38:46 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 22:38:46 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20090112112831.5F3C810D5E8B@birch.elegosoft.com> References: <20090112112831.5F3C810D5E8B@birch.elegosoft.com> Message-ID: <64BB1AFE-D740-44B8-A576-DDE0125EAB24@cs.purdue.edu> I'm not sure what you mean by the ports being wrong. Can you explain more? On 12 Jan 2009, at 12:28, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/01/12 12:28:31 > > Modified files: > cm3/m3-libs/m3core/src/unix/big-endian/: m3makefile > cm3/m3-libs/m3core/src/unix/little-endian/: m3makefile > cm3/m3-libs/m3core/src/unix/Common/: m3makefile > Added files: > cm3/m3-libs/m3core/src/unix/big-endian/: Uexec.i3 > cm3/m3-libs/m3core/src/unix/little-endian/: Uexec.i3 > > Log message: > clone more headers to account for non portable waitpid > reintroduction; what was wrong with what was here? Aren't several > ports wrong e.g. {I386,AMD64}_DARWIN, PPC_LINUX? I guess the point > is to stop anyone from using this data at all, so as to not need to > return it one way or the other? From hosking at cs.purdue.edu Mon Jan 12 12:41:56 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 22:41:56 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20090112112831.5F3C810D5E8B@birch.elegosoft.com> References: <20090112112831.5F3C810D5E8B@birch.elegosoft.com> Message-ID: <9ADACB4E-1D6A-4FDB-9A63-90BFEBAAB169@cs.purdue.edu> PS I would love to avoid cloning the headers. waitpid would be invocable without any wrapper -- it's up to the client code to interpret the status word properly as needs. On 12 Jan 2009, at 12:28, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/01/12 12:28:31 > > Modified files: > cm3/m3-libs/m3core/src/unix/big-endian/: m3makefile > cm3/m3-libs/m3core/src/unix/little-endian/: m3makefile > cm3/m3-libs/m3core/src/unix/Common/: m3makefile > Added files: > cm3/m3-libs/m3core/src/unix/big-endian/: Uexec.i3 > cm3/m3-libs/m3core/src/unix/little-endian/: Uexec.i3 > > Log message: > clone more headers to account for non portable waitpid > reintroduction; what was wrong with what was here? Aren't several > ports wrong e.g. {I386,AMD64}_DARWIN, PPC_LINUX? I guess the point > is to stop anyone from using this data at all, so as to not need to > return it one way or the other? From hosking at cs.purdue.edu Mon Jan 12 12:42:06 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 22:42:06 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20090112112831.5F3C810D5E8B@birch.elegosoft.com> References: <20090112112831.5F3C810D5E8B@birch.elegosoft.com> Message-ID: PS I would love to avoid cloning the headers. waitpid would be invocable without any wrapper -- it's up to the client code to interpret the status word properly as needs. On 12 Jan 2009, at 12:28, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/01/12 12:28:31 > > Modified files: > cm3/m3-libs/m3core/src/unix/big-endian/: m3makefile > cm3/m3-libs/m3core/src/unix/little-endian/: m3makefile > cm3/m3-libs/m3core/src/unix/Common/: m3makefile > Added files: > cm3/m3-libs/m3core/src/unix/big-endian/: Uexec.i3 > cm3/m3-libs/m3core/src/unix/little-endian/: Uexec.i3 > > Log message: > clone more headers to account for non portable waitpid > reintroduction; what was wrong with what was here? Aren't several > ports wrong e.g. {I386,AMD64}_DARWIN, PPC_LINUX? I guess the point > is to stop anyone from using this data at all, so as to not need to > return it one way or the other? From jay.krell at cornell.edu Mon Jan 12 12:49:32 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 11:49:32 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20090112112831.5F3C810D5E8B@birch.elegosoft.com> Message-ID: [all tangent] This indirectly answers one of my questions perhaps, as to the level of avoiding cloning headers. You have no problem with this level of header cloning: Uexec.i3 <*external*> PROCEDURE waitpid(pid:Utypes.pid_t, status:UNTRACED REF int, int options):int; You know -- 1) the need to define pid_t correctly. 2) The assumption that it is trafficing in int, and not e.g. short or long? "portable enough"? I think maybe so. And even this can be "checked" on native builds, but always used "directly". There is an argument that even something "like this" would benefit from being wrapped in C where we have very tight control over the Modula-3<->C transition. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 22:42:06 +1100> CC: m3commit at elegosoft.com> Subject: Re: [M3commit] CVS Update: cm3> > PS I would love to avoid cloning the headers. waitpid would be > invocable without any wrapper -- it's up to the client code to > interpret the status word properly as needs.> > > On 12 Jan 2009, at 12:28, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 09/01/12 12:28:31> >> > Modified files:> > cm3/m3-libs/m3core/src/unix/big-endian/: m3makefile> > cm3/m3-libs/m3core/src/unix/little-endian/: m3makefile> > cm3/m3-libs/m3core/src/unix/Common/: m3makefile> > Added files:> > cm3/m3-libs/m3core/src/unix/big-endian/: Uexec.i3> > cm3/m3-libs/m3core/src/unix/little-endian/: Uexec.i3> >> > Log message:> > clone more headers to account for non portable waitpid > > reintroduction; what was wrong with what was here? Aren't several > > ports wrong e.g. {I386,AMD64}_DARWIN, PPC_LINUX? I guess the point > > is to stop anyone from using this data at all, so as to not need to > > return it one way or the other?> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 12:53:50 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 11:53:50 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <9ADACB4E-1D6A-4FDB-9A63-90BFEBAAB169@cs.purdue.edu> References: <20090112112831.5F3C810D5E8B@birch.elegosoft.com> <9ADACB4E-1D6A-4FDB-9A63-90BFEBAAB169@cs.purdue.edu> Message-ID: uh oh.I sense a possible big vocabulary difference. There are, indeed, two ways of cloning headers. One way is with super tight fidelity.Declaring the types in Modula-3 to match exactly what it is in the .h files..h files that you don't write yourself, that vary from system to system,and may be full of #ifdefs and hard to read (but sure, preprocess them).This is what I don't like.It is tedious, error prone, dangerous.This is historically what was done. The alternative is, well, also cloning headers.You write your own.But you don't put any #ifdefs in them.You make them easy to read.They are the same for Solaris, Linux, little endian, big endian (no bit fields), etc. The ones you write yourself, you write in both Modula-3 and C.You have your Modula-3 code call your C code, and then your C calls "the OS", viaits headers, that you no longer have to read and clone. This is what I have been doing. In fact, maybe the ones you write yourself you write in xml or some otherconstrained language/schema, and write a tool to spit out Modula .i3 and C .h files. We are on the same page, right? Bad to clone /usr/include. Ok to clone stuff you write yourself. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 22:41:56 +1100> CC: m3commit at elegosoft.com> Subject: Re: [M3commit] CVS Update: cm3> > PS I would love to avoid cloning the headers. waitpid would be > invocable without any wrapper -- it's up to the client code to > interpret the status word properly as needs.> > > On 12 Jan 2009, at 12:28, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 09/01/12 12:28:31> >> > Modified files:> > cm3/m3-libs/m3core/src/unix/big-endian/: m3makefile> > cm3/m3-libs/m3core/src/unix/little-endian/: m3makefile> > cm3/m3-libs/m3core/src/unix/Common/: m3makefile> > Added files:> > cm3/m3-libs/m3core/src/unix/big-endian/: Uexec.i3> > cm3/m3-libs/m3core/src/unix/little-endian/: Uexec.i3> >> > Log message:> > clone more headers to account for non portable waitpid > > reintroduction; what was wrong with what was here? Aren't several > > ports wrong e.g. {I386,AMD64}_DARWIN, PPC_LINUX? I guess the point > > is to stop anyone from using this data at all, so as to not need to > > return it one way or the other?> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 12:55:39 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 11:55:39 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <64BB1AFE-D740-44B8-A576-DDE0125EAB24@cs.purdue.edu> References: <20090112112831.5F3C810D5E8B@birch.elegosoft.com> <64BB1AFE-D740-44B8-A576-DDE0125EAB24@cs.purdue.edu> Message-ID: I believe: linux-libc6 defines the little endian types. PPC_LINUX is wrong. darwin-generic defines the big endian types. I386_DARWIN and AMD64_DARWIN are wrong. All the platforms I have been hammering on don't define any of the types. My Uwaitpid.c was "automatically" correct for any platform. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 22:38:46 +1100> CC: m3commit at elegosoft.com> Subject: Re: [M3commit] CVS Update: cm3> > I'm not sure what you mean by the ports being wrong. Can you explain > more?> > On 12 Jan 2009, at 12:28, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 09/01/12 12:28:31> >> > Modified files:> > cm3/m3-libs/m3core/src/unix/big-endian/: m3makefile> > cm3/m3-libs/m3core/src/unix/little-endian/: m3makefile> > cm3/m3-libs/m3core/src/unix/Common/: m3makefile> > Added files:> > cm3/m3-libs/m3core/src/unix/big-endian/: Uexec.i3> > cm3/m3-libs/m3core/src/unix/little-endian/: Uexec.i3> >> > Log message:> > clone more headers to account for non portable waitpid > > reintroduction; what was wrong with what was here? Aren't several > > ports wrong e.g. {I386,AMD64}_DARWIN, PPC_LINUX? I guess the point > > is to stop anyone from using this data at all, so as to not need to > > return it one way or the other?> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 12:58:34 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 11:58:34 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <3F2E7A20-E9AE-4D3D-8262-032F356E0253@cs.purdue.edu> References: <20090112092033.2748010D5FD1@birch.elegosoft.com> <3F2E7A20-E9AE-4D3D-8262-032F356E0253@cs.purdue.edu> Message-ID: Eek using the packed types in Uexec.i3 instead of my portable Uwaitpid.i3, Uwaitpid.c that unpacked everything into a whole number of bytes (no bit fields or shifting for the caller to wory about), and formed the value that I believe the loopholes were historically getting. A big part of the change. - Jay CC: hosking at elego.de; m3commit at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 22:26:01 +1100 Eek, what? On 12 Jan 2009, at 21:28, Jay wrote: Eek, was this really the way to go?It really seemed better before to me.Before it was automatically portable without declaring the packed return type or NOHANG. - Jay From: jay.krell at cornell.eduTo: hosking at elego.de; m3commit at elegosoft.comSubject: RE: [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 10:11:17 +0000 > relies on particular endian-ness of the status > word they return. Really, those clients should > be using proper bit-shifts and bit-masks to extract > the right values rather than some endian- dependent RECORD layout defined in Uexec Wasn't Uwaitpid.c a good portable way to do exactly that? I guess it can be written in Modula-3 though, if the headers are cloned as they are. Aren't {I386,AMD64}_DARWIN broken here? Besides all "my" ports, which don't define those types. Yeah yeah, all I have to do is switch on endian and I can introduce them.. I'll see about Cygwin pthreads. - Jay> Date: Mon, 12 Jan 2009 10:20:33 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 09/01/12 10:20:33> > Modified files:> cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > ThreadPWait.m3 > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > m3makefile > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > Log message:> Try to clean up mess with Process.Wait and System.Wait based on waitpid.> > Packing is now returned to Process.Wait and System.Wait where it used to be.> > Not sure if this re-packing is needed by clients, but should verify.> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 13:08:29 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 12:08:29 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> References: <20090112092033.2748010D5FD1@birch.elegosoft.com> <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> Message-ID: Hm. So I guess the point then is to return one "reasonable" integer, and "reasonable" is actually defined as (coredump << 15) | (termsig << 8) | exitcode That's the point of the repacking? and coredump and termsig are usually 0. Anyway, I don't think even this 7/1/8/16 split is specified by Posix. Right? Uwaitpid.c was a good portable method I think. It was based on the example code in online Posix docs (which you originally pointed me to). - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 22:25:25 +1100CC: m3commit at elegosoft.comSubject: Re: [M3commit] CVS Update: cm3 On 12 Jan 2009, at 21:11, Jay wrote: > relies on particular endian-ness of the status > word they return. Really, those clients should > be using proper bit-shifts and bit-masks to extract > the right values rather than some endian- dependent RECORD layout defined in Uexec Wasn't Uwaitpid.c a good portable way to do exactly that? I didn't look too closely at that. I wanted something that retained the simplicity of calling waitpid as: PROCEDURE waitpid(pid: int; VAR status: int; options: int): int; I guess it can be written in Modula-3 though, if the headers are cloned as they are. Aren't {I386,AMD64}_DARWIN broken here? I don't think so -- Uexec is still there. Besides all "my" ports, which don't define those types. Yeah yeah, all I have to do is switch on endian and I can introduce them.. But really, clients of waitpid/SchedulerPosix.WaitProcess should be prepared to shift the status return value correctly! After all, the interface doc for Process.Wait indicates that the return value is the status word. I'll see about Cygwin pthreads. Yes, it would be a more coherent solution. - Jay> Date: Mon, 12 Jan 2009 10:20:33 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 09/01/12 10:20:33> > Modified files:> cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > ThreadPWait.m3 > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > m3makefile > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > Log message:> Try to clean up mess with Process.Wait and System.Wait based on waitpid.> > Packing is now returned to Process.Wait and System.Wait where it used to be.> > Not sure if this re-packing is needed by clients, but should verify.> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Mon Jan 12 13:26:56 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 13:26:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112122656.AE89510D5FD1@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 13:26:56 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Log message: fix cygwin From jkrell at elego.de Mon Jan 12 14:25:27 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 14:25:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112132528.0CA6310D4E24@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 14:25:27 Modified files: cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 Log message: Convert errno case to 'if ladder' so we can use auto-ported C variables instead of port-requiring constants From jkrell at elego.de Mon Jan 12 14:44:25 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 14:44:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112134425.CEA0C10D5F24@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 14:44:25 Modified files: cm3/m3-libs/m3core/src/unix/Common/: m3makefile cm3/m3-libs/m3core/src/unix/linux-common/: m3makefile cm3/m3-libs/m3core/src/unix/linux-sparc/: m3makefile cm3/m3-libs/m3core/src/unix/openbsd-common/: m3makefile Added files: cm3/m3-libs/m3core/src/unix/Common/: Uerror.c Uerror.i3 UerrorX.h Removed files: cm3/m3-libs/m3core/src/unix/linux-common/: Uerror.i3 cm3/m3-libs/m3core/src/unix/linux-sparc/: Uerror.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Uerror.i3 Log message: move to portable rendition of Uerror for now exclude Cygwin From jkrell at elego.de Mon Jan 12 14:46:18 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 14:46:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112134618.2D79510D5F24@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 14:46:18 Modified files: cm3/m3-libs/m3core/src/unix/freebsd-common/: m3makefile Removed files: cm3/m3-libs/m3core/src/unix/freebsd-common/: Uerror.i3 Log message: this one too From jkrell at elego.de Mon Jan 12 15:09:08 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 15:09:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112140908.77D4E10D5F28@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 15:09:08 Modified files: cm3/m3-libs/m3core/src/C/PPC_LINUX/: Csetjmp.i3 Log message: remove unused import From hosking at cs.purdue.edu Mon Jan 12 01:18:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 11:18:29 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> Message-ID: I really hate the idea that thread.quake exists. Screw sysutils working against old m3core versions. sysutils doing thread-related scheduling is a big hack, and should be killed now before it infects others. I don't want to see thread-dependent code outside of m3core. We really need to come to consensus on this before you do more damage to the core thread libraries. I feel strongly about this! -- Tony From jkrell at elego.de Mon Jan 12 15:49:07 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 15:49:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112144907.B25CC10D5F28@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 15:49:07 Modified files: cm3/m3-comm/tcp/src/POSIX/: TCP.m3 Log message: convert another case on errno to an 'if ladder' so that CONST can be VAR for auto-porting From hosking at cs.purdue.edu Mon Jan 12 21:23:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 13 Jan 2009 07:23:29 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20090112092033.2748010D5FD1@birch.elegosoft.com> <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> Message-ID: I guess I'd like to get rid of the re-packing and fix the clients instead. On 12 Jan 2009, at 23:08, Jay wrote: > Hm. So I guess the point then is to return one "reasonable" integer, > and > "reasonable" is actually defined as > > (coredump << 15) | (termsig << 8) | exitcode > > That's the point of the repacking? > and coredump and termsig are usually 0. > > Anyway, I don't think even this 7/1/8/16 split is specified by > Posix. Right? > Uwaitpid.c was a good portable method I think. > It was based on the example code in online Posix docs (which you > originally pointed me to). > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 22:25:25 +1100 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > On 12 Jan 2009, at 21:11, Jay wrote: > > > relies on particular endian-ness of the status > > word they return. Really, those clients should > > be using proper bit-shifts and bit-masks to extract > > the right values rather than some endian- dependent RECORD layout > defined in Uexec > > Wasn't Uwaitpid.c a good portable way to do exactly that? > > I didn't look too closely at that. I wanted something that retained > the simplicity of calling waitpid as: > > PROCEDURE waitpid(pid: int; VAR status: int; options: int): int; > > I guess it can be written in Modula-3 though, if the headers are > cloned as they are. > Aren't {I386,AMD64}_DARWIN broken here? > > I don't think so -- Uexec is still there. > > Besides all "my" ports, which don't define those types. > Yeah yeah, all I have to do is switch on endian and I can introduce > them.. > > But really, clients of waitpid/SchedulerPosix.WaitProcess should be > prepared to shift the status return value correctly! After all, the > interface doc for Process.Wait indicates that the return value is > the status word. > > I'll see about Cygwin pthreads. > > Yes, it would be a more coherent solution. > > > > - Jay > > > Date: Mon, 12 Jan 2009 10:20:33 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 09/01/12 10:20:33 > > > > Modified files: > > cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > > ThreadPWait.m3 > > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > > m3makefile > > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > > > Log message: > > Try to clean up mess with Process.Wait and System.Wait based on > waitpid. > > > > Packing is now returned to Process.Wait and System.Wait where it > used to be. > > > > Not sure if this re-packing is needed by clients, but should verify. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 21:34:38 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 13 Jan 2009 07:34:38 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20090112092033.2748010D5FD1@birch.elegosoft.com> <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> Message-ID: <54C1E71A-CCCD-4E09-9426-A0F300402858@cs.purdue.edu> I guess I'd like to get rid of the re-packing and fix the clients instead. On 12 Jan 2009, at 23:08, Jay wrote: > Hm. So I guess the point then is to return one "reasonable" integer, > and > "reasonable" is actually defined as > > (coredump << 15) | (termsig << 8) | exitcode > > That's the point of the repacking? > and coredump and termsig are usually 0. > > Anyway, I don't think even this 7/1/8/16 split is specified by > Posix. Right? > Uwaitpid.c was a good portable method I think. > It was based on the example code in online Posix docs (which you > originally pointed me to). > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 22:25:25 +1100 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > On 12 Jan 2009, at 21:11, Jay wrote: > > > relies on particular endian-ness of the status > > word they return. Really, those clients should > > be using proper bit-shifts and bit-masks to extract > > the right values rather than some endian- dependent RECORD layout > defined in Uexec > > Wasn't Uwaitpid.c a good portable way to do exactly that? > > I didn't look too closely at that. I wanted something that retained > the simplicity of calling waitpid as: > > PROCEDURE waitpid(pid: int; VAR status: int; options: int): int; > > I guess it can be written in Modula-3 though, if the headers are > cloned as they are. > Aren't {I386,AMD64}_DARWIN broken here? > > I don't think so -- Uexec is still there. > > Besides all "my" ports, which don't define those types. > Yeah yeah, all I have to do is switch on endian and I can introduce > them.. > > But really, clients of waitpid/SchedulerPosix.WaitProcess should be > prepared to shift the status return value correctly! After all, the > interface doc for Process.Wait indicates that the return value is > the status word. > > I'll see about Cygwin pthreads. > > Yes, it would be a more coherent solution. > > > > - Jay > > > Date: Mon, 12 Jan 2009 10:20:33 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 09/01/12 10:20:33 > > > > Modified files: > > cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > > ThreadPWait.m3 > > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > > m3makefile > > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > > > Log message: > > Try to clean up mess with Process.Wait and System.Wait based on > waitpid. > > > > Packing is now returned to Process.Wait and System.Wait where it > used to be. > > > > Not sure if this re-packing is needed by clients, but should verify. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Mon Jan 12 23:42:28 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 23:42:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112224228.13F7110D5EBC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 23:42:28 Modified files: cm3/m3-sys/cminstall/src/config/: NT386.common Log message: Ship and statically link to Uerror.obj IF it exists, it will exist after I finish investigating cygwin/pthreads. Data cannot be dynamically linked on Win32 without more work. The really portable solution is to use functions, but that is not source compatible and I'm reluctant, but maybe.. From hosking at elego.de Tue Jan 13 00:46:03 2009 From: hosking at elego.de (Antony Hosking) Date: Tue, 13 Jan 2009 0:46:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112234604.07A6110D5DAA@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 09/01/13 00:46:03 Modified files: cm3/m3-libs/m3core/src/thread/: m3makefile cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 cm3/m3-libs/m3core/src/thread/WIN32/: m3makefile Added files: cm3/m3-libs/m3core/src/thread/WIN32/: SchedulerPosix.m3 ThreadInternal.i3 Removed files: cm3/m3-libs/m3core/src/thread/: ThreadInternal.i3 ThreadPScheduler.m3 ThreadPWait.m3 Log message: Restore the coherence of the thread packages (keeping code for different thread implementations together, and avoiding smearing across implementations). The only weird hybrid (which should in probably anyway use PTHREAD instead of WIN32) is CygWin. Keep the mess created by this hybrid in the WIN32 implementation where it belongs rather than complicating all the other pure pthread-based implementations. From jay.krell at cornell.edu Tue Jan 13 06:50:43 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 13 Jan 2009 05:50:43 +0000 Subject: [M3commit] waitpit In-Reply-To: <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> References: <20090112092033.2748010D5FD1@birch.elegosoft.com> <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> Message-ID: I think "what I was missing" here is the option of changing the Process.Wait or SchedulerPosix.WaitProcess interface to return the status bits. I don't think this is how it was before, (which I think was implied). Maybe I misread it, between returning the pid/success vs. the status word? I had added the new interface SchedulerPosix.DoesWaitPidYield, but left others asis. Now, true, I'm arguing both sides, since I did make Uerror.i3 incompatible with some clients. Exposing more information like that seems a good solution, leaving the next level down to waitpid(0) or waitpid(nohang). I think user threads are missing some code now, since ThreadPWait (but not ThreadPScheduler) was used by them. But I admit, I didn't build them either, so whether they worked or not, and whether I kept them working or not, don't know. They are never build by default. I think the problem with the encoded exit status it is just a bit "wierd", and hardly anyone would want to use it asis. The repacked value makes more sense? Slightly? Hm..how about this...? interface Uexec; <*external Uexec_WIFEXITED> PROCEDURE WIFEXITED(int status):BOOLEAN; etc. the various other macros/functions in Posix, well, at least two or three of them, the ones that access the relevant fields. Uexec.c typedef size_t BOOLEAN; /* ? safe at least, to return a full word's worth of bits */ #define TRUE 1 #define FALSE 1 BOOLEAN Uexec_WIFEEXITED(int status) { return WIFEEXITED(status) ? TRUE : FALSE; } That fits one of the molds well imho. I like what I had in Uwaitpid, but it is hard to argue for it vs. this. They are very similar. This has the advantage of only returning what is asked for. Uwaitpid had the advantage of probably being faster -- less storage efficient, but fewer function calls / roundtrips and such, since WIFEEXITED is likely a macro and Modula-3 loses the inlining. Surely not a big deal either way. Both options are very portable. Then, the rejiggering/repacking of the bits can be done portably, without regard to endiannness and without regard to the bitfield layout of the int; the bitfields can go away, leaving just the int to be unpacked by these macros-wrapped-in-functions. (I believe it is portable defined as an int but I'll check). Ok? - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3commit at elegosoft.comSubject: RE: [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 12:08:29 +0000 Hm. So I guess the point then is to return one "reasonable" integer, and"reasonable" is actually defined as (coredump << 15) | (termsig << 8) | exitcode That's the point of the repacking?and coredump and termsig are usually 0. Anyway, I don't think even this 7/1/8/16 split is specified by Posix. Right?Uwaitpid.c was a good portable method I think.It was based on the example code in online Posix docs (which you originally pointed me to). - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 22:25:25 +1100CC: m3commit at elegosoft.comSubject: Re: [M3commit] CVS Update: cm3 On 12 Jan 2009, at 21:11, Jay wrote: > relies on particular endian-ness of the status > word they return. Really, those clients should > be using proper bit-shifts and bit-masks to extract > the right values rather than some endian- dependent RECORD layout defined in Uexec Wasn't Uwaitpid.c a good portable way to do exactly that? I didn't look too closely at that. I wanted something that retained the simplicity of calling waitpid as: PROCEDURE waitpid(pid: int; VAR status: int; options: int): int; I guess it can be written in Modula-3 though, if the headers are cloned as they are. Aren't {I386,AMD64}_DARWIN broken here? I don't think so -- Uexec is still there. Besides all "my" ports, which don't define those types. Yeah yeah, all I have to do is switch on endian and I can introduce them.. But really, clients of waitpid/SchedulerPosix.WaitProcess should be prepared to shift the status return value correctly! After all, the interface doc for Process.Wait indicates that the return value is the status word. I'll see about Cygwin pthreads. Yes, it would be a more coherent solution. - Jay> Date: Mon, 12 Jan 2009 10:20:33 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 09/01/12 10:20:33> > Modified files:> cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > ThreadPWait.m3 > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > m3makefile > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > Log message:> Try to clean up mess with Process.Wait and System.Wait based on waitpid.> > Packing is now returned to Process.Wait and System.Wait where it used to be.> > Not sure if this re-packing is needed by clients, but should verify.> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at elego.de Tue Jan 13 08:03:37 2009 From: hosking at elego.de (Antony Hosking) Date: Tue, 13 Jan 2009 8:03:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113070337.ACE1E10D5D11@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 09/01/13 08:03:37 Modified files: cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosix.m3 Log message: Repair ThreadPosix.m3 as well. Forgot to do this earlier. From hosking at elego.de Tue Jan 13 08:07:56 2009 From: hosking at elego.de (Antony Hosking) Date: Tue, 13 Jan 2009 8:07:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113070756.93F3C10D5D11@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 09/01/13 08:07:56 Modified files: cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosix.m3 Log message: Fix syntax error and restore Delay constant. What about just calling Yield instead of Delay to get better performance at the expense of niceness w.r.to other processes? From jkrell at elego.de Tue Jan 13 12:06:25 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 12:06:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113110625.72EB710D5F41@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 12:06:25 Modified files: cm3/m3-libs/m3core/src/unix/ultrix-3-1.SEQUENT/: m3makefile cm3/m3-libs/m3core/src/unix/ultrix-3-1.SUN3/: m3makefile cm3/m3-libs/m3core/src/unix/ultrix-3-1.SUN386/: m3makefile cm3/m3-libs/m3core/src/unix/ultrix-3-1.UMAX/: m3makefile cm3/m3-libs/m3core/src/unix/ultrix-3-1.VAX/: m3makefile cm3/m3-libs/m3core/src/unix/sunos-4-x/: m3makefile cm3/m3-libs/m3core/src/unix/sysv-4.0/: m3makefile cm3/m3-libs/m3core/src/unix/ultrix-3-1.AP3000/: m3makefile cm3/m3-libs/m3core/src/unix/ultrix-3-1.ARM/: m3makefile cm3/m3-libs/m3core/src/unix/ultrix-3-1.DS3100/: m3makefile cm3/m3-libs/m3core/src/unix/ultrix-3-1.NEXT/: m3makefile cm3/m3-libs/m3core/src/unix/linux-libc6/: m3makefile cm3/m3-libs/m3core/src/unix/little-endian/: m3makefile cm3/m3-libs/m3core/src/unix/netbsd2-i386/: m3makefile cm3/m3-libs/m3core/src/unix/os2/: m3makefile cm3/m3-libs/m3core/src/unix/osf-1.generic/: m3makefile cm3/m3-libs/m3core/src/unix/solaris-2-x/: m3makefile cm3/m3-libs/m3core/src/unix/aix-3-2/: m3makefile cm3/m3-libs/m3core/src/unix/aix-ps2-1-2/: m3makefile cm3/m3-libs/m3core/src/unix/big-endian/: m3makefile cm3/m3-libs/m3core/src/unix/darwin-generic/: m3makefile cm3/m3-libs/m3core/src/unix/freebsd-1/: m3makefile cm3/m3-libs/m3core/src/unix/freebsd-2/: m3makefile cm3/m3-libs/m3core/src/unix/freebsd-3/: m3makefile cm3/m3-libs/m3core/src/unix/freebsd-4/: m3makefile cm3/m3-libs/m3core/src/unix/hpux-7-0/: m3makefile cm3/m3-libs/m3core/src/unix/ibm-4-3/: m3makefile cm3/m3-libs/m3core/src/unix/irix-5.2/: m3makefile cm3/m3-libs/m3core/src/unix/linux/: m3makefile cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 Removed files: cm3/m3-libs/m3core/src/unix/ultrix-3-1.SEQUENT/: Uexec.i3 cm3/m3-libs/m3core/src/unix/ultrix-3-1.SUN3/: Uexec.i3 cm3/m3-libs/m3core/src/unix/ultrix-3-1.SUN386/: Uexec.i3 cm3/m3-libs/m3core/src/unix/ultrix-3-1.UMAX/: Uexec.i3 cm3/m3-libs/m3core/src/unix/ultrix-3-1.VAX/: Uexec.i3 cm3/m3-libs/m3core/src/unix/sunos-4-x/: Uexec.i3 cm3/m3-libs/m3core/src/unix/sysv-4.0/: Uexec.i3 cm3/m3-libs/m3core/src/unix/ultrix-3-1.AP3000/: Uexec.i3 cm3/m3-libs/m3core/src/unix/ultrix-3-1.ARM/: Uexec.i3 cm3/m3-libs/m3core/src/unix/ultrix-3-1.DS3100/: Uexec.i3 cm3/m3-libs/m3core/src/unix/ultrix-3-1.NEXT/: Uexec.i3 cm3/m3-libs/m3core/src/unix/linux-libc6/: Uexec.i3 cm3/m3-libs/m3core/src/unix/little-endian/: Uexec.i3 cm3/m3-libs/m3core/src/unix/netbsd2-i386/: Uexec.i3 cm3/m3-libs/m3core/src/unix/os2/: Uexec.i3 cm3/m3-libs/m3core/src/unix/osf-1.generic/: Uexec.i3 cm3/m3-libs/m3core/src/unix/solaris-2-x/: Uexec.i3 cm3/m3-libs/m3core/src/unix/aix-3-2/: Uexec.i3 cm3/m3-libs/m3core/src/unix/aix-ps2-1-2/: Uexec.i3 cm3/m3-libs/m3core/src/unix/big-endian/: Uexec.i3 cm3/m3-libs/m3core/src/unix/darwin-generic/: Uexec.i3 cm3/m3-libs/m3core/src/unix/freebsd-1/: Uexec.i3 cm3/m3-libs/m3core/src/unix/freebsd-2/: Uexec.i3 cm3/m3-libs/m3core/src/unix/freebsd-3/: Uexec.i3 cm3/m3-libs/m3core/src/unix/freebsd-4/: Uexec.i3 cm3/m3-libs/m3core/src/unix/hpux-7-0/: Uexec.i3 cm3/m3-libs/m3core/src/unix/ibm-4-3/: Uexec.i3 cm3/m3-libs/m3core/src/unix/irix-5.2/: Uexec.i3 cm3/m3-libs/m3core/src/unix/linux/: Uexec.i3 Log message: make it portable From jkrell at elego.de Tue Jan 13 12:09:39 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 12:09:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113110939.1EEE010D5DA1@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 12:09:39 Removed files: cm3/m3-libs/m3core/src/unix/Common/: Uwaitpid.i3 Uwaitpid.c Log message: and delete these too From jkrell at elego.de Tue Jan 13 12:59:29 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 12:59:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113115929.1B8B410D5F41@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 12:59:29 Modified files: cm3/m3-libs/m3core/src/unix/Common/: m3makefile Log message: forgot to commit this (cvs commit isn't commiting anything I have to manually list files; granted, cvs diff would have shown me) From jkrell at elego.de Tue Jan 13 13:01:30 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 13:01:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113120135.1F0BD10D5F5B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 13:01:30 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Uexec.i3 Added files: cm3/m3-libs/m3core/src/unix/Common/: Uexec.c Log message: and these From jkrell at elego.de Tue Jan 13 13:22:44 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 13:22:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113122244.8FAEB714573@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 13:22:44 Modified files: cm3/m3-libs/m3core/src/win32/: WinNT.i3 Log message: fix warning on large numbers by using unsigned From jkrell at elego.de Tue Jan 13 13:28:49 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 13:28:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113122849.4C70B10D4EAA@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 13:28:49 Removed files: cm3/m3-libs/sysutils/src/POSIX/: Sysutils_DoesWaitPidYield.i3 Sysutils_Uwaitpid.c Sysutils_Uwaitpid.i3 Log message: and delete these From jkrell at elego.de Tue Jan 13 13:30:33 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 13:30:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113123036.AD5F610D5F41@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 13:30:33 Modified files: cm3/m3-sys/cminstall/src/config/: NT386.common Log message: fix copy/paste error, no effect as long as cygwin using win32 threads From jkrell at elego.de Tue Jan 13 14:47:16 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 14:47:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113134716.7367910D5FCD@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 14:47:16 Modified files: cm3/m3-libs/m3core/src/Csupport/libgcc/: libgcc.c Log message: Quash warning on Darwin about libgcc.o having no symbols, by introducing an arbitrary symbol. From jkrell at elego.de Tue Jan 13 15:20:19 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 15:20:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113142019.7A93010D5FD0@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 15:20:19 Modified files: cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 Log message: both my change and Tony's change are 'difficult' to bootstrap; cut the dependency from sysutils to newer m3core, somewhat sleazily; this should be changed as indicated once newer m3core is well established, or maybe, again, by copying code From jkrell at elego.de Tue Jan 13 15:24:05 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 15:24:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113142405.CC98710D5FD0@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 15:24:05 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Log message: fix for Darwin (10.4) From jkrell at elego.de Tue Jan 13 15:24:59 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 15:24:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113142459.7953810D5FD0@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 15:24:59 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Usignal.i3 Log message: fix line endings From jkrell at elego.de Tue Jan 13 15:33:28 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 15:33:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113143328.E9B7D10D5359@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 15:33:28 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 ThreadPThreadC.c ThreadPThreadC.i3 cm3/m3-libs/m3core/src/unix/Common/: Usignal.i3 m3makefile Removed files: cm3/m3-libs/m3core/src/unix/Common/: Usem.i3 Log message: Darwin tools didn't like these variables, something about common variables and shared/dynamic libs. Possibly merely initializing them would fix this, however there was also the nagging problem of the incorrect type declarations, which arguably could be fixed by just removing them and declaring the variables to be ints. Anyway, the solution here is /very/ portable, mechanical, and a little contorted. Uses of sem_* and sigsuspend are moved into small C wrappers. The global variables they operate on are implied at the Modula-3 level. From jkrell at elego.de Tue Jan 13 15:39:13 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 15:39:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113143913.0DC1910D5359@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 15:39:13 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: PPC_DARWIN Log message: share a bunch of code From jay.krell at cornell.edu Wed Jan 14 00:59:30 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 13 Jan 2009 23:59:30 +0000 Subject: [M3commit] waitpit In-Reply-To: <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> References: <20090112092033.2748010D5FD1@birch.elegosoft.com> <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> Message-ID: > I think "what I was missing" here is the option of changing the Process.Wait or > SchedulerPosix.WaitProcess interface to return the status bits. I don't think this > is how it was before, (which I think was implied). It looks like I added SchedulerPosix.WaitProcess only in 2008, while fixing the inefficient waitpid in libm3, so it wasn't some long standing interface, and changing it very reasonable. Had I only noticed sysutils at the time, I /might/ have thought to define it the way you did. (Still the bootstrap issue, neither WaitProcess signature is in older m3core.) - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3commit at elegosoft.comSubject: RE: waitpitDate: Tue, 13 Jan 2009 05:50:43 +0000 I think "what I was missing" here is the option of changing the Process.Wait or SchedulerPosix.WaitProcess interface to return the status bits. I don't think this is how it was before, (which I think was implied).Maybe I misread it, between returning the pid/success vs. the status word?I had added the new interface SchedulerPosix.DoesWaitPidYield, but left others asis.Now, true, I'm arguing both sides, since I did make Uerror.i3 incompatible with some clients.Exposing more information like that seems a good solution, leaving the next level down to waitpid(0) or waitpid(nohang).I think user threads are missing some code now, since ThreadPWait (but not ThreadPScheduler) was used by them. But I admit, I didn't build them either, so whether they worked or not, and whether I kept them working or not, don't know. They are never build by default. I think the problem with the encoded exit status it is just a bit "wierd", and hardly anyone would want to use it asis.The repacked value makes more sense? Slightly?Hm..how about this...? interface Uexec; <*external Uexec_WIFEXITED> PROCEDURE WIFEXITED(int status):BOOLEAN;etc. the various other macros/functions in Posix, well, at least two or three of them, theones that access the relevant fields. Uexec.c typedef size_t BOOLEAN; /* ? safe at least, to return a full word's worth of bits */ #define TRUE 1 #define FALSE 1 BOOLEAN Uexec_WIFEEXITED(int status) { return WIFEEXITED(status) ? TRUE : FALSE; } That fits one of the molds well imho.I like what I had in Uwaitpid, but it is hard to argue for it vs. this.They are very similar.This has the advantage of only returning what is asked for.Uwaitpid had the advantage of probably being faster -- less storage efficient, but fewer function calls / roundtrips and such, since WIFEEXITED is likely a macro and Modula-3 loses the inlining. Surely not a big deal either way. Both options are very portable. Then, the rejiggering/repacking of the bits can be done portably, without regard to endiannness and without regard to the bitfield layout of the int; the bitfields can go away, leaving just the int to be unpacked by these macros-wrapped-in-functions. (I believe it is portable defined as an int but I'll check). Ok? - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3commit at elegosoft.comSubject: RE: [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 12:08:29 +0000 Hm. So I guess the point then is to return one "reasonable" integer, and"reasonable" is actually defined as (coredump << 15) | (termsig << 8) | exitcode That's the point of the repacking?and coredump and termsig are usually 0. Anyway, I don't think even this 7/1/8/16 split is specified by Posix. Right?Uwaitpid.c was a good portable method I think.It was based on the example code in online Posix docs (which you originally pointed me to). - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 22:25:25 +1100CC: m3commit at elegosoft.comSubject: Re: [M3commit] CVS Update: cm3 On 12 Jan 2009, at 21:11, Jay wrote: > relies on particular endian-ness of the status > word they return. Really, those clients should > be using proper bit-shifts and bit-masks to extract > the right values rather than some endian- dependent RECORD layout defined in Uexec Wasn't Uwaitpid.c a good portable way to do exactly that? I didn't look too closely at that. I wanted something that retained the simplicity of calling waitpid as: PROCEDURE waitpid(pid: int; VAR status: int; options: int): int; I guess it can be written in Modula-3 though, if the headers are cloned as they are. Aren't {I386,AMD64}_DARWIN broken here? I don't think so -- Uexec is still there. Besides all "my" ports, which don't define those types. Yeah yeah, all I have to do is switch on endian and I can introduce them.. But really, clients of waitpid/SchedulerPosix.WaitProcess should be prepared to shift the status return value correctly! After all, the interface doc for Process.Wait indicates that the return value is the status word. I'll see about Cygwin pthreads. Yes, it would be a more coherent solution. - Jay> Date: Mon, 12 Jan 2009 10:20:33 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 09/01/12 10:20:33> > Modified files:> cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > ThreadPWait.m3 > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > m3makefile > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > Log message:> Try to clean up mess with Process.Wait and System.Wait based on waitpid.> > Packing is now returned to Process.Wait and System.Wait where it used to be.> > Not sure if this re-packing is needed by clients, but should verify.> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 14 01:25:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 14 Jan 2009 11:25:07 +1100 Subject: [M3commit] waitpit In-Reply-To: References: <20090112092033.2748010D5FD1@birch.elegosoft.com> <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> Message-ID: <164AB63E-E3CA-4E08-B15B-9F78F2B648B9@cs.purdue.edu> Yeah, that's right. I think we should still ensure that clients of Process.Wait and System.Wait don't do anything more than check the non- zero status value that they return. I suspect the packing was there to ensure that current clients were able to do that reliably (are there systems that encode non-zero successful exit status for processes?). Hmm. On 14 Jan 2009, at 10:59, Jay wrote: > > I think "what I was missing" here is the option of changing the > Process.Wait or > > SchedulerPosix.WaitProcess interface to return the status bits. > I don't think this > > is how it was before, (which I think was implied). > > It looks like I added SchedulerPosix.WaitProcess only in 2008, while > fixing the inefficient waitpid in libm3, > so it wasn't some long standing interface, and changing it very > reasonable. > Had I only noticed sysutils at the time, I /might/ have thought to > define it the way you did. > (Still the bootstrap issue, neither WaitProcess signature is in > older m3core.) > > - Jay > > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3commit at elegosoft.com > Subject: RE: waitpit > Date: Tue, 13 Jan 2009 05:50:43 +0000 > > I think "what I was missing" here is the option of changing the > Process.Wait or SchedulerPosix.WaitProcess interface to return the > status bits. I don't think this is how it was before, (which I think > was implied). > Maybe I misread it, between returning the pid/success vs. the status > word? > I had added the new interface SchedulerPosix.DoesWaitPidYield, but > left others asis. > Now, true, I'm arguing both sides, since I did make Uerror.i3 > incompatible with some clients. > Exposing more information like that seems a good solution, leaving > the next level down to waitpid(0) or waitpid(nohang). > I think user threads are missing some code now, since ThreadPWait > (but not ThreadPScheduler) was used by them. But I admit, I didn't > build them either, so whether they worked or not, and whether I kept > them working or not, don't know. They are never build by default. > > I think the problem with the encoded exit status it is just a bit > "wierd", and hardly anyone would want to use it asis. > The repacked value makes more sense? Slightly? > Hm..how about this...? > > > interface Uexec; > > <*external Uexec_WIFEXITED> PROCEDURE WIFEXITED(int status):BOOLEAN; > etc. the various other macros/functions in Posix, well, at least two > or three of them, the > ones that access the relevant fields. > > Uexec.c > typedef size_t BOOLEAN; /* ? safe at least, to return a full > word's worth of bits */ > #define TRUE 1 > #define FALSE 1 > > BOOLEAN Uexec_WIFEEXITED(int status) > { > return WIFEEXITED(status) ? TRUE : FALSE; > } > > That fits one of the molds well imho. > I like what I had in Uwaitpid, but it is hard to argue for it vs. > this. > They are very similar. > This has the advantage of only returning what is asked for. > Uwaitpid had the advantage of probably being faster -- less storage > efficient, but fewer function calls / roundtrips and such, since > WIFEEXITED is likely a macro and Modula-3 loses the inlining. Surely > not a big deal either way. Both options are very portable. > > Then, the rejiggering/repacking of the bits can be done portably, > without regard to endiannness and without regard to the bitfield > layout of the int; the bitfields can go away, leaving just the int > to be unpacked by these macros-wrapped-in-functions. (I believe it > is portable defined as an int but I'll check). > > Ok? > > - Jay > > > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3commit at elegosoft.com > Subject: RE: [M3commit] CVS Update: cm3 > Date: Mon, 12 Jan 2009 12:08:29 +0000 > > Hm. So I guess the point then is to return one "reasonable" integer, > and > "reasonable" is actually defined as > > (coredump << 15) | (termsig << 8) | exitcode > > That's the point of the repacking? > and coredump and termsig are usually 0. > > Anyway, I don't think even this 7/1/8/16 split is specified by > Posix. Right? > Uwaitpid.c was a good portable method I think. > It was based on the example code in online Posix docs (which you > originally pointed me to). > > - Jay > > > > > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 22:25:25 +1100 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > > > On 12 Jan 2009, at 21:11, Jay wrote: > > > relies on particular endian-ness of the status > > word they return. Really, those clients should > > be using proper bit-shifts and bit-masks to extract > > the right values rather than some endian- dependent RECORD layout > defined in Uexec > > Wasn't Uwaitpid.c a good portable way to do exactly that? > > I didn't look too closely at that. I wanted something that retained > the simplicity of calling waitpid as: > > PROCEDURE waitpid(pid: int; VAR status: int; options: int): int; > > I guess it can be written in Modula-3 though, if the headers are > cloned as they are. > Aren't {I386,AMD64}_DARWIN broken here? > > I don't think so -- Uexec is still there. > > Besides all "my" ports, which don't define those types. > Yeah yeah, all I have to do is switch on endian and I can introduce > them.. > > But really, clients of waitpid/SchedulerPosix.WaitProcess should be > prepared to shift the status return value correctly! After all, the > interface doc for Process.Wait indicates that the return value is > the status word. > > I'll see about Cygwin pthreads. > > Yes, it would be a more coherent solution. > > > > - Jay > > > Date: Mon, 12 Jan 2009 10:20:33 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 09/01/12 10:20:33 > > > > Modified files: > > cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > > ThreadPWait.m3 > > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > > m3makefile > > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > > > Log message: > > Try to clean up mess with Process.Wait and System.Wait based on > waitpid. > > > > Packing is now returned to Process.Wait and System.Wait where it > used to be. > > > > Not sure if this re-packing is needed by clients, but should verify. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 14 00:45:23 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 14 Jan 2009 10:45:23 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20090113142019.7A93010D5FD0@birch.elegosoft.com> References: <20090113142019.7A93010D5FD0@birch.elegosoft.com> Message-ID: <034D3CBF-C0D2-46F6-9F82-1DA6737D1A7B@cs.purdue.edu> I don't see what's difficult to bootstrap here. Why do you need to build against old m3core? On 13 Jan 2009, at 15:20, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/01/13 15:20:19 > > Modified files: > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 > > Log message: > both my change and Tony's change are 'difficult' to bootstrap; cut > the dependency from sysutils to newer m3core, somewhat sleazily; > this should be changed as indicated once newer m3core is well > established, or maybe, again, by copying code From jay.krell at cornell.edu Wed Jan 14 03:42:42 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 14 Jan 2009 02:42:42 +0000 Subject: [M3commit] waitpid In-Reply-To: <164AB63E-E3CA-4E08-B15B-9F78F2B648B9@cs.purdue.edu> References: <20090112092033.2748010D5FD1@birch.elegosoft.com> <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> <164AB63E-E3CA-4E08-B15B-9F78F2B648B9@cs.purdue.edu> Message-ID: > (are there systems that encode non-zero successful exit status for processes?). Hmm. I don't know, but I read that Posix says something like "zero is zero". Like, if child process calls exit(0) or _exit(0), then the full int status will be 0 (even if only 8 bits of exit's parameter are preserved). I thought I read long ago that VMS inverted the meaning, but then C development libraries had to reinvert it for source compatibility. Maybe I'll know better when I bring Modula-3 on VMS back. :) Whatever I was reading gave EXIT_SUCCESS and EXIT_FAILURE as the only portable values...but certainly there is plenty of hardcoded exit(0), thus the theoretically compat hacks. Nevertheless, a "rich" exit code has its uses. Like "number of files copies" or such various common conditions. But maybe we don't care. > I suspect the packing was there to ensure that current clients were able to do that reliably I don't follow. Do you mean, like, guarding against "zero is not zero", such as, like, the filler being "random"? I'll try poke around. In the meantime, see Uexec.RepackStatus that I put in? And definitely look at what I did to ThreadPThread. Perhaps too contorted. Perhaps declare ackSem and mask as arbibrary int and the relevant functions taking ADDRESS, and see if initializing the variables with { 0 } will fix the problem I had on Darwin. Or, if not, I can put in accessor functions for the globals, leaving them static. That'll surely work, didn't think of it till just now. ps: The Darwin PPC 10.4 dylibs don't have make/get/set/swapcontext either. I think I checked both System.dylib and libc.dylib. A "hybrid" where some platforms use setjmp/long and some use context is probably ok. A larger issue here..another thread... - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Wed, 14 Jan 2009 11:25:07 +1100CC: m3commit at elegosoft.comSubject: Re: [M3commit] waitpit Yeah, that's right. I think we should still ensure that clients of Process.Wait and System.Wait don't do anything more than check the non-zero status value that they return. I suspect the packing was there to ensure that current clients were able to do that reliably (are there systems that encode non-zero successful exit status for processes?). Hmm. On 14 Jan 2009, at 10:59, Jay wrote: > I think "what I was missing" here is the option of changing the Process.Wait or > SchedulerPosix.WaitProcess interface to return the status bits. I don't think this > is how it was before, (which I think was implied). It looks like I added SchedulerPosix.WaitProcess only in 2008, while fixing the inefficient waitpid in libm3,so it wasn't some long standing interface, and changing it very reasonable.Had I only noticed sysutils at the time, I /might/ have thought to define it the way you did.(Still the bootstrap issue, neither WaitProcess signature is in older m3core.) - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3commit at elegosoft.comSubject: RE: waitpitDate: Tue, 13 Jan 2009 05:50:43 +0000I think "what I was missing" here is the option of changing the Process.Wait or SchedulerPosix.WaitProcess interface to return the status bits. I don't think this is how it was before, (which I think was implied).Maybe I misread it, between returning the pid/success vs. the status word?I had added the new interface SchedulerPosix.DoesWaitPidYield, but left others asis.Now, true, I'm arguing both sides, since I did make Uerror.i3 incompatible with some clients.Exposing more information like that seems a good solution, leaving the next level down to waitpid(0) or waitpid(nohang).I think user threads are missing some code now, since ThreadPWait (but not ThreadPScheduler) was used by them. But I admit, I didn't build them either, so whether they worked or not, and whether I kept them working or not, don't know. They are never build by default. I think the problem with the encoded exit status it is just a bit "wierd", and hardly anyone would want to use it asis.The repacked value makes more sense? Slightly?Hm..how about this...? interface Uexec; <*external Uexec_WIFEXITED> PROCEDURE WIFEXITED(int status):BOOLEAN;etc. the various other macros/functions in Posix, well, at least two or three of them, theones that access the relevant fields. Uexec.c typedef size_t BOOLEAN; /* ? safe at least, to return a full word's worth of bits */ #define TRUE 1 #define FALSE 1 BOOLEAN Uexec_WIFEEXITED(int status) { return WIFEEXITED(status) ? TRUE : FALSE; } That fits one of the molds well imho.I like what I had in Uwaitpid, but it is hard to argue for it vs. this.They are very similar.This has the advantage of only returning what is asked for.Uwaitpid had the advantage of probably being faster -- less storage efficient, but fewer function calls / roundtrips and such, since WIFEEXITED is likely a macro and Modula-3 loses the inlining. Surely not a big deal either way. Both options are very portable. Then, the rejiggering/repacking of the bits can be done portably, without regard to endiannness and without regard to the bitfield layout of the int; the bitfields can go away, leaving just the int to be unpacked by these macros-wrapped-in-functions. (I believe it is portable defined as an int but I'll check). Ok? - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3commit at elegosoft.comSubject: RE: [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 12:08:29 +0000Hm. So I guess the point then is to return one "reasonable" integer, and"reasonable" is actually defined as (coredump << 15) | (termsig << 8) | exitcode That's the point of the repacking?and coredump and termsig are usually 0. Anyway, I don't think even this 7/1/8/16 split is specified by Posix. Right?Uwaitpid.c was a good portable method I think.It was based on the example code in online Posix docs (which you originally pointed me to). - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 22:25:25 +1100CC: m3commit at elegosoft.comSubject: Re: [M3commit] CVS Update: cm3 On 12 Jan 2009, at 21:11, Jay wrote: > relies on particular endian-ness of the status > word they return. Really, those clients should > be using proper bit-shifts and bit-masks to extract > the right values rather than some endian- dependent RECORD layout defined in Uexec Wasn't Uwaitpid.c a good portable way to do exactly that? I didn't look too closely at that. I wanted something that retained the simplicity of calling waitpid as: PROCEDURE waitpid(pid: int; VAR status: int; options: int): int; I guess it can be written in Modula-3 though, if the headers are cloned as they are. Aren't {I386,AMD64}_DARWIN broken here? I don't think so -- Uexec is still there. Besides all "my" ports, which don't define those types. Yeah yeah, all I have to do is switch on endian and I can introduce them.. But really, clients of waitpid/SchedulerPosix.WaitProcess should be prepared to shift the status return value correctly! After all, the interface doc for Process.Wait indicates that the return value is the status word. I'll see about Cygwin pthreads. Yes, it would be a more coherent solution. - Jay> Date: Mon, 12 Jan 2009 10:20:33 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 09/01/12 10:20:33> > Modified files:> cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > ThreadPWait.m3 > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > m3makefile > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > Log message:> Try to clean up mess with Process.Wait and System.Wait based on waitpid.> > Packing is now returned to Process.Wait and System.Wait where it used to be.> > Not sure if this re-packing is needed by clients, but should verify.> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jan 14 03:48:48 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 14 Jan 2009 02:48:48 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <034D3CBF-C0D2-46F6-9F82-1DA6737D1A7B@cs.purdue.edu> References: <20090113142019.7A93010D5FD0@birch.elegosoft.com> <034D3CBF-C0D2-46F6-9F82-1DA6737D1A7B@cs.purdue.edu> Message-ID: I didn't check for PPC_DARWIN has Tinderbox outputs, so I was bootstrapping from the latest release -- 5.5. If I was desparate I could bootstrap cross. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Wed, 14 Jan 2009 10:45:23 +1100> CC: m3commit at elegosoft.com> Subject: Re: [M3commit] CVS Update: cm3> > I don't see what's difficult to bootstrap here. Why do you need to > build against old m3core?> > On 13 Jan 2009, at 15:20, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 09/01/13 15:20:19> >> > Modified files:> > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3> >> > Log message:> > both my change and Tony's change are 'difficult' to bootstrap; cut > > the dependency from sysutils to newer m3core, somewhat sleazily; > > this should be changed as indicated once newer m3core is well > > established, or maybe, again, by copying code> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 14 05:34:43 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 14 Jan 2009 15:34:43 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20090113142019.7A93010D5FD0@birch.elegosoft.com> <034D3CBF-C0D2-46F6-9F82-1DA6737D1A7B@cs.purdue.edu> Message-ID: There used to PPC_DARWIN Tinderbox, but my machines at home are packed up in my basement... You should be able to use the bootstrap files from ftp://ftp.cs.purdue.edu/m3/PPC_DARWIN . I have AMD64_DARWIN there too. On 14 Jan 2009, at 13:48, Jay wrote: > I didn't check for PPC_DARWIN has Tinderbox outputs, so I was > bootstrapping from the latest release -- 5.5. > If I was desparate I could bootstrap cross. > > - Jay > > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Wed, 14 Jan 2009 10:45:23 +1100 > > CC: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > I don't see what's difficult to bootstrap here. Why do you need to > > build against old m3core? > > > > On 13 Jan 2009, at 15:20, Jay Krell wrote: > > > > > CVSROOT: /usr/cvs > > > Changes by: jkrell at birch. 09/01/13 15:20:19 > > > > > > Modified files: > > > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 > > > > > > Log message: > > > both my change and Tony's change are 'difficult' to bootstrap; cut > > > the dependency from sysutils to newer m3core, somewhat sleazily; > > > this should be changed as indicated once newer m3core is well > > > established, or maybe, again, by copying code > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Wed Jan 14 10:34:21 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jan 2009 10:34:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090114093421.6DE5A10D5EC8@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/14 10:34:20 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Uexec.c Unix.i3 Ustat.i3 m3makefile Added files: cm3/m3-libs/m3core/src/unix/Common/: Uconstants.c Removed files: cm3/m3-libs/m3core/src/unix/Common/: Uerror.c Log message: Move all constants-implemented-as-variables to one file dedicated to them -- Uconstants.c. This way we don't have to keep picking up nickels and dimes on platforms that need to statically link to them (cygwin), and we keep functions and data separate. Not all of the constants in this file are yet active, but they are ok to be there ahead of time. More will migrate here soon. We should perhaps rely on Posix mandating some of the values, or perhaps that some of the values happen to be identical on all platforms, and then make them consts, or we can just play it very safe and err toward making them variables. As well we will look into removing their uses behind C wrappers. From jkrell at elego.de Wed Jan 14 10:36:24 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jan 2009 10:36:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090114093625.1A75D10D5EC8@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/14 10:36:24 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Uconstants.c Log message: add more #includes so it compiles From jkrell at elego.de Mon Jan 19 06:14:26 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 6:14:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119051426.3D5A2714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 06:14:26 Added files: cm3/scripts/: config.c Log message: something like autoconf; sniffs a bunch about a system, though not yet for example the pthread initializers or the exact layout of struct tm From jkrell at elego.de Mon Jan 19 06:34:40 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 6:34:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119053442.3656E10D5F16@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 06:34:40 Modified files: cm3/scripts/: config.c Log message: some cleanup and improvements From jkrell at elego.de Mon Jan 19 10:43:40 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 10:43:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119094340.2D0CB714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 10:43:40 Modified files: cm3/scripts/: config.c Log message: demonstrate start of 'fully dynamic struct reconstitution', at least for structs composed of particular types; this could be developed into a more complete struct declaration cloner, but I don't think we'll need it From jkrell at elego.de Mon Jan 19 11:03:19 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 11:03:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119100319.D1009714573@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 11:03:19 Modified files: cm3/scripts/: config.c Log message: output struct linger, though again, probably will just use more C wrappers instead From jkrell at elego.de Mon Jan 19 11:19:12 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 11:19:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119101912.850EF714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 11:19:12 Modified files: cm3/scripts/: config.c Log message: support CC and CFLAGS environment variables, not clear if we should still try -lpthread and -Werror, or if we should split the 'possible' array between binary name and flags, and then probe only whichever is not an environment variable; really should support command line switches too but none of this likely matters much From jkrell at elego.de Mon Jan 19 12:11:28 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 12:11:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119111128.61BBA10D5F2E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 12:11:28 Modified files: cm3/m3-comm/tcp/src/POSIX/: IP.m3 Log message: let Unetdb.TRY_AGAIN, NO_RECOVERY, NO_ADDRESS be constant variables initialized in C instead of constants, for easier portability; alternatively, move this lone use to C From jkrell at elego.de Mon Jan 19 12:16:10 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 12:16:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119111610.827C4714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 12:16:10 Modified files: cm3/m3-comm/tcp/src/POSIX/: TCP.m3 Log message: convert a few tabs to spaces From jkrell at elego.de Mon Jan 19 14:05:50 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 14:05:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119130550.E9B272200076@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 14:05:50 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: ProcessCygwin.m3 Log message: fix newlines From jkrell at elego.de Mon Jan 19 14:09:15 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 14:09:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119130917.67F06744003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 14:09:15 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: FSPosix.m3 FilePosix.m3 SocketPosix.m3 Log message: allow for more constants to be constant variables initialized in C to reduce header cloning From jkrell at elego.de Mon Jan 19 14:09:39 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 14:09:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119130940.64A5810D4C64@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 14:09:39 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 Log message: allow for more constants to be constant variables initialized in C to reduce header cloning From jkrell at elego.de Mon Jan 19 14:31:32 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 14:31:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119133133.3C1CF10D5ECA@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 14:31:32 Modified files: cm3/m3-libs/m3core/src/C/NT386/: Csetjmp.i3 Log message: fix newlines From jkrell at elego.de Mon Jan 19 14:32:45 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 14:32:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119133246.059EC72575C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 14:32:45 Modified files: cm3/m3-libs/m3core/src/C/NT386/: Csetjmp.i3 Log message: Don't trash the stack on Cygwin when using pthreads; the usual suspect, how did I miss it..? From jkrell at elego.de Mon Jan 19 14:40:43 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 14:40:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119134043.977C610D5ECA@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 14:40:43 Modified files: cm3/m3-libs/m3core/src/thread/WIN32/: m3makefile Log message: fix NT386; maybe more surgery here once Cygwin uses pthreads From jkrell at elego.de Mon Jan 19 14:47:15 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 14:47:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119134715.2B80410D5F14@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 14:47:15 Modified files: cm3/scripts/python/: pylib.py Log message: verbosity tweaks From jkrell at elego.de Mon Jan 19 15:59:04 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 15:59:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119145904.4816F10D5F14@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 15:59:04 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Uconstants.c Log message: Prepare to move a bunch of constants to constant variables. Content can be added here ahead of the use, assuming there are no global namespace clashes. Also mechanize some of the tedium here. From jkrell at elego.de Mon Jan 19 16:03:29 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 16:03:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119150329.D00582200008@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 16:03:29 Removed files: cm3/m3-libs/m3core/src/unix/Common/: Uerror.i3.cpp Uutsname.i3.cpp cm3/m3-libs/m3core/src/unix/cygwin/: Unix.i3.cpp Utypes.i3.cpp 1.cmd cm3/m3-libs/m3core/src/unix/openbsd-common/: 1.cpp 1.sh Log message: delete files that used to be used to help clone headers but which are no longer used since other better tactics have been adopted From jkrell at elego.de Mon Jan 19 16:05:21 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 16:05:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119150521.6ED3D10D5F14@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 16:05:21 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Uexec.i3 Unix.i3 UnixC.c Ustat.i3 Log message: Fix newlines. From jkrell at elego.de Mon Jan 19 16:57:22 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 16:57:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119155722.BD24710D5F30@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 16:57:22 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile cm3/m3-libs/m3core/src/unix/Common/: Uconstants.c Uexec.c Unetdb.i3 Unix.i3 Upthread.i3 Uresource.i3 Usignal.i3 Usocket.i3 Ustat.i3 Utime.i3 Utypes.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 m3makefile cm3/m3-libs/m3core/src/unix/freebsd-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 cm3/m3-sys/cminstall/src/config/: NT386.common Removed files: cm3/m3-libs/m3core/src/unix/cygwin/: 1.c Uerror.i3 Usignal.i3 Usignal.i3.c Ustat.i3 cm3/m3-libs/m3core/src/unix/linux-sparc/: Usignal.i3 Usocket.i3 m3makefile Log message: add Cygwin Upthread support, to be used very soon move a lot of constants out of cloned headers and into constant variables in C Upthread.i3 remove commented out pthread_mutexattr_t, pthread_condattr_t for now, we always pass NULL destructor_t is always the same start_routine_t is always the same move PTHREAD_MUTEX_INITIALIZER, PTHREAD_COND_INITIALIZER to be constant variables in C Unix.i3 move constants to constant C variables: O_RDONLY O_RDWR O_CREAT O_EXCL O_TRUNC O_NONBLOCK Usignal.i3: move constants to constant C variables: SIGINT SIGKILL Usocket.i3: move constants to constant C variables: SOCK_STREAM SOCK_DGRAM SO_REUSEADDR SO_KEEPALIVE SO_LINGER SOL_SOCKET AF_INET MSG_PEEK Utypes.i3: clock_t is never used; remove it Uresource.i3: move constant RUSAGE_SELF to constant C variable Unetdb.i3 move constants to constant C variables: TRY_AGAIN NO_RECOVERY NO_ADDRESS as part of this then, we can delete linux-sparc and some cygwin files, leaving only Usysdep.i3 in openbsd-common, cygwin, linux-common, freebsd-common From jkrell at elego.de Mon Jan 19 17:01:33 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 17:01:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119160134.05AE910D5F74@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 17:01:33 Modified files: cm3/m3-libs/m3core/src/unix/Common/: m3makefile Log message: forgot this From jkrell at elego.de Mon Jan 19 17:04:03 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 17:04:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119160403.4037D10D5F74@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 17:04:03 Modified files: cm3/m3-libs/m3core/src/runtime/: m3makefile cm3/m3-libs/m3core/src/runtime/common/: m3makefile cm3/m3-libs/m3core/src/thread/: m3makefile cm3/m3-libs/m3core/src/thread/WIN32/: m3makefile Removed files: cm3/m3-libs/m3core/src/thread/WIN32/: SchedulerPosix.m3 Log message: Switch NT386GNU (aka I386_CYGWIN) to use pthreads. From jkrell at elego.de Mon Jan 19 17:11:30 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 17:11:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119161130.826B710D5F74@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 17:11:30 Modified files: cm3/m3-libs/m3core/src/thread/WIN32/: ThreadWin32.m3 Log message: go back to version 26 now that Cygwin uses pthreads From jkrell at elego.de Mon Jan 19 17:12:59 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 17:12:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119161259.6223310D5F74@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 17:12:59 Modified files: cm3/m3-libs/m3core/src/thread/WIN32/: m3makefile ThreadWin32.m3 Removed files: cm3/m3-libs/m3core/src/thread/WIN32/: ThreadInternal.i3 Log message: finish cleanup now that cygwin uses pthreads -- remove dummy SchedulerPosix implementation From jkrell at elego.de Mon Jan 19 17:20:10 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 17:20:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119162010.6BEC110D5F74@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 17:20:10 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Utime.i3 Log message: fix -- was missing int import (had copied changes across source trees..) From jkrell at elego.de Mon Jan 19 17:37:09 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 17:37:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119163709.583C510D5F74@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 17:37:09 Added files: cm3/m3-libs/m3core/src/runtime/POSIX/: RTProcessPosixC.c RTProcessPosixC.i3 Log message: prepare to remove Uresource.i3; once confirmed this is the only user From jkrell at elego.de Mon Jan 19 17:38:38 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 17:38:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119163838.26B0A714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 17:38:38 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Utime.i3 Log message: oops From jkrell at elego.de Mon Jan 19 23:37:09 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 23:37:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119223710.01AD7714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 23:37:09 Modified files: cm3/scripts/python/: make-dist.py Log message: make-dist needs to copy Uerror.obj to bootstrap cygwin distribution; take hand.obj while at it (lib/*.obj) From jkrell at elego.de Mon Jan 19 23:57:53 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 23:57:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119225753.92E8B10D5F31@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 23:57:53 Modified files: cm3/scripts/python/: make-dist.py Log message: pylib.py doesn't filter packages when they are a function parameter, only if they are on the command line; this should fix filtering out of serial on cygwin in make-dist From jay.krell at cornell.edu Tue Jan 20 06:40:07 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 20 Jan 2009 05:40:07 +0000 Subject: [M3commit] FW: [M3devel] move to version 5.7.1? In-Reply-To: <4974CB61.1E75.00D7.1@scires.com> References: <4974CB61.1E75.00D7.1@scires.com> Message-ID: [was truncated] ---------------------------------------- > From: jay.krell at cornell.edu > To: rcoleburn at scires.com; m3devel at elegosoft.com > Subject: RE: [M3devel] move to version 5.7.1? > Date: Tue, 20 Jan 2009 02:28:07 +0000 > > > I meant, can we update the version stamp in the compiler. > Nothing about releases or what not. > But I'll take some of the bait. :) > > > My archives are already pretty easy to use, but need a short readme. > > > HP-UX is not yet supported, but will be fairly soon, maybe this week. > 64bit first, this week, then 32bit, by end of next week? > (HP-UX also runs on IA64 btw, but I couldn't get my hardware to boot > my OS, maybe too old OS, maybe need to fiddle with EFI console settings. > I will be doing IA64_LINUX before long. IA64_FREEBSD also wouldn't boot > for me.) > > > Where is the line between "free Microsoft tools" and "free Python"? > > > Python is NOT needed to build cm3, just as bash is not needed. > > > There are VERY handy scripts for doing so, in both languages. > They are just slightly elaborate ways to cd around and run cm3. > > > I know, I know..they are each line crossing, everything I have to > install is a line. If it was just "free Python" and no need for "free Microsoft", > that would be similar as just "free Microsoft". And "free Microsoft" > is higher quality and more trusted than "free Python", and, clearly, > simply more necessary, unless you use Cygwin. > > > Cmd is an awful language for nearly any purpose. > Please don't ask me to support any cmd files. > > > Maybe I will rewrite the automation in JScript. > It is a half decent language and works plenty well for command line automation. > It is been "in the OS" for many years, probably at least since Windows 2000, and > with any install of Internet Explorer. > > > But really..you know..all the Python I write...is somewhat of an indictment > of either Modula-3 or myself -- I don't "like" Modula-3 enough to write much > of anything in it.. That is..these "scripts" perhaps should be written in Modula-3. > > > Or maybe actually in Quake? > Quake is kind of limited though. > Maybe with the updates though that Olaf made? > I'll think about it. > > > The system is "easier" to build from a "current" system than from an "older" system. > upgrade.sh and upgrade.py work with either. > If your system is already current, you can just build in dependency order. > If your system is not current, you first build "just the compiler", in dependency > order, but skipping and m3core, libm3. Or you possibly hack them slightly. > (Btw Tony there are few other instances of LONGINT in m3core than the one, but not many.) > > > Most of this confusion is probably only for people that build the system. > As well, maybe it could be reduced by just having an "output root" > like I've said, but I know that'd be disruptive. > > > The archives I upload are not bad. > You just extract them, set $PATH, install Python, get/install a > C compiler and linker and runtime (either Cygwin or Microsoft) and go. > > > I think they are better than the cminstall-based ones. > > > I am not likely to get around to much additional polish. > > > > - Jay > > > > ________________________________ >> Date: Mon, 19 Jan 2009 18:50:40 -0500 >> From: rcoleburn at scires.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] move to version 5.7.1? >> >> >> >> >> >> >> >> Jay et al: >> >> >> >> I have not updated any of my cm3 code base since I released my last application to my customer in late 3Q2008. >> >> >> >> Based on all the activity, I don't think I want to do an update until we've decided to make a new release. This decision should be based primarily on stability of the code base across platforms. >> >> >> >> I can backup my cm3 tree, update to latest code, and run tests on Windows XP using my current apps if that would be helpful. Let me know. Also, I may be able to do some tests on HP-UX if that platform is supported. In addition, I also now have access to a Solaris box. >> >> >> >> One of the things I want to do for the next release is to provide detailed documentation on how to install cm3 on Windows using just the tools that comes with Windows or that are available free from Microsoft. I've already got a good start on this, but will want to get input on the exact order of package builds and which have to be repeated when. >> >> >> >> My idea is that we should have a minimal install archive for Windows (NT386) available from which the "customer" (end-user) can build all of the supported packages in the correct order, including rebuilding the base/core cm3 to prove his system is fully functional. On Windows, the build would be handled via .CMD files and not require python or anything else not supplied with Windows or free from Microsoft. >> >> >> >> I also want "us" to give explicit, documented, definitions of the terms "build", "ship", "clean", "spotless", etc. etc. that are used in various scripts et al and make these consistent. We also need to have good documentation on all the pragmas, environment variables, options, and command line switches that CM3 and CM3IDE recognize. I believe a number of these currently exist that are not well-known or properly documented. >> >> >> >> IMO, this next release needs to be as professional as possible and provide end users (customers) with the best possible experience in terms of ease of installation and use. >> >> >> >> I'll help as much as I can. >> >> >> >> Regards, >> >> Randy Coleburn >> >>>>> Jay 1/19/2009 5:39 PM>>> >> >> Should we move to move version 5.7.1? >> >> To mark the new year, and NT386GNU defaulting to pthreads (I'm thinking I should go back and make it a command line option, it's very very easy). >> >> Just edit two lines in sysinfo.sh and everything keeps working, right? >> >> - Jay From jkrell at elego.de Tue Jan 20 12:57:25 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 12:57:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120115725.81A1910D5DA0@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 12:57:25 Modified files: cm3/m3-libs/m3core/src/runtime/POSIX/: RTProcessPosix.m3 m3makefile cm3/m3-libs/m3core/src/unix/Common/: Uconstants.c m3makefile cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 Added files: cm3/m3-libs/m3core/src/unix/Common/: Utermio.i3 Removed files: cm3/m3-libs/m3core/src/unix/Common/: Uresource.i3 Log message: Remove only Uresource.i3 client, and then Uresource.i3 itself. Add Utermio.i3 so Cygwin can use Posix serial, which does at least compile. There's some chance this would work for other platforms too, at the cost of defining Usysdep.struct_termios and Usysdep.speed_t. For now it is #if __CYGWIN__ in Uconstant.c though. From jkrell at elego.de Tue Jan 20 12:58:15 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 12:58:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120115815.A338610D5DA0@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 12:58:15 Modified files: cm3/m3-comm/serial/src/: m3makefile cm3/m3-comm/serial/src/POSIX/: SerialPort.m3 Log message: Switch some "CONST" to "VAR" to be compatible with constants implemented as constant variables in C. Switch Cygwin to use Posix implementation. It at least compiles and links. From jkrell at elego.de Tue Jan 20 12:59:27 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 12:59:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120115927.3824710D5DA0@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 12:59:27 Modified files: cm3/scripts/python/: pylib.py Log message: The HAVE_SERIAL filtering was still not working..remove the block on Cygwin in favor of..Cygwin has termios.h, maybe it works. From jkrell at elego.de Tue Jan 20 13:37:30 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 13:37:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120123730.E01CF10D5DA0@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 13:37:30 Modified files: cm3/m3-libs/m3core/src/time/POSIX/: DatePosix.m3 m3makefile cm3/m3-libs/m3core/src/unix/solaris-2-x/: Utime.i3 Log message: Switch the "clock" parameters in ctime_r, localtime_r, gmtime_r from long_star requiring an unsafe ADR to READONLY. VAR would also be reasonable, but they are const in C so READONLY slightly better. Might as well switch the output parameter to VAR instead of "star"? (Would be nice to change this code such as to avoid declaring sysdep struct tm..) Switch Cygwin from DateLinux to DatePosix. Note that DateLinux is dead, it is only used by Linux 1.x. DateBsd is the overwhelmingly used one, except Cygwin and Solaris. It corresponds to having gmtoff and zone at the end of struct tm. DatePosix vs. DateLinux uses the "_r" functions instead of a lock. (Where do they store the zone string, in BSD versions?) From jkrell at elego.de Tue Jan 20 14:06:07 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 14:06:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120130608.20EFA2200095@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 14:06:07 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Uconstants.c cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/freebsd-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 Log message: Crack the Modula-3 renaming code: MSETUID <=> S_ISUID MSETGID <=> S_ISGID MSTICKY <=> S_ISVTX Now that I figured that out, make them portable too, and give Cygwin its values (not sure they do anything there; the ISVTX feature is a bit in executable headers, not the file system, and setuid/setgid don't exist as far as I know, but Interix apparently offers it somehow). (See also how Unix.MROWNER == Ustat.S_IREAD == S_IRUSR, if I got those right..) From jkrell at elego.de Tue Jan 20 14:34:57 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 14:34:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120133458.1356910D5C54@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 14:34:57 Modified files: cm3/scripts/: config.c Log message: collect information about mode_t, struct timeval, let use -DCC when building it, and it will use that, cover up annoying gcc warning about -lpthread when only compiling From jkrell at elego.de Tue Jan 20 14:48:50 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 14:48:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120134850.788E310D5C54@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 14:48:50 Modified files: cm3/scripts/: config.c Log message: fix From jkrell at elego.de Tue Jan 20 15:24:18 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 15:24:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120142418.966A710D5C54@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 15:24:18 Modified files: cm3/m3-libs/m3core/src/Csupport/: m3makefile cm3/m3-libs/m3core/src/float/: m3makefile cm3/m3-libs/m3core/src/runtime/: m3makefile cm3/m3-libs/m3core/src/runtime/common/: m3makefile cm3/m3-libs/m3core/src/unix/: m3makefile cm3/m3-libs/m3core/src/unix/Common/: m3makefile Added files: cm3/m3-libs/m3core/src/unix/hpux-common/: Usysdep.i3 m3makefile Log message: Some PA32_HPUX and PA64_HPUX support, work in progress. From jkrell at elego.de Tue Jan 20 20:11:58 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 20:11:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120191158.A9158714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 20:11:58 Modified files: cm3/scripts/python/: pylib.py Log message: root around more for windows.h so I don't have to switch environment From jkrell at elego.de Tue Jan 20 20:17:46 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 20:17:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120191746.D053810D4EAA@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 20:17:46 Modified files: cm3/scripts/: config.c Log message: socklent_t, sigsuspend, always add a particular prefix From jkrell at elego.de Tue Jan 20 20:27:50 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 20:27:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120192750.919D410D4EAA@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 20:27:50 Removed files: cm3/scripts/: config.c Log message: make directory (cvs crashing again for multifile commit From jkrell at elego.de Tue Jan 20 20:28:00 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 20:28:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120192800.A9E0A10D4EAA@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 20:28:00 Added files: cm3/scripts/config/: config.c Log message: make directory (cvs crashing again for multifile commit) From jkrell at elego.de Tue Jan 20 20:42:09 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 20:42:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120194209.8672F714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 20:42:09 Added files: cm3/scripts/config/: mode.c sigsuspend.c time.c Log message: experiment with smaller programs From jkrell at elego.de Tue Jan 20 21:21:55 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 21:21:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120202155.ACE7010D4EAA@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 21:21:55 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile cm3/m3-libs/m3core/src/unix/Common/: m3makefile Added files: cm3/m3-libs/m3core/src/unix/Common/: Uutmp.i3 Removed files: cm3/m3-libs/m3core/src/unix/Uutmp1/: m3makefile Uutmp.i3 Log message: move Uutmp1 to Common From jkrell at elego.de Tue Jan 20 22:04:15 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 22:04:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120210415.333EE714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 22:04:15 Modified files: cm3/scripts/config/: config.c Log message: need to check that which is in common also, not just determine what is sysdep From jkrell at elego.de Tue Jan 20 22:08:36 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 22:08:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120210836.E0491714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 22:08:36 Modified files: cm3/scripts/config/: config.c Log message: should check function signatures too -- ultimately this should probably be output by cm3 rather than tediously maintain parallel content From jkrell at elego.de Tue Jan 20 22:12:03 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 22:12:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120211203.C0BF1714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 22:12:03 Modified files: cm3/scripts/config/: config.c Log message: fix gcc -Wall warnings -- portable and warning-free is difficult From rodney at elego.de Tue Jan 20 22:34:52 2009 From: rodney at elego.de (Rodney M. Bates) Date: Tue, 20 Jan 2009 22:34:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120213452.1CFB8714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: rodney at birch. 09/01/20 22:34:52 Modified files: cm3/m3-sys/m3gdb/gdb/gdb/: m3-util.c Log message: Fix two bugs in accessing open array dope. From jkrell at elego.de Tue Jan 20 22:35:49 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 22:35:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120213549.5A6EB714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 22:35:49 Modified files: cm3/m3-libs/libm3/src/random/: m3makefile Log message: PA32_HPUX, PA64_HPUX From jkrell at elego.de Tue Jan 20 22:37:26 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 22:37:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120213726.7D9F3714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 22:37:26 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: m3makefile SocketPosix.m3 Log message: reduce dependency of libm3 on list of supported platforms -- fewer errors when building new runtime with old compiler; elimination will come later, OSConfigPosix.m3 is the other file that needs work, and fixing it will also make it more optimal, it doesn't need to carry all the strings From jkrell at elego.de Tue Jan 20 22:40:44 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 22:40:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120214044.7D324714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 22:40:44 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: m3makefile Log message: fix incrementality -- don't recompile and relink for every run, only if the file changes From jkrell at elego.de Tue Jan 20 22:57:18 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 22:57:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120215718.60101714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 22:57:18 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: OSConfigPosix.m3 SocketPosix.m3 m3makefile Log message: Elminate the other dependency by libm3 on the list of supported platforms, and namespacify the previous one. m3core still depends on the list. From jkrell at elego.de Tue Jan 20 23:28:20 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 23:28:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120222820.D9AD710D4EAA@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 23:28:20 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Log message: fix get_altzone for Solaris From jkrell at elego.de Tue Jan 20 23:36:46 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 23:36:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120223646.12E0110D5D54@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 23:36:46 Modified files: cm3/scripts/config/: config.c Log message: fix for Solaris From jkrell at elego.de Tue Jan 20 23:47:40 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 23:47:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120224740.6303C10D5F2F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 23:47:40 Added files: cm3/m3-libs/m3core/src/unix/solaris-common/: Usysdep.i3 m3makefile Log message: add first try at Solaris Usysdep, should be double checked (config.c doesn't report MAX_FDSET for example); only checked on 32bit and 64bit SPARC, not x86/AMD64 From jkrell at elego.de Tue Jan 20 23:52:50 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 23:52:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120225250.7B1E0714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 23:52:50 Modified files: cm3/m3-libs/m3core/src/unix/solaris-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/hpux-common/: Usysdep.i3 Log message: fixup imports From jkrell at elego.de Tue Jan 20 23:53:11 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 23:53:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120225311.36DD3714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 23:53:11 Modified files: cm3/m3-libs/m3core/src/unix/hpux-common/: Usysdep.i3 Log message: fixup imports From jkrell at elego.de Wed Jan 21 16:25:14 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jan 2009 16:25:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090121152514.748DE72575B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/21 16:25:13 Modified files: cm3/m3-libs/m3core/src/runtime/AMD64_DARWIN/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/FreeBSD4/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/I386_DARWIN/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/LINUXLIBC6/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/NT386GNU/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/PPC_DARWIN/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/SOLgnu/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/SOLsun/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/common/: RTMachine.i3 cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 ThreadPThreadC.c ThreadPThreadC.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/freebsd-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/hpux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/solaris-common/: Usysdep.i3 Log message: slightly easier porting wrt SIG_SUSPEND From jkrell at elego.de Wed Jan 21 16:30:44 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jan 2009 16:30:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090121153046.49F5110D5F31@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/21 16:30:44 Modified files: cm3/m3-libs/m3core/src/runtime/FreeBSD4/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/LINUXLIBC6/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/SOLgnu/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/SOLsun/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTMachine.i3 Log message: fix warnings by removing IMPORT of Usignal From jkrell at elego.de Wed Jan 21 16:32:59 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jan 2009 16:32:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090121153300.3A56110D5F7B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/21 16:32:59 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: m3makefile Log message: remove a few spaces that make a critical difference -- PPC_LINUX was broken From jkrell at elego.de Wed Jan 21 16:57:55 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jan 2009 16:57:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090121155755.B9DFB10D6394@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/21 16:57:55 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Uconstants.c Log message: missing #includes -- at least Linux and FreeBSD broken From jkrell at elego.de Wed Jan 21 17:13:35 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jan 2009 17:13:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090121161336.02FFA10D5DA3@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/21 17:13:35 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Uconstants.c Uerror.i3 UtimeC.c Log message: fixes for Solaris: remove const to fix warning, raise Uerror.Max to 151, missing sys/filio.h #include (put it under #ifdef __sun) From jkrell at elego.de Thu Jan 22 01:58:29 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jan 2009 1:58:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090122005829.86FF4744001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/22 01:58:29 Modified files: cm3/scripts/: sysinfo.sh Log message: upgrade version from 5.7.0 to 5.7.1 From jay.krell at cornell.edu Thu Jan 22 02:00:37 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 22 Jan 2009 01:00:37 +0000 Subject: [M3commit] m3commit test.. Message-ID: I'm not seeing m3commit mail any longer. - Jay From jay.krell at cornell.edu Thu Jan 22 02:01:48 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 22 Jan 2009 01:01:48 +0000 Subject: [M3commit] m3commit not working? Message-ID: I'm not seeing m3commit mail. - Jay From jkrell at elego.de Thu Jan 22 02:09:36 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jan 2009 2:09:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090122010950.7ED17714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/22 02:09:36 Modified files: cm3/scripts/python/: pylib.py Log message: test m3commit; seems maybe working now From jay.krell at cornell.edu Thu Jan 22 02:30:07 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 22 Jan 2009 01:30:07 +0000 Subject: [M3commit] [M3devel] m3commit not working? (now working) In-Reply-To: References: Message-ID: sorry, nevermind, I see it now. A few were skipped though, like upping the version from 5.7.0 to 5.7.1, fixes for Solaris, Linux, FreeBSD though I think only in inactive files or less active platforms, not sure (i.e. Uconstants.c errors not active, UtimeC.c was only a warning, though it was also broken on Solaris a few days wrt altzone). They are in the archives on the web page. e.g.: http://mail.elegosoft.com/pipermail/m3commit/2009-January/002618.html http://mail.elegosoft.com/pipermail/m3commit/2009-January/002618.html http://mail.elegosoft.com/pipermail/m3commit/2009-January/002617.html http://mail.elegosoft.com/pipermail/m3commit/2009-January/002616.html - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3commit at elegosoft.com; m3devel at elegosoft.com > Date: Thu, 22 Jan 2009 01:01:48 +0000 > Subject: [M3devel] m3commit not working? > > > I'm not seeing m3commit mail. > > - Jay From jay.krell at cornell.edu Thu Jan 22 02:36:14 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 22 Jan 2009 01:36:14 +0000 Subject: [M3commit] [M3devel] m3commit not working? (now working) In-Reply-To: References: Message-ID: er, I see mail I send directly, but I think still not checkins. sorry for confusion... - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3commit at elegosoft.com; m3devel at elegosoft.com > Subject: RE: [M3devel] m3commit not working? (now working) > Date: Thu, 22 Jan 2009 01:30:07 +0000 > > > sorry, nevermind, I see it now. A few were skipped though, like upping the version from 5.7.0 to 5.7.1, fixes for Solaris, Linux, FreeBSD though I think only in inactive files or less active platforms, not sure (i.e. Uconstants.c errors not active, UtimeC.c was only a warning, though it was also broken on Solaris a few days wrt altzone). They are in the archives on the web page. > > e.g.: > http://mail.elegosoft.com/pipermail/m3commit/2009-January/002618.html > http://mail.elegosoft.com/pipermail/m3commit/2009-January/002618.html > http://mail.elegosoft.com/pipermail/m3commit/2009-January/002617.html > http://mail.elegosoft.com/pipermail/m3commit/2009-January/002616.html > > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3commit at elegosoft.com; m3devel at elegosoft.com >> Date: Thu, 22 Jan 2009 01:01:48 +0000 >> Subject: [M3devel] m3commit not working? >> >> >> I'm not seeing m3commit mail. >> >> - Jay From jkrell at elego.de Thu Jan 22 03:01:41 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jan 2009 3:01:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090122020141.3119810D5A74@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/22 03:01:41 Modified files: cm3/scripts/python/: pylib.py Log message: test m3commit From jkrell at elego.de Thu Jan 22 15:21:10 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jan 2009 15:21:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090122142110.45A5010D49FC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/22 15:21:10 Modified files: cm3/scripts/config/: config.c Log message: print some maxpath stuff, print about fd_set, fix for platforms that do have sockaddr_in.len From jkrell at elego.de Thu Jan 22 15:23:24 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jan 2009 15:23:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090122142324.B206810D49FC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/22 15:23:24 Added files: cm3/m3-libs/m3core/src/unix/darwin-common/: Usysdep.i3 m3makefile Log message: initial Darwin version, based only on 32bit PowerPC From jkrell at elego.de Thu Jan 22 16:20:58 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jan 2009 16:20:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090122152058.5EFE1714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/22 16:20:58 Modified files: cm3/scripts/: lzma.sh Log message: gzcat is much more portably gzip than zcat is (Darwin, Solaris) From jkrell at elego.de Sun Jan 25 17:36:15 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 25 Jan 2009 17:36:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090125163615.DABA3904003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/25 17:36:15 Modified files: cm3/m3-sys/windowsResources/src/: winRes.tmpl Log message: Surely there is no need to run cvtres manually. Not doing so works with a few toolsets I have tried. The linker accepts .res files and it is normal to give them to it. The invocation here is incompatible with very old toolsets (Visual C++ 2.0) and a minor porting nuisance due to the use of /machine:x86. The only savings I can imagine is if some resources are used "like a library" and linked into multiple binaries, that invocations of cvtres can be reduced, from once per link to just once. From jkrell at elego.de Sun Jan 25 17:57:41 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 25 Jan 2009 17:57:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090125165741.91110904003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/25 17:57:41 Modified files: cm3/scripts/python/: pylib.py Log message: m3commit test From jkrell at elego.de Sun Jan 25 19:30:27 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 25 Jan 2009 19:30:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090125183028.1799810D6357@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/25 19:30:27 Modified files: cm3/m3-tools/uniq/src/: Main.m3 Log message: Fix the problem where the Modula-3 implementation of uniq.exe causes building gcc to hang if it is first in %PATH%. The problem is that building gcc invokes uniq with a file path on the command line, rather than feeding it stdin. Modula-3 uniq.exe only was expecting stdin and hangs reading from it and getting nothing. From jkrell at elego.de Mon Jan 26 10:57:32 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jan 2009 10:57:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090126095732.B29E610D63BB@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/26 10:57:32 Modified files: cm3/m3-sys/windowsResources/src/: winRes.tmpl Log message: go ahead and remove the unnecessary stuff, rather than just comment it out From jkrell at elego.de Mon Jan 26 13:36:15 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jan 2009 13:36:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090126123615.73B1B10D6491@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/26 13:36:15 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RT0.i3 Log message: fix comment to refer to correct interface, since the interface doesn't actually exist (the fiel does, but it isn't built) From jkrell at elego.de Mon Jan 26 13:38:12 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jan 2009 13:38:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090126123812.C7F4B10D63BC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/26 13:38:12 Modified files: cm3/m3-libs/m3core/src/runtime/FreeBSD/: m3makefile Removed files: cm3/m3-libs/m3core/src/runtime/FreeBSD/: DEFS.h RTStackASM.s Log message: remove unused files, esp. in obsolete target From jkrell at elego.de Mon Jan 26 13:39:20 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jan 2009 13:39:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090126123920.05B9910D63BC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/26 13:39:20 Removed files: cm3/m3-libs/m3core/src/runtime/FreeBSD2/: DEFS.h RTStackASM.s Log message: remove unused files, esp. in obsolete targets From jkrell at elego.de Mon Jan 26 13:41:29 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jan 2009 13:41:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090126124129.0A04B10D63BC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/26 13:41:29 Removed files: cm3/m3-libs/m3core/src/runtime/FreeBSD3/: RTStackASM.s Log message: remove unused file, esp. from obsolete targets From jkrell at elego.de Mon Jan 26 13:42:51 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jan 2009 13:42:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090126124251.C4F8A10D63BC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/26 13:42:51 Removed files: cm3/m3-libs/m3core/src/runtime/FreeBSD4/: RTStackASM.s Log message: remove unused file From jkrell at elego.de Mon Jan 26 13:43:47 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jan 2009 13:43:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090126124347.3E19A10D63BC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/26 13:43:47 Removed files: cm3/m3-libs/m3core/src/runtime/LINUXLIBC6/: RTStackASM.s Log message: remove unused file From jkrell at elego.de Mon Jan 26 13:44:56 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jan 2009 13:44:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090126124456.E46CA10D63BC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/26 13:44:56 Removed files: cm3/m3-libs/m3core/src/runtime/LINUX/: RTStackASM.s Log message: remove unused file, in obsolete Linux 1.x a.out target From jkrell at elego.de Wed Jan 28 00:28:42 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 0:28:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090127232842.99F2310D63C2@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 00:28:42 Removed files: cm3/m3-libs/m3core/src/runtime/I386_DARWIN/: RTStackASM.s _fpsetjmp.s Log message: delete unused files From jkrell at elego.de Wed Jan 28 00:29:48 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 0:29:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090127232948.7195910D63C2@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 00:29:48 Removed files: cm3/m3-libs/m3core/src/runtime/LINUXELF/: RTStackASM.s Log message: remove unused file, in obsolete target From jkrell at elego.de Wed Jan 28 00:30:59 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 0:30:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090127233102.782A7744006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 00:30:59 Modified files: cm3/m3-libs/m3core/src/runtime/OS2/: m3makefile Removed files: cm3/m3-libs/m3core/src/runtime/OS2/: RTStackASM.s Log message: remove unused file From jkrell at elego.de Wed Jan 28 00:32:34 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 0:32:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090127233234.B08F9F04006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 00:32:34 Modified files: cm3/m3-libs/m3core/src/runtime/NetBSD2_i386/: m3makefile Log message: remove remnants of unused file From jkrell at elego.de Wed Jan 28 00:36:57 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 0:36:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090127233657.3532210D63C5@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 00:36:57 Removed files: cm3/m3-libs/m3core/src/runtime/SOLsun/: RTStackASM.s.sav RTStackASM.s Log message: remove unused files From jkrell at elego.de Wed Jan 28 00:37:51 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 0:37:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090127233751.9414710D63C5@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 00:37:51 Removed files: cm3/m3-libs/m3core/src/runtime/SOLgnu/: RTStackASM.s Log message: remove unused file From jkrell at elego.de Wed Jan 28 16:23:53 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 16:23:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090128152353.9BDDF714575@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 16:23:53 Modified files: cm3/m3-libs/m3core/src/runtime/IBMR2/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/LINUXLIBC6/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/SOLgnu/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/SOLsun/: RTThread.m3 Log message: gratuitous formating difference From jkrell at elego.de Wed Jan 28 16:47:15 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 16:47:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090128154716.3138F1704004@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 16:47:15 Modified files: cm3/m3-libs/m3core/src/runtime/FreeBSD4/: RTSignal.m3 Log message: eliminate gratuitous platform specific diff -- change local variable 'dummy' to 'old From jkrell at elego.de Wed Jan 28 16:49:46 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 16:49:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090128154952.A2A8F220001A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 16:49:46 Modified files: cm3/m3-libs/m3core/src/runtime/ALPHA_OSF/: RTThread.m3 Log message: eliminate gratuitous formating difference, missed this before From jkrell at elego.de Wed Jan 28 16:52:56 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 16:52:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090128155256.C58E8220001A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 16:52:56 Modified files: cm3/m3-libs/m3core/src/runtime/ALPHA_OSF/: RTSignal.m3 cm3/m3-libs/m3core/src/runtime/AMD64_DARWIN/: RTSignal.m3 cm3/m3-libs/m3core/src/runtime/FreeBSD4/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/I386_DARWIN/: RTSignal.m3 cm3/m3-libs/m3core/src/runtime/LINUXLIBC6/: RTSignal.m3 cm3/m3-libs/m3core/src/runtime/NetBSD2_i386/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/PPC_DARWIN/: RTSignal.m3 cm3/m3-libs/m3core/src/runtime/SOLgnu/: RTSignal.m3 cm3/m3-libs/m3core/src/runtime/SOLsun/: RTSignal.m3 Log message: eliminate gratuitous whitespace diff between platforms before: <*ASSERT i = 0*> after: <* ASSERT i = 0 *> From jkrell at elego.de Wed Jan 28 17:21:19 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 17:21:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090128162119.7294D10D5ECB@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 17:21:19 Modified files: cm3/m3-libs/m3core/src/runtime/AMD64_DARWIN/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/I386_DARWIN/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/LINUXLIBC6/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/PPC_DARWIN/: RTThread.m3 Log message: eliminate more gratuitous platform specific diffs These platforms were doing FROM Usignal IMPORT sigaction, sigprocmask, etc. whereas other platforms just IMPORT Usignal; and then reference qualified Usignal.sigaction, etc. From jkrell at elego.de Wed Jan 28 18:44:42 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 18:44:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090128174442.D2AD210D63A2@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 18:44:42 Modified files: cm3/m3-libs/m3core/src/runtime/ALPHA_OSF/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/AMD64_DARWIN/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/FreeBSD4/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/I386_DARWIN/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/LINUXLIBC6/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/NetBSD2_i386/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/PPC_DARWIN/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/SOLgnu/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/SOLsun/: RTThread.m3 Log message: eliminate more gratuitous platform differences Some platforms uses + to combine mprotect protections, some used Word.Or. Use + because it is terser, assuming these are all independent flags. Some platforms used WITH i = foo; ASSERT(i = 0); Some used VAR i := foo; ASSERT(i = 0); Use VAR, in order to elminate indentation. some platforms said IF (page_size = 0) and some said IF page_size = 0. Use the second shorter form. This code kinda looks like it has a race condition, but probably not, since it is the code that is involved in creating threads, there cannot be multiple threads until after it runs. Platforms still vary as to what protections they use on the last stack page. From jkrell at elego.de Thu Jan 29 08:43:23 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 29 Jan 2009 8:43:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090129074323.C5F4010D6493@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/29 08:43:23 Modified files: cm3/m3-libs/m3core/src/unix/darwin-common/: Usysdep.i3 Log message: add missing semicolons; this code is not yet active From jkrell at elego.de Thu Jan 29 18:07:09 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 29 Jan 2009 18:07:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090129170709.CBB9110D5F23@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/29 18:07:09 Modified files: cm3/scripts/config/: config.c Log message: Cygwin's setjmp.h reports the wrong size for jmp_buf; detect and report that. From jkrell at elego.de Fri Jan 30 04:25:37 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 30 Jan 2009 4:25:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090130032538.030B410D5DAA@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/30 04:25:37 Added files: cm3/m3-libs/m3core/src/context/: context.c context.h tcontext.c Log message: highly non-portable working version of set/get/make/swapcontext for NT386; should assist in providing e.g. Cygwin, OpenBSD/x86, and perhaps non-x86, though again, it is highly system specific, and inline assembly syntax is very different between Visual C++ and gcc From jkrell at elego.de Fri Jan 30 16:26:42 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 30 Jan 2009 16:26:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090130152642.30B8F71457D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/30 16:26:42 Modified files: cm3/m3-libs/m3core/src/context/: context.c context.h tcontext.c Log message: fix newlines From jkrell at elego.de Fri Jan 30 16:28:35 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 30 Jan 2009 16:28:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090130152835.E94DC10D5A8D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/30 16:28:35 Modified files: cm3/m3-libs/m3core/src/context/: context.c context.h Log message: use pushad/popad, and keep registers as all size_t, only change the type of esp for convenience via a local; note that real NT386/Cygwin usermode threads should use Win32 fibers, this is just a prototype that maybe could be applied to OpenBSD/x86 and proof of concept of how difficult/possible the context APIs are to implement -- very difficult actually, just that x86 is familiar From jkrell at elego.de Fri Jan 30 16:35:57 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 30 Jan 2009 16:35:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090130153557.C9A0771457E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/30 16:35:57 Modified files: cm3/m3-libs/m3core/src/unix/linux-64/: m3makefile Removed files: cm3/m3-libs/m3core/src/unix/linux-64/: Uucontext.i3 Log message: should fix AMD64_LINUX and SPARC64_LINUX -- no need for Uucontext.i3 here, just use the common one From jkrell at elego.de Fri Jan 30 20:06:51 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 30 Jan 2009 20:06:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090130190651.EDAF2744002@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/30 20:06:51 Modified files: cm3/m3-libs/m3core/src/context/: tcontext.c Added files: cm3/m3-libs/m3core/src/context/winfiber/: context.c context.h cm3/m3-libs/m3core/src/context/x86msvc/: context.c context.h readme.txt Removed files: cm3/m3-libs/m3core/src/context/: context.c context.h Log message: A more realistic implementation of *context portable to all Windows platforms by using fibers. Move previous to "x86msvc". From jkrell at elego.de Fri Jan 30 23:16:58 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 30 Jan 2009 23:16:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090130221658.B4A8B744002@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/30 23:16:58 Added files: cm3/m3-libs/m3core/src/context/x86/: Makefile context.c context.h contextasm.s Log message: works on OpenBSD/x86, neat From jkrell at elego.de Sat Jan 31 00:10:47 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jan 2009 0:10:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090130231047.2354410D63AB@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/31 00:10:47 Modified files: cm3/m3-libs/m3core/src/context/x86/: Makefile context.c contextasm.s Log message: adapt to Cygwin -- which uses coff, so symbols with underscores, and different validity/meaning of .type and .size; and its make doesn't understand $> From jkrell at elego.de Sat Jan 31 00:14:13 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jan 2009 0:14:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090130231413.2086710D63AB@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/31 00:14:13 Modified files: cm3/m3-libs/m3core/src/context/x86/: Makefile contextasm.s Log message: finish adapting to Cygwin and quash make clean output From jkrell at elego.de Sat Jan 31 05:25:43 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jan 2009 5:25:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090131042543.ED60710D5F16@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/31 05:25:43 Modified files: cm3/m3-libs/m3core/src/context/: tcontext.c cm3/m3-libs/m3core/src/context/x86/: Makefile Log message: preemptive version works on OpenBSD/x86 From jkrell at elego.de Thu Jan 1 01:02:45 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jan 2009 1:02:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090101000246.4E23210D5F06@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/01 01:02:45 Modified files: cm3/m3-libs/m3core/src/: Uwaitpid.quake m3makefile cm3/m3-libs/m3core/src/thread/: m3makefile cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile Added files: cm3/m3-libs/m3core/src/: thread.quake Log message: Remove the Sleep from [Process]Wait in sysutils, as it was removed from libm3, at least for non-user threads platforms. This should accomplish some speedup, but not measured. NOTE: historically m3core is built for userthreads or kernelthreads; now sysutils is too. Ideally such "switches" are contained within one .dll and then exported to others that adapt. In this case, both .dlls contain the constant. The roundabout structuring here, as well as the previous non-ideal situation, is in the interest of letting sysutils work against old m3core, while still getting this fix. Another approach to consider, if it can be easily reliably achieved, is to only do the "copying" when building against an old m3core, and go ahead and use the usual share-by-call mechanisms when building against newer m3core. Another approach is..what is this import_pkg quake feature? It seems to allow sharing-by-automated-copy instead of sharing-by-call, like static linking vs. dynamic linking. There does seem to be a bunch of redundancy in sysutils compared to m3core or libm3..but the compiler works with older m3core/libm3 whereas there sort of is no such thing as an 'old' sysutils, since it was introduced relatively recently. Really just need to bump forward the bootstrap start?? From jkrell at elego.de Thu Jan 1 01:55:29 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jan 2009 1:55:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090101005529.A85E510D5F02@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/01 01:55:29 Modified files: cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 Log message: share some common code From jkrell at elego.de Thu Jan 1 08:51:02 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jan 2009 8:51:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090101075102.B8A9710D4524@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/01 08:51:02 Added files: cm3/scripts/: lzma.sh Log message: make-dist helper -- for any *.tar.gz in current directory, produce equiv .tar.lzma; my current thinking is to always release both, folks that have lzma can spare the download bandwidth, of course one of the downsides is that people might be confused or lazy and download both From jkrell at elego.de Thu Jan 1 09:31:37 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jan 2009 9:31:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090101083138.9FE3B10D5E61@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/01 09:31:37 Modified files: cm3/m3-libs/m3core/src/unix/Common/: m3unix.h Log message: fix newlines From jkrell at elego.de Thu Jan 1 09:43:06 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jan 2009 9:43:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090101084306.57E8110D4524@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/01 09:43:06 Modified files: cm3/m3-libs/m3core/src/unix/Common/: m3unix.h UdirC.c Log message: having done some research on the myriad macros guiding 64 vs. 32 bit file offsets/sizes, this should suffice From jkrell at elego.de Thu Jan 1 09:44:50 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jan 2009 9:44:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090101084450.653A110D4524@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/01 09:44:50 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UstatC.c Log message: fix one newline From jkrell at elego.de Fri Jan 2 01:21:20 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 1:21:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102002120.D5FF610D5D5D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 01:21:20 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c cm3/m3-libs/m3core/src/unix/cygwin/: Unix.i3 Usignal.i3 Usocket.i3 Ustat.i3 Utime.i3 Utypes.i3 Uutsname.i3 m3makefile Added files: cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 Removed files: cm3/m3-libs/m3core/src/unix/cygwin/: Utime.m3 Log message: tighten up UtimeC.c a little, perhaps unnecessarily in particular, function that takes [0..1] assert its parameter, and in the unlikely case that doesn't suffice (compile with -DNDEBUG?), truncate it as well. If the extern function is declared as taking [0..1], presumably the range checks are on the caller side and not the callee side??? That is more bloated, but seems better, maybe. Remove some unused prototypes. Dubious to put them here. Might have quashed compiler warnings(as errors) in some contexts, will put them back as needed, probably in m3unix.h. The code is definitely standard-correct, but might not pass all command lines, like gcc -Wmissing-prototypes or such. (Er, at least Metrowerks was the worst here, making you prototype functions that were implemented prior to use, or not even used.., gcc hopefully only complains about used stuff..?) First round of moving Unix constants and types into new Usysdep.i3, and then exporting those from files that contain some portable content. plan: do this one platform at a time (cygwin, linux, openbsd) do each platform twice it is very tedious, copy/paste intensive, error-prone first round not commited, just saved away and then compared to second round once each platform done, go back and extract the common parts the intention is that every file but Usysdep.i3 is identical, but this is best verified and acted upon only once they are all three there and seeming to work Here just Cygwin. This should significantly reduce the system dependent content, even though it may lead to more lines over all, since sysdep content must be declared AND forwarded. Note that this discovered duplicate declarations of timezone or such, one in Utime.i3, the other in Utypes.i3. Investigate this more later. As well, Usysdep probably contains some portable content, to be whittled down later. As well, the resulting portable files -- Unix.i3 and such -- are likely to be in varying order after the first round, and Cygwin's suffers (arguably) from a lack of comments and unreadable order (flags/types/functions not near relatives). At some point this was to reduce the size of the cloned headers, but once their duplication is reduced, the trade off starts shifting. Merge Utime.m3 into UtimeC.c. Perhaps not ideal. Cygwin is the only Posix platform that needs this C wrapper. Perhaps the calling Modula-3 should be modified to either ignore errors, or ignore errors on Cygwin (you can do runtime checks of what platform you are on, after all, some code does). From jkrell at elego.de Fri Jan 2 02:58:52 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 2:58:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102015852.5F47F10D5D5E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 02:58:52 Modified files: cm3/m3-libs/m3core/src/Csupport/: m3makefile cm3/m3-libs/m3core/src/Csupport/libgcc/: libgcc.c Log message: Account for NT386 and NT386GNU clashing over /cm3/lib/hand.obj, which should probably be moved. As well, this will be needed for any 32bit system that doesn't use gcc as the compiler/linker (AIX, HP-UX, IRIX, etc.). It is already needed/used by SOLsun. From jkrell at elego.de Fri Jan 2 06:00:55 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 6:00:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102050055.4096D10D5EDB@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 06:00:55 Modified files: cm3/m3-ui/zeus/src/: m3zume.tmpl Log message: % % Allow native I386_NT (NT386) cm3 to run I386_CYGWIN (NT386GNU) m3zume. % This is a fairly real scenario in my workflow that I was ignoring. % I386_CYGWIN does not like commands like: % m3zume ..\foo\bar => invalid extension, it probably % thinks \foo\bar is the extension. % This is a more general problem, not fully solved here. % For this to be OK on native Win32 depends on that / are now accepted on Win32. % (Which I question from time to time, if it was a good idea.) % % % A problem is that on "biarch" systems, such as NT386 + NT386GNU, or % LINUXLIBC6 + AMD64_LINUX, /cm3/bin/cm3 can bounce back and forth between the two, % leading to the two worlds to come together somewhat, and perhaps interop. % % Probably there should be /cm3/bin/target/cm3, and a "portable" /cm3/bin/cm3 that % figures out which one to call. On Posix it would be an extensionless sh % that ends with "exec". It could sniff host platform with uname, like sysinfo.sh does, % though sysinfo.sh would also compute it, allowing skipping running the sniffing repeatedly. % On NT it would be nice if it could be .cmd, but more likely an NT386 binary. % On uniarch systems, just link the two. % % This way the systems don't have to interop, nor would the general problem of differing % slashes have to be dealt with. Though, it is a dilemna beyond Modula-3 as to interop % of Cygwin binaries with Win32 binaries. % From jkrell at elego.de Fri Jan 2 08:28:23 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 8:28:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102072823.705C810D5EDD@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 08:28:23 Removed files: cm3/m3-libs/m3core/src/unix/solaris-2-x/: Udir.m3 Log message: remove unused file From jkrell at elego.de Fri Jan 2 09:06:26 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 9:06:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102080626.93D0210D5F04@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 09:06:26 Modified files: cm3/m3-libs/m3core/src/time/POSIX/: m3makefile Log message: add missing SPARC64_OPENBSD; and put all the OPENBSD platforms next to each other From jkrell at elego.de Fri Jan 2 09:10:50 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 9:10:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102081050.BE50210D5EDC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 09:10:50 Modified files: cm3/m3-libs/m3core/src/unix/openbsd-common/: Udir.i3 Unix.i3 Upthread.i3 Usignal.i3 Usocket.i3 Utime.i3 Utypes.i3 Uucontext.i3 Uutsname.i3 m3makefile Added files: cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 Log message: refactor system dependent lines (ie: types and constants) into Usysdep, with the intent that all the other files will be identical across all targets and move into the Common directory (and even still, then and Usysdep might be further reduced, and Usysdep.i3 generated automatically) Note that Uerror.i3 is left alone (as it was for Cygwin, but forgot to mention that); it has a /very/ high density of sysdep lines, like essentially every line; unless we wrap the constants up in accessor functions written in C, then it becomes completely portable. (Other files like Uucontext are also highly sysdep, and might become more so when make/set/get/swapcontext supported added; we'll see; also, most of the stat values are sysdep, except a few that Cygwin uses zero for; again, this is just a step, more before and after.) From jkrell at elego.de Fri Jan 2 21:08:56 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 21:08:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102200856.3960610D5CFC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 21:08:56 Modified files: cm3/m3-libs/libm3/src/os/WIN32/: OSConfigWin32.m3 cm3/m3-libs/libm3/src/os/POSIX/: OSConfigPosix.m3 Log message: eliminate race condition that could occur if the code is highly optimized -- don't depend on write ordering From jkrell at elego.de Fri Jan 2 21:22:55 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 21:22:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102202255.9177E10D5D00@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 21:22:55 Modified files: cm3/m3-libs/libm3/src/os/WIN32/: OSConfigWin32.m3 Log message: add in some missing architectures, though arguably this should be either GetEnv(PROCESSOR_ARCHITECTURE) (does it work on CE?) or a constant determined at build time; the historical code goes obsolete automatically and quietly From jkrell at elego.de Fri Jan 2 21:36:45 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 21:36:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102203645.6902110D5D00@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 21:36:45 Modified files: cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 m3makefile cm3/m3-libs/libm3/src/os/POSIX/: OSConfigPosix.m3 m3makefile cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 m3makefile Added files: cm3/m3-libs/libm3/src/os/POSIX/: OSConfigPosixC.c OSConfigPosixC.i3 Removed files: cm3/m3-libs/m3core/src/unix/cygwin/: Uutsname.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Uutsname.i3 Log message: eliminate lone Uutsname.i3 usage and then system-dependent Uutsname.i3 itself, via portable C wrapper The vast bulk of OSConfig appears dead within cm3 anyway. All I see is OSConfig.LineSep (for writing only; readers should accept any of the three usages) and OSConfig.UserName(). So maybe we should just aggressively prune it down? Could be users outside the tree, granted. From jkrell at elego.de Fri Jan 2 21:49:31 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 21:49:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102204931.4718610D461B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 21:49:31 Modified files: cm3/m3-libs/m3core/src/unix/linux-common/: m3makefile Removed files: cm3/m3-libs/m3core/src/unix/linux-common/: Uutsname.i3 Log message: delete this one too From jkrell at elego.de Fri Jan 2 23:04:54 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 23:04:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102220454.B9EF910D5481@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 23:04:54 Modified files: cm3/m3-libs/m3core/src/unix/Common/: m3makefile Log message: fix newlines From jkrell at elego.de Fri Jan 2 23:07:05 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 23:07:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102220705.3EA0810D5481@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 23:07:05 Modified files: cm3/m3-libs/m3core/src/unix/linux-common/: Unix.i3 Upthread.i3 Usignal.i3 Usocket.i3 Utime.i3 Utypes.i3 m3makefile Log message: refactor linux-common using Usysdep a little more needed for Usignal and Usocket due to linux-sparc variant (should be ok, just hasn't achieved as much commonality as in the openbsd-common change) From jkrell at elego.de Fri Jan 2 23:38:40 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 23:38:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102223840.CB17110D542A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 23:38:40 Modified files: cm3/m3-libs/m3core/src/C/Common/: m3makefile Log message: fix newlines From jkrell at elego.de Fri Jan 2 23:40:45 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 23:40:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102224045.734F510D542A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 23:40:45 Added files: cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 Log message: forgot to add this From jkrell at elego.de Sat Jan 3 00:49:44 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 0:49:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102234944.CA23510D4D19@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 00:49:44 Modified files: cm3/m3-libs/m3core/src/unix/cygwin/: m3makefile Log message: forgot to delete Uutsname.i3 here From jkrell at elego.de Sat Jan 3 00:52:05 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 0:52:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102235205.995B110D4D19@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 00:52:05 Modified files: cm3/m3-libs/m3core/src/unix/openbsd-common/: Utypes.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Utypes.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Utypes.i3 Log message: make these three files identical From jkrell at elego.de Sat Jan 3 01:57:20 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 1:57:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103005721.001F410D54EF@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 01:57:20 Modified files: cm3/m3-libs/m3core/src/unix/hpux-7-0/: Utime.i3 cm3/m3-libs/m3core/src/unix/irix-5.2/: Utime.i3 cm3/m3-libs/m3core/src/unix/linux/: Utime.i3 Log message: go ahead and break these three old dormant platforms rather than determine interfaces regarding timezones, alt timezones, daylight savings, etc.; will probably actually repair Irix and HPUX in the next few months (! I have Irix running at home and HP-UX maybe soon) but Linux 1.x a.out not likely; this is part of other Utime-related cleanup. From jkrell at elego.de Sat Jan 3 01:59:30 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 1:59:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103005930.4A0F010D569E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 01:59:30 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c cm3/m3-libs/m3core/src/unix/cygwin/: Utime.i3 cm3/m3-libs/m3core/src/unix/linux-libc6/: Utime.i3 cm3/m3-libs/m3core/src/unix/solaris-2-x/: Utime.i3 Log message: 1: put "m3_" in front of the functions we implement outselves, for clarity, and in case there are "real" functions with these names 2: add comments indicating what should perhaps be re-investigated no "real" change From jkrell at elego.de Sat Jan 3 02:51:36 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 2:51:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103015136.1C9BC10D458D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 02:51:36 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c cm3/m3-libs/m3core/src/unix/cygwin/: Utime.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Utime.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Utime.i3 Log message: make these three files identical too From jkrell at elego.de Sat Jan 3 06:22:25 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 6:22:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103052225.413CA170400C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 06:22:25 Modified files: cm3/m3-sys/cm3/src/: M3Build.m3 Log message: (* Host and Target paths sometimes get confused, leading to many warnings such as: package "libm3" is already overridden to C:\dev2\cm3.2/m3-libs, ignoring new override to C:/dev2/cm3.2/m3-libs PathEqual is defined as Text.Equal or Text.Equal(replacing backward slashes with forward slashes). It would also be reasonable to be case insensitive if the path contains any backward slashes, or if they both contain colon as the second character. *) From jkrell at elego.de Sat Jan 3 06:36:43 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 6:36:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103053644.E810410D4624@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 06:36:43 Modified files: cm3/m3-ui/juno-2/juno-app/src/: m3makefile Log message: Fix more substantial cross build scenarios. Previously fixed cross scenarios where host and target could run on the same machine (NT386/NT386GNU, LINUXLIBC6/AMD64_LINUX). This fixes 'normal' cross scenarios, where they can't. Why are we even using unshipped binaries here? How about just trust $PATH, knowing that binaries ship next to cm3, and that cm3 is probably in $PATH? (Granted, it need not be, and perhaps PklFonts doesn't ship?) Also, why are we cd'ing around? Why doesn't the the package whose output directory we are stomping in do this, or why don't we just stay in our own output directory? It seems like a generally bad idea what is going on here -- you know, imagine a multithreaded build..packages should keep to themselves. This does impact all builds but should be simply correct. From jkrell at elego.de Sat Jan 3 06:52:54 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 6:52:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103055254.A161A10D582F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 06:52:53 Modified files: cm3/m3-libs/m3core/src/unix/openbsd-common/: Usocket.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usocket.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Usocket.i3 Log message: three more identical files, they almost already were save for whitespace, and an int vs. size_t but in cygwin/recvfrom; and get size_t from Cstddef instead of Utypes From jkrell at elego.de Sat Jan 3 13:07:00 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 13:07:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103120700.D0D7F10D5E88@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 13:07:00 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile Log message: fix newlines From jkrell at elego.de Sat Jan 3 13:07:34 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 13:07:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103120734.31A5110D5E88@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 13:07:34 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile Log message: use Common on all platforms From jkrell at elego.de Sat Jan 3 14:14:18 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 14:14:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103131421.6B73D10D5E9E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 14:14:18 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: don't leak attributes used for setting thread stack size From jkrell at elego.de Sat Jan 3 14:54:38 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 14:54:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103135438.CB44A10D43B4@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 14:54:38 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: ProcessCygwin.m3 cm3/m3-libs/m3core/src/unix/Common/: m3makefile cm3/m3-libs/m3core/src/unix/cygwin/: Unix.i3 Usysdep.i3 Utypes.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Unix.i3 Upthread.i3 Usignal.i3 Usysdep.i3 Utypes.i3 m3makefile cm3/m3-libs/m3core/src/unix/linux-sparc/: Usignal.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Unix.i3 Upthread.i3 Usignal.i3 Usysdep.i3 Utypes.i3 Added files: cm3/m3-libs/m3core/src/unix/Common/: UnixC.c Log message: on going header cleanup/merge (in non-mainstream platforms) some lengths were incorrectly int instead of size_t flesh out cygwin's Usignal (not used, but need to be the same) add wrappers for anything dealing with off_t or opening files so that we can be sure to get 64bit off_t and O_LARGEFILE, even on 32bit platforms, and with common headers; otherwise we'd have to fiddle with the <*extern*> name on 32bit Linux and Solaris (Solaris not yet relevant here, but it will be) Darwin does very similar. start adding comments back; they won't be so annoyingly bloated when we only have one copy of them instead of per-platform add mode_t; we were using the wrong type there in a few places (int) remove bogus sigaction type, some editing error problem, it is a field not a type cleanup the NDELAY / NONBLOCK / M3_NONBLOCK stuff /somewhat/ still leaving stuff around for compat cleanup is that Usysdep only defines NDELAY, and then portable layer aliases all three as one Cygwin will hold back with its own Usignal.i3. In particular, pthreads platforms need more in Usignal than non-pthreads. Cygwin also won't have pthreads.i3 at all, unless/until we use it. From jkrell at elego.de Sat Jan 3 15:00:20 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 15:00:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103140025.DC62010D5E88@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 15:00:20 Modified files: cm3/m3-libs/m3core/src/unix/linux-common/: Unix.i3 Log message: missed a spot of semantically meaningless diff From jkrell at elego.de Sat Jan 3 15:01:05 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 15:01:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103140106.1947B10D5E88@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 15:01:05 Modified files: cm3/m3-libs/m3core/src/unix/cygwin/: Utypes.i3 Log message: fix newlines From jkrell at elego.de Sat Jan 3 16:15:38 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 16:15:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103151538.4BE6C10D458D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 16:15:38 Modified files: cm3/m3-libs/m3core/src/unix/Common/: m3makefile Added files: cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Usignal.i3 Usocket.i3 Utime.i3 Utypes.i3 Removed files: cm3/m3-libs/m3core/src/unix/cygwin/: Unix.i3 Usocket.i3 Utime.i3 Utypes.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Unix.i3 Upthread.i3 Usignal.i3 Usocket.i3 Utime.i3 Utypes.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Unix.i3 Upthread.i3 Usignal.i3 Usocket.i3 Utime.i3 Utypes.i3 Log message: move 2-way or 3-say identical files to Common From jkrell at elego.de Sat Jan 3 16:19:14 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 16:19:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103151915.BDB1C10D458D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 16:19:14 Modified files: cm3/m3-libs/m3core/src/unix/openbsd-common/: m3makefile cm3/m3-libs/m3core/src/unix/linux-common/: m3makefile cm3/m3-libs/m3core/src/unix/cygwin/: m3makefile Log message: move (partly) common files to common From jkrell at elego.de Sat Jan 3 16:25:24 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 16:25:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103152525.25FB610D458D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 16:25:24 Added files: cm3/m3-libs/m3core/src/unix/Common/: Upthread.i3 Log message: forgot to add this From jkrell at elego.de Sat Jan 3 17:03:31 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 17:03:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103160332.0C5AC10D5AF4@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 17:03:31 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: fix the fallback; this never affects me because the probing finds my unshipped codegenerators From jkrell at elego.de Sat Jan 3 17:03:53 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 17:03:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103160354.0332A10D5AF4@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 17:03:53 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: fix the disabled debugprint too From jkrell at elego.de Sun Jan 4 01:43:42 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 1:43:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104004342.B1BD310D5E9A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 01:43:42 Modified files: cm3/m3-libs/m3core/src/unix/irix-5.2/: Unix.i3 Log message: tediously convert to base 8 for easier comparison to other platforms, though base 16 really is far more natural than base 8 except for permission bits.. From jkrell at elego.de Sun Jan 4 01:47:39 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 1:47:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104004739.711E3F04010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 01:47:39 Modified files: cm3/m3-libs/m3core/src/unix/irix-5.2/: Ustat.i3 Log message: ditto: tediously convert to base 8 for easier comparison to other platforms, though base 16 really is far more natural than base 8 except for permission bits.. From jkrell at elego.de Sun Jan 4 01:53:03 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 1:53:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104005303.84C7110D5E9A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 01:53:03 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utypes.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 Log message: significant reduction in sysdep content off_t is always 64 bits (or at least let's hope so) the dir/stat flags are mostly all the same, except for a few that are zero on cygwin M[RWX][OWNER GROUP OTHER] [FXWR]_OK F_SETFD, F_GETFL, F_SETFL FIONREAD ITIMER_REAL ITIMER_VIRTUAL Some of this might be by chance and not by-standard, so under review for new platforms, and probably should be verified during native builds. note that OS/2 has a different S_IFMT but not quite relevant here From jkrell at elego.de Sun Jan 4 02:09:58 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 2:09:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104010959.29D922200044@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 02:09:57 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Utime.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 Log message: struct_itimerval is always the same From jkrell at elego.de Sun Jan 4 02:13:22 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 2:13:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104011323.4603610D5EB1@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 02:13:22 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Utime.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 Log message: struct_timezone is always the same From jkrell at elego.de Sun Jan 4 02:56:16 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 2:56:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104015616.F307E10D5C54@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 02:56:16 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Utime.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 Log message: struct_timespec is always the same From hosking at cs.purdue.edu Sun Jan 4 02:57:28 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 4 Jan 2009 12:57:28 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20090104005303.84C7110D5E9A@birch.elegosoft.com> References: <20090104005303.84C7110D5E9A@birch.elegosoft.com> Message-ID: <13927A2A-F535-48EB-9A33-4813E2B74442@cs.purdue.edu> On some platforms off_t is not 64 bits. This from Solaris (see off_t==long): #if defined(_LARGEFILE_SOURCE) || defined(_XPG5) #ifndef _OFF_T #define _OFF_T #if defined(_LP64) || _FILE_OFFSET_BITS == 32 typedef long off_t; #else typedef __longlong_t off_t; #endif #ifdef _LARGEFILE64_SOURCE #ifdef _LP64 typedef off_t off64_t; #else typedef __longlong_t off64_t; #endif #endif /* _LARGEFILE64_SOURCE */ #endif /* _OFF_T */ #endif /* _LARGEFILE_SOURCE * Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 4 Jan 2009, at 01:53, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/01/04 01:53:03 > > Modified files: > cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utypes.i3 > cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 > > Log message: > significant reduction in sysdep content > > off_t is always 64 bits (or at least let's hope so) > the dir/stat flags are mostly all the same, > except for a few that are zero on cygwin > > M[RWX][OWNER GROUP OTHER] > [FXWR]_OK > F_SETFD, F_GETFL, F_SETFL > FIONREAD > ITIMER_REAL > ITIMER_VIRTUAL > > Some of this might be by chance and not by-standard, > so under review for new platforms, and probably should be verified > during native builds. > > note that OS/2 has a different S_IFMT but not quite relevant here -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 4 03:22:22 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 4 Jan 2009 02:22:22 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <13927A2A-F535-48EB-9A33-4813E2B74442@cs.purdue.edu> References: <20090104005303.84C7110D5E9A@birch.elegosoft.com> <13927A2A-F535-48EB-9A33-4813E2B74442@cs.purdue.edu> Message-ID: But how about if we always #define _FILE_OFFSET_BITS 64 and use C wrappers? As I have done. Or externs with "64" appended, but that prevents me from using one set of .i3 files. I mean, I know there are "modes" with 32 bit off_t, but we should really strive not to use them, if given a choice, eh? You think there are any systems we will ever care about that don't offer a 64 bit off_t (or off64_t, or whatever). - Jay From: hosking at To: jkrell at Date: Sun, 4 Jan 2009 12:57:28 +1100CC: m3commit at elegosoft.comSubject: Re: [M3commit] CVS Update: cm3On some platforms off_t is not 64 bits. This from Solaris (see off_t==long): #if defined(_LARGEFILE_SOURCE) || defined(_XPG5) #ifndef _OFF_T #define _OFF_T #if defined(_LP64) || _FILE_OFFSET_BITS == 32 typedef long off_t; #else typedef __longlong_t off_t; #endif #ifdef _LARGEFILE64_SOURCE #ifdef _LP64 typedef off_t off64_t; #else typedef __longlong_t off64_t; #endif #endif /* _LARGEFILE64_SOURCE */ #endif /* _OFF_T */ #endif /* _LARGEFILE_SOURCE * Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 4 Jan 2009, at 01:53, Jay Krell wrote: CVSROOT: /usr/cvsChanges by: jkrell at birch. 09/01/04 01:53:03Modified files:cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utypes.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 Log message:significant reduction in sysdep contentoff_t is always 64 bits (or at least let's hope so)the dir/stat flags are mostly all the same,except for a few that are zero on cygwinM[RWX][OWNER GROUP OTHER][FXWR]_OKF_SETFD, F_GETFL, F_SETFLFIONREADITIMER_REALITIMER_VIRTUALSome of this might be by chance and not by-standard,so under review for new platforms, and probably should be verifiedduring native builds.note that OS/2 has a different S_IFMT but not quite relevant here -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Sun Jan 4 07:10:59 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 7:10:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104061100.33872904003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 07:10:59 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Utime.i3 Log message: fix newlines From jkrell at elego.de Sun Jan 4 07:12:01 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 7:12:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104061201.D8FEE10D5EC8@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 07:12:01 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Utime.i3 Log message: messed this up earlier -- fix ITIMER_REAL and ITIMER_VIRTUAL From jkrell at elego.de Sun Jan 4 07:14:31 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 7:14:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104061431.A8CEC10D5EC8@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 07:14:31 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Utime.i3 Log message: fix.. From jkrell at elego.de Sun Jan 4 08:03:58 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 8:03:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104070359.010CE10D5EC7@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 08:03:58 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: FilePosixC.c Log message: use correct define for 64 bit file offsets; not sure if it matters here or not From jkrell at elego.de Sun Jan 4 08:04:33 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 8:04:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104070433.68A5010D5EC7@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 08:04:33 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: FSPosix.m3 m3makefile Added files: cm3/m3-libs/libm3/src/os/POSIX/: FSPosixC.c FSPosixC.i3 Log message: replace the lone use of wrapped readdir with a smaller bit of C From jkrell at elego.de Sun Jan 4 08:07:13 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 8:07:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104070713.E95A410D5EC7@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 08:07:13 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Udir.i3 m3makefile cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 Removed files: cm3/m3-libs/m3core/src/unix/Common/: UdirC.c cm3/m3-libs/m3core/src/unix/openbsd-common/: Udir.i3 Log message: remove dirent and varyingly wrapped readdir, having removed the only use pkgtools also uses dirent, but in a way that has 'never' worked on many platforms (e.g. LINUXLIBC), it uses a non-opaque DIR, which POSIX doesn't allow for, and none of the pkgtools directories currently builds; the code using non-opaque DIR could use realpath or something else From jkrell at elego.de Sun Jan 4 08:32:10 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 8:32:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104073211.7FC2810D5EC8@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 08:32:10 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Log message: fix PPC_LINUX, AMD64_LINUX, *_OPENBSD, I thought I already done this -- give them the m3_setitimer function From hosking at cs.purdue.edu Sun Jan 4 05:54:48 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 4 Jan 2009 15:54:48 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20090104005303.84C7110D5E9A@birch.elegosoft.com> <13927A2A-F535-48EB-9A33-4813E2B74442@cs.purdue.edu> Message-ID: <40684423-F337-4C58-BC88-7A0AB7085CF9@cs.purdue.edu> Why not just switch between 32-bit and 64-bit versions. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 4 Jan 2009, at 13:22, Jay wrote: > But how about if we always #define _FILE_OFFSET_BITS 64 and use C > wrappers? > As I have done. > Or externs with "64" appended, but that prevents me from using one > set of .i3 files. > > I mean, I know there are "modes" with 32 bit off_t, but we should > really strive not to use them, if given a choice, eh? > > You think there are any systems we will ever care about that don't > offer a 64 bit off_t (or off64_t, or whatever). > > - Jay > > > From: hosking@ > To: jkrell@ > Date: Sun, 4 Jan 2009 12:57:28 +1100 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > On some platforms off_t is not 64 bits. This from Solaris (see > off_t==long): > > #if defined(_LARGEFILE_SOURCE) || defined(_XPG5) > #ifndef _OFF_T > #define _OFF_T > #if defined(_LP64) || _FILE_OFFSET_BITS == 32 > typedef long off_t; > #else > typedef __longlong_t off_t; > #endif > #ifdef _LARGEFILE64_SOURCE > #ifdef _LP64 > typedef off_t off64_t; > #else > typedef __longlong_t off64_t; > #endif > #endif /* _LARGEFILE64_SOURCE */ > #endif /* _OFF_T */ > #endif /* _LARGEFILE_SOURCE * > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > On 4 Jan 2009, at 01:53, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/01/04 01:53:03 > > Modified files: > cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utypes.i3 > cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 > > Log message: > significant reduction in sysdep content > > off_t is always 64 bits (or at least let's hope so) > the dir/stat flags are mostly all the same, > except for a few that are zero on cygwin > > M[RWX][OWNER GROUP OTHER] > [FXWR]_OK > F_SETFD, F_GETFL, F_SETFL > FIONREAD > ITIMER_REAL > ITIMER_VIRTUAL > > Some of this might be by chance and not by-standard, > so under review for new platforms, and probably should be verified > during native builds. > > note that OS/2 has a different S_IFMT but not quite relevant here > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 4 09:35:40 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 4 Jan 2009 08:35:40 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <40684423-F337-4C58-BC88-7A0AB7085CF9@cs.purdue.edu> References: <20090104005303.84C7110D5E9A@birch.elegosoft.com> <13927A2A-F535-48EB-9A33-4813E2B74442@cs.purdue.edu> <40684423-F337-4C58-BC88-7A0AB7085CF9@cs.purdue.edu> Message-ID: Exactly how? Like off_t == word? That isn't right. Switch which files? I want to reduce switching more than what is needed. Can the string in an extern be "forwarded"? That would be the ideal granularity here. Darwin does stuff very similar or maybe the same as I am doing -- wrapper functions in C for reasons related to off_t, though the wrappers are a bit dubious, e.g.: int m3_pread(int d, void *buf, size_t nbytes, int offset){ off_t off = (off_t)offset; return pread(d, buf, nbytes, offset);} int m3_profil(char *samples, size_t size, u_long offset, u_int scale){ off_t off = (off_t)offset; return profil(samples, size, offset, scale);} int m3_pwrite(int d, const void *buf, size_t nbytes, int offset){ off_t off = (off_t)offset; return pwrite(d, buf, nbytes, offset);} int m3_ftruncate(int fd, int length){ off_t len = (off_t) length; return ftruncate(fd, length);} What does the first line of each of those accomplish? voidm3_assignOffT (off_t* dest, long src){ *dest = (off_t)src;} Is that widening or narrowing, and if it is narrowing, silent truncation? Granted, Modula-3 doesn't check for integer overflow anyway, so silent truncation I guess is "ok". Ideally, every system would have a 64 bit off_t, if not the default, at least via #defines, or using function names with "64" appended (or both). The case for 32bit off_t would be interop with existing code. Otherwise, it seems clear that it should always, if possible, be 64 bits. time_t should be 64 bits too, but that's another matter. I did just check and DJGPP seems limited to 32bit off_t. So eventually it might have to go back to Usysdep.i3, but ok. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Sun, 4 Jan 2009 15:54:48 +1100CC: m3commit at elegosoft.comSubject: Re: [M3commit] CVS Update: cm3Why not just switch between 32-bit and 64-bit versions. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 4 Jan 2009, at 13:22, Jay wrote: But how about if we always #define _FILE_OFFSET_BITS 64 and use C wrappers? As I have done. Or externs with "64" appended, but that prevents me from using one set of .i3 files. I mean, I know there are "modes" with 32 bit off_t, but we should really strive not to use them, if given a choice, eh? You think there are any systems we will ever care about that don't offer a 64 bit off_t (or off64_t, or whatever). - Jay From: hosking at To: jkrell at Date: Sun, 4 Jan 2009 12:57:28 +1100CC: m3commit at elegosoft.comSubject: Re: [M3commit] CVS Update: cm3On some platforms off_t is not 64 bits. This from Solaris (see off_t==long): #if defined(_LARGEFILE_SOURCE) || defined(_XPG5) #ifndef _OFF_T #define _OFF_T #if defined(_LP64) || _FILE_OFFSET_BITS == 32 typedef long off_t; #else typedef __longlong_t off_t; #endif #ifdef _LARGEFILE64_SOURCE #ifdef _LP64 typedef off_t off64_t; #else typedef __longlong_t off64_t; #endif #endif /* _LARGEFILE64_SOURCE */ #endif /* _OFF_T */ #endif /* _LARGEFILE_SOURCE * Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 4 Jan 2009, at 01:53, Jay Krell wrote: CVSROOT: /usr/cvsChanges by: jkrell at birch. 09/01/04 01:53:03Modified files:cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utypes.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 Log message:significant reduction in sysdep contentoff_t is always 64 bits (or at least let's hope so)the dir/stat flags are mostly all the same,except for a few that are zero on cygwinM[RWX][OWNER GROUP OTHER][FXWR]_OKF_SETFD, F_GETFL, F_SETFLFIONREADITIMER_REALITIMER_VIRTUALSome of this might be by chance and not by-standard,so under review for new platforms, and probably should be verifiedduring native builds.note that OS/2 has a different S_IFMT but not quite relevant here -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Jan 4 11:02:18 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 4 Jan 2009 21:02:18 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20090104005303.84C7110D5E9A@birch.elegosoft.com> <13927A2A-F535-48EB-9A33-4813E2B74442@cs.purdue.edu> <40684423-F337-4C58-BC88-7A0AB7085CF9@cs.purdue.edu> Message-ID: Darwin no longer uses wrapper functions for pread etc. I figured a static switch at build time. On 4 Jan 2009, at 19:35, Jay wrote: > Exactly how? > Like off_t == word? > That isn't right. > > Switch which files? > I want to reduce switching more than what is needed. > Can the string in an extern be "forwarded"? > That would be the ideal granularity here. > Darwin does stuff very similar or maybe the same as I am doing -- > wrapper functions in C for reasons related to off_t, though the > wrappers are a bit dubious, e.g.: > > int m3_pread(int d, void *buf, size_t nbytes, int offset) > { > off_t off = (off_t)offset; > return pread(d, buf, nbytes, offset); > } > > int m3_profil(char *samples, size_t size, u_long offset, u_int scale) > { > off_t off = (off_t)offset; > return profil(samples, size, offset, scale); > } > > int m3_pwrite(int d, const void *buf, size_t nbytes, int offset) > { > off_t off = (off_t)offset; > return pwrite(d, buf, nbytes, offset); > } > > int m3_ftruncate(int fd, int length) > { > off_t len = (off_t) length; > return ftruncate(fd, length); > } > > What does the first line of each of those accomplish? > > void > m3_assignOffT (off_t* dest, long src) > { > *dest = (off_t)src; > } > > Is that widening or narrowing, and if it is narrowing, silent > truncation? > Granted, Modula-3 doesn't check for integer overflow anyway, so > silent truncation I guess is "ok". > > Ideally, every system would have a 64 bit off_t, if not the default, > at least via #defines, or using function names with "64" appended > (or both). The case for 32bit off_t would be interop with existing > code. Otherwise, it seems clear that it should always, if possible, > be 64 bits. time_t should be 64 bits too, but that's another matter. > > I did just check and DJGPP seems limited to 32bit off_t. > So eventually it might have to go back to Usysdep.i3, but ok. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Sun, 4 Jan 2009 15:54:48 +1100 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Why not just switch between 32-bit and 64-bit versions. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > On 4 Jan 2009, at 13:22, Jay wrote: > > But how about if we always #define _FILE_OFFSET_BITS 64 and use C > wrappers? > As I have done. > Or externs with "64" appended, but that prevents me from using one > set of .i3 files. > > I mean, I know there are "modes" with 32 bit off_t, but we should > really strive not to use them, if given a choice, eh? > > You think there are any systems we will ever care about that don't > offer a 64 bit off_t (or off64_t, or whatever). > > - Jay > > > From: hosking@ > To: jkrell@ > Date: Sun, 4 Jan 2009 12:57:28 +1100 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > On some platforms off_t is not 64 bits. This from Solaris (see > off_t==long): > > #if defined(_LARGEFILE_SOURCE) || defined(_XPG5) > #ifndef _OFF_T > #define _OFF_T > #if defined(_LP64) || _FILE_OFFSET_BITS == 32 > typedef long off_t; > #else > typedef __longlong_t off_t; > #endif > #ifdef _LARGEFILE64_SOURCE > #ifdef _LP64 > typedef off_t off64_t; > #else > typedef __longlong_t off64_t; > #endif > #endif /* _LARGEFILE64_SOURCE */ > #endif /* _OFF_T */ > #endif /* _LARGEFILE_SOURCE * > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > On 4 Jan 2009, at 01:53, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/01/04 01:53:03 > > Modified files: > cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utypes.i3 > cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 > > Log message: > significant reduction in sysdep content > > off_t is always 64 bits (or at least let's hope so) > the dir/stat flags are mostly all the same, > except for a few that are zero on cygwin > > M[RWX][OWNER GROUP OTHER] > [FXWR]_OK > F_SETFD, F_GETFL, F_SETFL > FIONREAD > ITIMER_REAL > ITIMER_VIRTUAL > > Some of this might be by chance and not by-standard, > so under review for new platforms, and probably should be verified > during native builds. > > note that OS/2 has a different S_IFMT but not quite relevant here > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Mon Jan 5 04:53:07 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 4:53:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105035307.89FBE220043C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 04:53:07 Modified files: cm3/m3-libs/m3core/src/: Uwaitpid.quake m3makefile cm3/m3-libs/m3core/src/runtime/POSIX/: m3makefile Log message: try again to deal with m3unix.h, perhaps in a way that works with cross bootstrapping From jkrell at elego.de Mon Jan 5 05:19:08 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 5:19:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105041908.CC15010D582F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 05:19:08 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Udir.i3 Uexec.i3 Unetdb.i3 Unix.i3 Uprocess.i3 Upthread.i3 Upwd.i3 Uresource.i3 Usched.i3 Usem.i3 Usignal.i3 Usocket.i3 Ustat.i3 Utime.i3 Uugid.i3 Uuio.i3 Log message: Well, what do you know..I go looking into the compiler for a purpose too much to describe here, and I find that entire interfaces can be marked external, cool. From jkrell at elego.de Mon Jan 5 05:28:20 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 5:28:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105042820.B0BAB10D582F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 05:28:20 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: FilePosix.m3 Log message: remove a few tabs From jkrell at elego.de Mon Jan 5 05:37:13 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 5:37:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105043713.783AD10D5E5B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 05:37:13 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: FilePosix.m3 Log message: reduce but don't eliminate race condition; before there was a race in a multithreaded code, now there is 'only' a race in multithreaded code under optimization that reorders writes (we need MemoryBarrier() for this kind of lock free on demand initialization of globals..) From jkrell at elego.de Mon Jan 5 06:38:01 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 6:38:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105053802.B6F6710D5E65@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 06:38:01 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 Log message: remove a few tabs From jkrell at elego.de Mon Jan 5 06:46:28 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 6:46:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105054628.7E69C10D5E65@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 06:46:28 Modified files: cm3/m3-libs/m3core/src/unix/linux-sparc/: Usocket.i3 Usignal.i3 Log message: make it more like common, for later merge/refactor From jkrell at elego.de Mon Jan 5 07:58:35 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 7:58:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105065835.4E31710D5DD1@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 07:58:35 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile Log message: fix win32, it has its own minimal Unix/Uuio, probably useless From jkrell at elego.de Mon Jan 5 08:25:48 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 8:25:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105072548.AB46610D5D2A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 08:25:48 Modified files: cm3/m3-sys/m3front/src/builtinOps/: Adr.m3 Log message: minor cleanup; should see about switching this? Or removing it? Looks like some indecisiveness and that the switched off way is more type-safe.. From jkrell at elego.de Mon Jan 5 10:37:21 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 10:37:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105093721.E382810D5E7C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 10:37:21 Modified files: cm3/scripts/python/: pylib.py Log message: port CheckForLinkSwitch from scripts/win/sysinfo.cmd, but then, oops, it is redundant, print to make that clearer From jkrell at elego.de Mon Jan 5 10:43:43 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 10:43:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105094343.DA5E110D5E68@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 10:43:43 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Log message: keep the timezone/daylight code out of FreeBSD (tinderbox error) From jkrell at elego.de Mon Jan 5 10:48:34 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 10:48:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105094835.10F7110D5E68@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 10:48:34 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Log message: and NetBSD From jkrell at elego.de Mon Jan 5 10:53:02 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 10:53:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105095302.0802210D5E68@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 10:53:02 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Log message: fix comment From jkrell at elego.de Mon Jan 5 20:10:55 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 20:10:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105191055.CAA2C10D5AF4@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 20:10:55 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: FilePosix.m3 Log message: fix (tinderbox, all posix platforms, I must not have compiled) From jkrell at elego.de Mon Jan 5 20:46:11 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 20:46:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105194611.6CA0B10D5C41@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 20:46:11 Modified files: cm3/m3-libs/m3core/src/runtime/common/: m3makefile Log message: forgot this earlier, only non-mainstream platforms affected From jkrell at elego.de Mon Jan 5 20:54:24 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 20:54:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105195424.0B8ED10D5C41@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 20:54:24 Modified files: cm3/m3-libs/m3core/src/runtime/: m3makefile Removed files: cm3/m3-libs/m3core/src/runtime/AMD64_LINUX/: RTMachine.i3 RTSignal.m3 m3makefile Log message: I thought I commited this last night -- move fairly common files to common directory. Only non-mainstream (so far) platforms affected. RTMachine.i3 might become platform-dependent with user therad support but RTSignal.m3 is quite identical/similar across all platforms, though will shortly be rewritten in C so that we can remove more platform-dependent "cloned headers". From jkrell at elego.de Mon Jan 5 21:04:04 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 21:04:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105200404.B479410D5C41@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 21:04:04 Added files: cm3/m3-libs/m3core/src/runtime/common/: RTMachine.i3 RTSignal.m3 Log message: try try again to add these files (one problem I have is that cvs commit usually crashes on one machine so I have to copy to another) From jkrell at elego.de Mon Jan 5 21:05:33 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 21:05:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105200533.190D110D5C41@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 21:05:33 Added files: cm3/m3-libs/m3core/src/runtime/common/: RTError.h RTProcess.h RTSignalC.c RTSignalC.h m3text.h Log message: work in progress -- rewriting RTSignal.m3 in C saves us from declaring several system-depenedant things in cloned headers, and is easy and portable enough From jkrell at elego.de Mon Jan 5 21:07:51 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 21:07:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105200751.8450810D5C41@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 21:07:51 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTSignal.m3 Log message: the correct version of this -- written in Modula-3 for now From jkrell at elego.de Mon Jan 5 21:33:38 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 21:33:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105203338.0987310D5C41@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 21:33:38 Modified files: cm3/m3-libs/m3core/src/: Uwaitpid.quake Log message: give up on sharing the header and just copy the two lines, alas From jkrell at elego.de Mon Jan 5 23:33:05 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 23:33:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105223305.8F54D10D59A7@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 23:33:05 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTSignal.m3 Log message: fix paste error From jkrell at elego.de Mon Jan 5 23:34:43 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 23:34:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105223443.9EB2610D59A7@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 23:34:43 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTLinkerC.c Log message: remove tab From jkrell at elego.de Tue Jan 6 00:33:06 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 6 Jan 2009 0:33:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105233322.4C3E510D582D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/06 00:33:05 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: fix newline From jkrell at elego.de Tue Jan 6 12:07:04 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 6 Jan 2009 12:07:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090106110704.5AFAC10D5CFC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/06 12:07:04 Modified files: cm3/m3-libs/m3core/src/: Uwaitpid.quake Log message: need sys/types on Linux From jkrell at elego.de Thu Jan 8 01:02:02 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 8 Jan 2009 1:02:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090108000202.8643E904006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/08 01:02:01 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile Log message: sort the list From hosking at elego.de Fri Jan 9 04:43:17 2009 From: hosking at elego.de (Antony Hosking) Date: Fri, 9 Jan 2009 4:43:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090109034317.8FD97220004B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 09/01/09 04:43:17 Modified files: cm3/m3-libs/m3core/src/convert/: CConvert.i3 CConvert.m3 Convert.m3 Log message: Fix space leak in calls to dtoa. The result must be freed using freedtoa. From hosking at elego.de Fri Jan 9 21:43:00 2009 From: hosking at elego.de (Antony Hosking) Date: Fri, 9 Jan 2009 21:43:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090109204300.E5218904007@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 09/01/09 21:43:00 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: dtoa.h Log message: Oops, forgot this which has m3_freedtoa. From jkrell at elego.de Sat Jan 10 14:02:13 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 10 Jan 2009 14:02:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090110130219.4A91790403A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/10 14:02:08 Modified files: cm3/scripts/python/: pylib.py Log message: AMD64_FREEBSD support; put .SUFFIXES in boot makefile to avoid a bunch of warnings about circularity (there is a builtin rule for these suffixes?); add RTSignalC.c to bootstrap packages (if it exists, as usual) From jkrell at elego.de Sat Jan 10 14:36:57 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 10 Jan 2009 14:36:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090110133657.203E810D4E24@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/10 14:36:57 Modified files: cm3/scripts/python/: pylib.py Log message: SPARC64_LINUX needs -Av9 switch on gas to assemble, though the result still hangs (-64 selects 64 bit ELF, -Av9 selects V9 architecture; there is also V9a and V9b, but V9 seems to suffice) From jkrell at elego.de Sun Jan 11 00:19:00 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 0:19:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090110231900.228A5904006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 00:19:00 Modified files: cm3/m3-libs/m3core/src/unix/freebsd-4/: Upthread.i3 Log message: remove unused import to remove warning From jkrell at elego.de Sun Jan 11 00:19:38 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 0:19:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090110231938.7B813904006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 00:19:38 Modified files: cm3/m3-libs/m3core/src/unix/openbsd-common/: m3makefile Log message: Udir not here any longer From jkrell at elego.de Sun Jan 11 00:43:18 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 0:43:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090110234318.24C6010D458D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 00:43:18 Modified files: cm3/m3-libs/m3core/src/runtime/common/: m3text.h RTError.h RTProcess.h RTSignalC.c RTSignalC.h Added files: cm3/m3-libs/m3core/src/runtime/common/: RTSignalC.i3 Log message: add extern "C" prepare for more Usignal reduction and AMD64_FREEBSD port From jkrell at elego.de Sun Jan 11 00:46:42 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 0:46:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090110234642.A060710D458D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 00:46:42 Added files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThreadC.c ThreadPThreadC.i3 Log message: prepare for Usignal reduction and AMD64_FREEBSD port From jkrell at elego.de Sun Jan 11 00:48:55 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 0:48:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090110234855.A764610D535B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 00:48:55 Added files: cm3/m3-sys/cminstall/src/config-no-install/: FreeBSD4 AMD64_FREEBSD Log message: AMD64_FREEBSD support and at least partial FreeBSD4 (for some significant level of verification via cross building) From jkrell at elego.de Sun Jan 11 01:00:38 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 1:00:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111000039.2EB80904006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 01:00:38 Added files: cm3/m3-libs/m3core/src/C/AMD64_FREEBSD/: m3makefile Csetjmp.i3 Log message: add files for AMD64_FREEBSD; diffs later From jkrell at elego.de Sun Jan 11 01:01:15 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 1:01:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111000116.0835A10D5D5D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 01:01:15 Added files: cm3/m3-libs/m3core/src/unix/freebsd-common/: m3makefile Uerror.i3 Usysdep.i3 Uucontext.i3 Log message: add files for AMD64_FREEBSD; diffs later From jkrell at elego.de Sun Jan 11 01:44:47 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 1:44:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111004447.5014E10D535B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 01:44:47 Modified files: cm3/m3-libs/m3core/src/C/PPC_LINUX/: Csetjmp.i3 Log message: remove use of sigset_t so we can prune Usignal; just make the thing properly sized with opaque data; note that it is declared in C as being aligned to 16 bytes but we can't declare that and the comments in the C header say that is ok From jkrell at elego.de Sun Jan 11 01:45:08 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 1:45:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111004509.461AE10D535B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 01:45:08 Modified files: cm3/m3-libs/m3core/src/C/PPC_LINUX/: Csetjmp.i3 Log message: opaque From jkrell at elego.de Sun Jan 11 14:35:04 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 14:35:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111133509.AF03F10D5DA3@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 14:35:04 Modified files: cm3/m3-ui/ui/src/xvbt/: XSharedMem.m3 Log message: workaround fatal error starting up remoted X apps on FreeBSD by cloning underlying function and indicating if it would raise its fatal error; more insight would be welcome here; note that for local X apps (ie: if $DISPLAY is not set) there is no impact, other than allocating a lock From jkrell at elego.de Sun Jan 11 14:50:57 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 14:50:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 14:50:57 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: OSConfigPosix.m3 cm3/m3-libs/libm3/src/random/: m3makefile cm3/m3-libs/m3core/src/: thread.quake cm3/m3-libs/m3core/src/C/Common/: m3makefile cm3/m3-libs/m3core/src/Csupport/: m3makefile cm3/m3-libs/m3core/src/float/: m3makefile cm3/m3-libs/m3core/src/runtime/: m3makefile cm3/m3-libs/m3core/src/runtime/common/: Compiler.tmpl RTLinkerC.c RTMachine.i3 RTSignal.m3 m3makefile cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 ThreadPThreadC.c ThreadPThreadC.i3 m3makefile cm3/m3-libs/m3core/src/time/POSIX/: m3makefile cm3/m3-libs/m3core/src/unix/: m3makefile cm3/m3-libs/m3core/src/unix/Common/: Usem.i3 Usignal.i3 m3makefile cm3/m3-libs/m3core/src/unix/freebsd-common/: Usysdep.i3 m3makefile cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-sparc/: Usignal.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 m3makefile cm3/m3-sys/m3cc/src/: m3makefile cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 cm3/scripts/python/: pylib.py cm3/www/uploaded-archives/: targets.txt Added files: cm3/m3-libs/m3core/src/unix/Common/: Uucontext.i3 Removed files: cm3/m3-libs/m3core/src/unix/freebsd-common/: Uucontext.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Uucontext.i3 Log message: AMD64_FREEBSD port add a few more files to bootstrap archives Usignal reduction, remove: SIGHUP SIGQUIT SIGABRT SIGSEGV SIGPIPE SIGTERM NSIG (Linux specific) SA_RESTART SA_SIGINFO SignalHandler sigset_t siginfo_t_star struct_sigaction (important) sigaction (would be ok, but no longer used) sigdelset (would be ok, but no longer used) sigemptyset (would be ok, but no longer used) sigfillset (would be ok, but no longer used) sigpending (would be ok, but no longer used) sigprocmask (would be ok, but no longer used) make common: SignalActionHandler Uucontext, just ucontext_t_star = ADDRESS; sigset_t removed have Usysdep define SIG_SUSPEND instead of going through Usignal intermediate remove sem_t header clone; declare the variable in C likewise Upthread.mask speculatively add some more targets to m3-sys/m3cc/src/m3makefile, some of which have had backends built, but not all From jkrell at elego.de Sun Jan 11 15:20:14 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 15:20:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111142016.98AB410D5D5D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 15:20:14 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: outputing to _m3.log failing for some reason on SPARC32_LINUX, remove (temporary?) From jkrell at elego.de Sun Jan 11 15:29:16 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 15:29:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111142916.72D7B714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 15:29:16 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 ThreadPThreadC.i3 Log message: Some platforms call SignalActionHandler just 'SignalAction'. Drop the Usignal depdenency and just declare it ourselves here. From jkrell at elego.de Sun Jan 11 15:31:25 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 15:31:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111143125.B7E2B10D5C59@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 15:31:25 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: remove unused import Uucontext From jkrell at elego.de Sun Jan 11 15:32:36 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 15:32:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111143236.2C55B10D5C59@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 15:32:36 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThreadC.c Log message: fix newlines From jkrell at elego.de Sun Jan 11 23:46:40 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 23:46:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111224641.4BD58714574@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 23:46:40 Modified files: cm3/m3-libs/m3core/src/unix/Common/: m3makefile cm3/www/uploaded-archives/: targets.txt Log message: fix newlines From jkrell at elego.de Sun Jan 11 23:48:04 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 23:48:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111224804.5855C714573@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 23:48:04 Modified files: cm3/m3-libs/m3core/src/unix/linux-32/: m3makefile Removed files: cm3/m3-libs/m3core/src/unix/linux-32/: Uucontext.i3 Log message: no more platform specific Uucontext (in some ports) From jkrell at elego.de Mon Jan 12 00:08:24 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 0:08:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111230824.8F8E710D5FAD@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 00:08:24 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: if ROOT is not defined (the root of the source tree), don't probe, rather than erroring for lack of ROOT From jkrell at elego.de Mon Jan 12 00:08:39 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 0:08:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111230839.AEC1910D5FAD@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 00:08:39 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: backwards From jkrell at elego.de Mon Jan 12 00:34:41 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 0:34:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111233442.57DE510D5FB1@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 00:34:41 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThreadC.c Log message: make the assertions actually check each call, not just the first, duh From jkrell at elego.de Mon Jan 12 01:49:11 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 1:49:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112004911.D509F10D5FB5@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 01:49:11 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: SocketPosix.m3 Log message: change switches to if ladders so that Uerror can change constants to variables and replace system dependent cloned headers with portable C From hosking at cs.purdue.edu Mon Jan 12 01:59:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 11:59:07 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20090112004911.D509F10D5FB5@birch.elegosoft.com> References: <20090112004911.D509F10D5FB5@birch.elegosoft.com> Message-ID: <7F816AC4-68DD-4881-97A8-08C973E97E1A@cs.purdue.edu> Jay, I really don't like this. What's wrong with constants again? On 12 Jan 2009, at 01:49, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/01/12 01:49:11 > > Modified files: > cm3/m3-libs/libm3/src/os/POSIX/: SocketPosix.m3 > > Log message: > change switches to if ladders so that Uerror can change constants > to variables and replace system dependent cloned headers with > portable C From jay.krell at cornell.edu Mon Jan 12 07:44:20 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 06:44:20 +0000 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> Message-ID: I basically agree here. I view thread.quake as temporary. Once m3core (that you bootstrap from) has SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. Or some other fix involving sysutils not knowing this (it sounds like you an easy one that I missed). And then the code that is generated when building m3core can be the exact checked in code, was my intention. I guess what I could/should have done is just put in SchedulerPosix.DoesWaitYield, wait some amount of time, and then move sysutils over it, not fix sysutils asap. I can go ahead and do that now -- "fix" m3core, re-"break" (slow down) sysutils, and then at whatever time, have sysutils use the new function. I had noticed cygwin builds seeming to take way way longer than I remember, like >12 hours instead of <1hour. I didn't track down if this is the cause. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:18:29 +1100> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > I really hate the idea that thread.quake exists.> > Screw sysutils working against old m3core versions. sysutils doing > thread-related scheduling is a big hack, and should be killed now > before it infects others. I don't want to see thread-dependent code > outside of m3core. We really need to come to consensus on this before > you do more damage to the core thread libraries.> > I feel strongly about this!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 07:49:55 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 17:49:55 +1100 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> Message-ID: <2599269D-3447-4D5C-8D8B-2A535027EBCF@cs.purdue.edu> Why do you need DoesWaitPidYield? As I mentioned in another post, fixing sysutils to use a properly scheduled version of waitpid is trivial. I don't think you need all this DoesWaitPidYield junk. Frankly, I think the threads code is now a mess and needs to be reverted. On 12 Jan 2009, at 17:44, Jay wrote: > I basically agree here. > I view thread.quake as temporary. > Once m3core (that you bootstrap from) has > SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. > Or some other fix involving sysutils not knowing this (it sounds > like you an easy one that I missed). > > And then the code that is generated when building m3core can be the > exact checked in code, was my intention. > > I guess what I could/should have done is just put in > SchedulerPosix.DoesWaitYield, wait some amount of time, and then > move sysutils over it, not fix sysutils asap. > > I can go ahead and do that now -- "fix" m3core, re-"break" (slow > down) sysutils, and then at whatever time, have sysutils use the new > function. > > I had noticed cygwin builds seeming to take way way longer than I > remember, like >12 hours instead of <1hour. I didn't track down if > this is the cause. > > - Jay > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:18:29 +1100 > > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > I really hate the idea that thread.quake exists. > > > > Screw sysutils working against old m3core versions. sysutils doing > > thread-related scheduling is a big hack, and should be killed now > > before it infects others. I don't want to see thread-dependent code > > outside of m3core. We really need to come to consensus on this > before > > you do more damage to the core thread libraries. > > > > I feel strongly about this! > > > > -- Tony > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 08:01:50 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 07:01:50 +0000 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: <2599269D-3447-4D5C-8D8B-2A535027EBCF@cs.purdue.edu> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <2599269D-3447-4D5C-8D8B-2A535027EBCF@cs.purdue.edu> Message-ID: I need to go back and study that. It implies I missed something big when I made the change. I could have sworn I looked at the functions and decided one could not be implemented on top of the other but it sounds like I missed one. Hold on. DoesWaitPidYield is not the problem really though. We agree, at its worst, it would be cloned, in regular Modula-3 code (not quake). At its best, it would be gone. The bigger change is sharing the SchedulerPosix implementation on Win32 threads for Cygwin. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 17:49:55 +1100CC: m3devel at elegosoft.com; m3commit at elegosoft.comSubject: Re: [M3commit] [M3devel] CVS Update: cm3Why do you need DoesWaitPidYield? As I mentioned in another post, fixing sysutils to use a properly scheduled version of waitpid is trivial. I don't think you need all this DoesWaitPidYield junk. Frankly, I think the threads code is now a mess and needs to be reverted. On 12 Jan 2009, at 17:44, Jay wrote: I basically agree here.I view thread.quake as temporary.Once m3core (that you bootstrap from) has SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. Or some other fix involving sysutils not knowing this (it sounds like you an easy one that I missed). And then the code that is generated when building m3core can be the exact checked in code, was my intention. I guess what I could/should have done is just put in SchedulerPosix.DoesWaitYield, wait some amount of time, and then move sysutils over it, not fix sysutils asap. I can go ahead and do that now -- "fix" m3core, re-"break" (slow down) sysutils, and then at whatever time, have sysutils use the new function. I had noticed cygwin builds seeming to take way way longer than I remember, like >12 hours instead of <1hour. I didn't track down if this is the cause. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:18:29 +1100> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > I really hate the idea that thread.quake exists.> > Screw sysutils working against old m3core versions. sysutils doing > thread-related scheduling is a big hack, and should be killed now > before it infects others. I don't want to see thread-dependent code > outside of m3core. We really need to come to consensus on this before > you do more damage to the core thread libraries.> > I feel strongly about this!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 08:05:48 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 18:05:48 +1100 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <2599269D-3447-4D5C-8D8B-2A535027EBCF@cs.purdue.edu> Message-ID: <7A6A105A-B305-4F14-91D2-1D2DC6F09BEC@cs.purdue.edu> I think the whole DoesWaitPidYield thing is a red herring. Can you just wait for me to put in my fix to the CVS head and you can look and see what you think? I would really like to reinstate the original structure for m3core/src/thread too, but I don't know what the constraints are w.r.to your C header file hacking and the need for Cygwin to have a SchedulerPosix implementation. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 12 Jan 2009, at 18:01, Jay wrote: > I need to go back and study that. It implies I missed something big > when I made the change. > I could have sworn I looked at the functions and decided one could > not be implemented > on top of the other but it sounds like I missed one. Hold on. > > DoesWaitPidYield is not the problem really though. > We agree, at its worst, it would be cloned, in regular Modula-3 code > (not quake). > At its best, it would be gone. > > The bigger change is sharing the SchedulerPosix implementation on > Win32 threads for Cygwin. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 17:49:55 +1100 > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > Subject: Re: [M3commit] [M3devel] CVS Update: cm3 > > Why do you need DoesWaitPidYield? As I mentioned in another post, > fixing sysutils to use a properly scheduled version of waitpid is > trivial. I don't think you need all this DoesWaitPidYield junk. > > Frankly, I think the threads code is now a mess and needs to be > reverted. > > On 12 Jan 2009, at 17:44, Jay wrote: > > I basically agree here. > I view thread.quake as temporary. > Once m3core (that you bootstrap from) has > SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. > Or some other fix involving sysutils not knowing this (it sounds > like you an easy one that I missed). > > And then the code that is generated when building m3core can be the > exact checked in code, was my intention. > > I guess what I could/should have done is just put in > SchedulerPosix.DoesWaitYield, wait some amount of time, and then > move sysutils over it, not fix sysutils asap. > > I can go ahead and do that now -- "fix" m3core, re-"break" (slow > down) sysutils, and then at whatever time, have sysutils use the new > function. > > I had noticed cygwin builds seeming to take way way longer than I > remember, like >12 hours instead of <1hour. I didn't track down if > this is the cause. > > - Jay > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:18:29 +1100 > > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > I really hate the idea that thread.quake exists. > > > > Screw sysutils working against old m3core versions. sysutils doing > > thread-related scheduling is a big hack, and should be killed now > > before it infects others. I don't want to see thread-dependent code > > outside of m3core. We really need to come to consensus on this > before > > you do more damage to the core thread libraries. > > > > I feel strongly about this! > > > > -- Tony > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 08:07:18 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 18:07:18 +1100 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> Message-ID: <66E87543-8486-4377-9405-2912E14CD96E@cs.purdue.edu> PS What is the name ThreadPScheduler supposed to connote? On 12 Jan 2009, at 17:44, Jay wrote: > I basically agree here. > I view thread.quake as temporary. > Once m3core (that you bootstrap from) has > SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. > Or some other fix involving sysutils not knowing this (it sounds > like you an easy one that I missed). > > And then the code that is generated when building m3core can be the > exact checked in code, was my intention. > > I guess what I could/should have done is just put in > SchedulerPosix.DoesWaitYield, wait some amount of time, and then > move sysutils over it, not fix sysutils asap. > > I can go ahead and do that now -- "fix" m3core, re-"break" (slow > down) sysutils, and then at whatever time, have sysutils use the new > function. > > I had noticed cygwin builds seeming to take way way longer than I > remember, like >12 hours instead of <1hour. I didn't track down if > this is the cause. > > - Jay > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:18:29 +1100 > > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > I really hate the idea that thread.quake exists. > > > > Screw sysutils working against old m3core versions. sysutils doing > > thread-related scheduling is a big hack, and should be killed now > > before it infects others. I don't want to see thread-dependent code > > outside of m3core. We really need to come to consensus on this > before > > you do more damage to the core thread libraries. > > > > I feel strongly about this! > > > > -- Tony > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 08:13:35 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 07:13:35 +0000 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: <7A6A105A-B305-4F14-91D2-1D2DC6F09BEC@cs.purdue.edu> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <2599269D-3447-4D5C-8D8B-2A535027EBCF@cs.purdue.edu> <7A6A105A-B305-4F14-91D2-1D2DC6F09BEC@cs.purdue.edu> Message-ID: I can wait but I really don't think this structure is so awful, rehosting one SchedulerPosix implementation on top of two different threading libraries. Maybe just let Cygwin die? Was the restructuring to use "spawn" sometimes instead of fork/exec also so bad? I actually find that hard to read, but it is theoretically a very large improvement.Cygwin really fails badly compared to "Posix" in fork perf, even if the semantic matches. (and vfork, which is what Modula-3 uses, doesn't help. Cygwin's vfork == fork, both slow.) It is contorted also, but you know, we can't use a line by line #ifdef, so we have to break stuff up into separate files, which often seems less clear (but sometimes is more clear, it depends on how much is different and how much the same; the more that is the same, the better to have #ifdef, the more that is different, the better to have separate files). Or, can I replit out SchedulerPosix after you apply your "actual" changes -- you know, just a way to avoid the merge, but keep the contituent diffs? - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:05:48 +1100CC: m3devel at elegosoft.com; m3commit at elegosoft.comSubject: Re: [M3commit] [M3devel] CVS Update: cm3I think the whole DoesWaitPidYield thing is a red herring. Can you just wait for me to put in my fix to the CVS head and you can look and see what you think? I would really like to reinstate the original structure for m3core/src/thread too, but I don't know what the constraints are w.r.to your C header file hacking and the need for Cygwin to have a SchedulerPosix implementation. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 12 Jan 2009, at 18:01, Jay wrote: I need to go back and study that. It implies I missed something big when I made the change.I could have sworn I looked at the functions and decided one could not be implementedon top of the other but it sounds like I missed one. Hold on. DoesWaitPidYield is not the problem really though.We agree, at its worst, it would be cloned, in regular Modula-3 code (not quake).At its best, it would be gone. The bigger change is sharing the SchedulerPosix implementation on Win32 threads for Cygwin. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 17:49:55 +1100CC: m3devel at elegosoft.com; m3commit at elegosoft.comSubject: Re: [M3commit] [M3devel] CVS Update: cm3Why do you need DoesWaitPidYield? As I mentioned in another post, fixing sysutils to use a properly scheduled version of waitpid is trivial. I don't think you need all this DoesWaitPidYield junk. Frankly, I think the threads code is now a mess and needs to be reverted. On 12 Jan 2009, at 17:44, Jay wrote: I basically agree here.I view thread.quake as temporary.Once m3core (that you bootstrap from) has SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. Or some other fix involving sysutils not knowing this (it sounds like you an easy one that I missed). And then the code that is generated when building m3core can be the exact checked in code, was my intention. I guess what I could/should have done is just put in SchedulerPosix.DoesWaitYield, wait some amount of time, and then move sysutils over it, not fix sysutils asap. I can go ahead and do that now -- "fix" m3core, re-"break" (slow down) sysutils, and then at whatever time, have sysutils use the new function. I had noticed cygwin builds seeming to take way way longer than I remember, like >12 hours instead of <1hour. I didn't track down if this is the cause. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:18:29 +1100> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > I really hate the idea that thread.quake exists.> > Screw sysutils working against old m3core versions. sysutils doing > thread-related scheduling is a big hack, and should be killed now > before it infects others. I don't want to see thread-dependent code > outside of m3core. We really need to come to consensus on this before > you do more damage to the core thread libraries.> > I feel strongly about this!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 08:15:41 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 07:15:41 +0000 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: <66E87543-8486-4377-9405-2912E14CD96E@cs.purdue.edu> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <66E87543-8486-4377-9405-2912E14CD96E@cs.purdue.edu> Message-ID: It is ambiguous, I admit. Feel free to suggest another name. It is PosixScheduler.i3 implementation for Cygwin and pthreads. You could call it PosixSchedulerKernel.m3? PosixScheduler.i3 for threads that are kernel threads? You know -- what does "pthreads" mean -- posix threads, but we have ThreadPThread and ThreadPosix. Also wierd. But ok. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:07:18 +1100CC: jkrell at elego.de; m3devel at elegosoft.com; m3commit at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3PS What is the name ThreadPScheduler supposed to connote? On 12 Jan 2009, at 17:44, Jay wrote: I basically agree here.I view thread.quake as temporary.Once m3core (that you bootstrap from) has SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. Or some other fix involving sysutils not knowing this (it sounds like you an easy one that I missed). And then the code that is generated when building m3core can be the exact checked in code, was my intention. I guess what I could/should have done is just put in SchedulerPosix.DoesWaitYield, wait some amount of time, and then move sysutils over it, not fix sysutils asap. I can go ahead and do that now -- "fix" m3core, re-"break" (slow down) sysutils, and then at whatever time, have sysutils use the new function. I had noticed cygwin builds seeming to take way way longer than I remember, like >12 hours instead of <1hour. I didn't track down if this is the cause. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:18:29 +1100> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > I really hate the idea that thread.quake exists.> > Screw sysutils working against old m3core versions. sysutils doing > thread-related scheduling is a big hack, and should be killed now > before it infects others. I don't want to see thread-dependent code > outside of m3core. We really need to come to consensus on this before > you do more damage to the core thread libraries.> > I feel strongly about this!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 08:16:34 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 07:16:34 +0000 Subject: [M3commit] FW: [M3devel] CVS Update: cm3 In-Reply-To: <7A6A105A-B305-4F14-91D2-1D2DC6F09BEC@cs.purdue.edu> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <2599269D-3447-4D5C-8D8B-2A535027EBCF@cs.purdue.edu> <7A6A105A-B305-4F14-91D2-1D2DC6F09BEC@cs.purdue.edu> Message-ID: [important points/question truncated -- request permission to reapply scheduler split after you apply your diff] From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.com; m3commit at elegosoft.comSubject: RE: [M3commit] [M3devel] CVS Update: cm3Date: Mon, 12 Jan 2009 07:13:35 +0000 I can wait but I really don't think this structure is so awful, rehosting one SchedulerPosix implementation on top of two different threading libraries. Maybe just let Cygwin die? Was the restructuring to use "spawn" sometimes instead of fork/exec also so bad?I actually find that hard to read, but it is theoretically a very large improvement.Cygwin really fails badly compared to "Posix" in fork perf, even if the semantic matches.(and vfork, which is what Modula-3 uses, doesn't help. Cygwin's vfork == fork, both slow.) It is contorted also, but you know, we can't use a line by line #ifdef, so we have to break stuff up into separate files, which often seems less clear (but sometimes is more clear, it depends on how much is different and how much the same; the more that is the same, the better to have #ifdef, the more that is different, the better to have separate files). Or, can I replit out SchedulerPosix after you apply your "actual" changes -- you know, just a way to avoid the merge, but keep the contituent diffs? - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:05:48 +1100CC: m3devel at elegosoft.com; m3commit at elegosoft.comSubject: Re: [M3commit] [M3devel] CVS Update: cm3I think the whole DoesWaitPidYield thing is a red herring. Can you just wait for me to put in my fix to the CVS head and you can look and see what you think? I would really like to reinstate the original structure for m3core/src/thread too, but I don't know what the constraints are w.r.to your C header file hacking and the need for Cygwin to have a SchedulerPosix implementation. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 12 Jan 2009, at 18:01, Jay wrote: I need to go back and study that. It implies I missed something big when I made the change.I could have sworn I looked at the functions and decided one could not be implementedon top of the other but it sounds like I missed one. Hold on. DoesWaitPidYield is not the problem really though.We agree, at its worst, it would be cloned, in regular Modula-3 code (not quake).At its best, it would be gone. The bigger change is sharing the SchedulerPosix implementation on Win32 threads for Cygwin. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 17:49:55 +1100CC: m3devel at elegosoft.com; m3commit at elegosoft.comSubject: Re: [M3commit] [M3devel] CVS Update: cm3Why do you need DoesWaitPidYield? As I mentioned in another post, fixing sysutils to use a properly scheduled version of waitpid is trivial. I don't think you need all this DoesWaitPidYield junk. Frankly, I think the threads code is now a mess and needs to be reverted. On 12 Jan 2009, at 17:44, Jay wrote: I basically agree here.I view thread.quake as temporary.Once m3core (that you bootstrap from) has SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. Or some other fix involving sysutils not knowing this (it sounds like you an easy one that I missed). And then the code that is generated when building m3core can be the exact checked in code, was my intention. I guess what I could/should have done is just put in SchedulerPosix.DoesWaitYield, wait some amount of time, and then move sysutils over it, not fix sysutils asap. I can go ahead and do that now -- "fix" m3core, re-"break" (slow down) sysutils, and then at whatever time, have sysutils use the new function. I had noticed cygwin builds seeming to take way way longer than I remember, like >12 hours instead of <1hour. I didn't track down if this is the cause. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:18:29 +1100> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > I really hate the idea that thread.quake exists.> > Screw sysutils working against old m3core versions. sysutils doing > thread-related scheduling is a big hack, and should be killed now > before it infects others. I don't want to see thread-dependent code > outside of m3core. We really need to come to consensus on this before > you do more damage to the core thread libraries.> > I feel strongly about this!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 08:22:31 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 18:22:31 +1100 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <66E87543-8486-4377-9405-2912E14CD96E@cs.purdue.edu> Message-ID: ThreadPosix is a historic name for threads built on top of simple POSIX primitives. The name was given before POSIX pthreads were even defined. ThreadPThread describes an implementation of threads built on top of POSIX pthreads. ThreadWin32 describes an implementation of threads built on top of Win32 threads. SchedulerPosix is indeed a misnomer, but again that name is a historic artefact. On 12 Jan 2009, at 18:15, Jay wrote: > It is ambiguous, I admit. > Feel free to suggest another name. > It is PosixScheduler.i3 implementation for Cygwin and pthreads. > You could call it PosixSchedulerKernel.m3? PosixScheduler.i3 for > threads that are kernel threads? > > You know -- what does "pthreads" mean -- posix threads, but we have > ThreadPThread and ThreadPosix. > Also wierd. But ok. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 18:07:18 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com; m3commit at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > PS What is the name ThreadPScheduler supposed to connote? > > > On 12 Jan 2009, at 17:44, Jay wrote: > > I basically agree here. > I view thread.quake as temporary. > Once m3core (that you bootstrap from) has > SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. > Or some other fix involving sysutils not knowing this (it sounds > like you an easy one that I missed). > > And then the code that is generated when building m3core can be the > exact checked in code, was my intention. > > I guess what I could/should have done is just put in > SchedulerPosix.DoesWaitYield, wait some amount of time, and then > move sysutils over it, not fix sysutils asap. > > I can go ahead and do that now -- "fix" m3core, re-"break" (slow > down) sysutils, and then at whatever time, have sysutils use the new > function. > > I had noticed cygwin builds seeming to take way way longer than I > remember, like >12 hours instead of <1hour. I didn't track down if > this is the cause. > > - Jay > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:18:29 +1100 > > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > I really hate the idea that thread.quake exists. > > > > Screw sysutils working against old m3core versions. sysutils doing > > thread-related scheduling is a big hack, and should be killed now > > before it infects others. I don't want to see thread-dependent code > > outside of m3core. We really need to come to consensus on this > before > > you do more damage to the core thread libraries. > > > > I feel strongly about this! > > > > -- Tony > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Mon Jan 12 08:29:56 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 8:29:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112072956.A51FF10D5FCF@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 08:29:56 Modified files: cm3/m3-libs/sysutils/src/POSIX/: m3makefile Log message: use a relative path instead of the ROOT variable that all the scripts define From jkrell at elego.de Mon Jan 12 08:45:00 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 8:45:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112074500.5B02410D5FD0@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 08:45:00 Modified files: cm3/m3-libs/sysutils/src/POSIX/: m3makefile Added files: cm3/m3-libs/sysutils/src/POSIX/: Sysutils_DoesWaitPidYield.i3 Sysutils_Uwaitpid.c Sysutils_Uwaitpid.i3 Log message: checkin the generated/duplicated code, at least temporarily From jkrell at elego.de Mon Jan 12 08:55:09 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 8:55:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112075509.793CF10D5FD0@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 08:55:09 Modified files: cm3/m3-libs/m3core/src/: thread.quake cm3/m3-libs/m3core/src/unix/Common/: m3makefile Added files: cm3/m3-libs/m3core/src/unix/Common/: Uwaitpid.c Uwaitpid.i3 Removed files: cm3/m3-libs/m3core/src/: Uwaitpid.quake Log message: checkin generated code From hosking at cs.purdue.edu Mon Jan 12 09:13:38 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 19:13:38 +1100 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: <66E87543-8486-4377-9405-2912E14CD96E@cs.purdue.edu> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <66E87543-8486-4377-9405-2912E14CD96E@cs.purdue.edu> Message-ID: <4FC3FD8A-6992-4B4B-97AB-E68F8CA26B4C@cs.purdue.edu> What clients of waitpid actually care about the status bits? On 12 Jan 2009, at 18:07, Tony Hosking wrote: > PS What is the name ThreadPScheduler supposed to connote? > > On 12 Jan 2009, at 17:44, Jay wrote: > >> I basically agree here. >> I view thread.quake as temporary. >> Once m3core (that you bootstrap from) has >> SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. >> Or some other fix involving sysutils not knowing this (it sounds >> like you an easy one that I missed). >> >> And then the code that is generated when building m3core can be the >> exact checked in code, was my intention. >> >> I guess what I could/should have done is just put in >> SchedulerPosix.DoesWaitYield, wait some amount of time, and then >> move sysutils over it, not fix sysutils asap. >> >> I can go ahead and do that now -- "fix" m3core, re-"break" (slow >> down) sysutils, and then at whatever time, have sysutils use the >> new function. >> >> I had noticed cygwin builds seeming to take way way longer than I >> remember, like >12 hours instead of <1hour. I didn't track down if >> this is the cause. >> >> - Jay >> >> > From: hosking at cs.purdue.edu >> > To: jkrell at elego.de >> > Date: Mon, 12 Jan 2009 11:18:29 +1100 >> > CC: m3devel at elegosoft.com; m3commit at elegosoft.com >> > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 >> > >> > I really hate the idea that thread.quake exists. >> > >> > Screw sysutils working against old m3core versions. sysutils doing >> > thread-related scheduling is a big hack, and should be killed now >> > before it infects others. I don't want to see thread-dependent code >> > outside of m3core. We really need to come to consensus on this >> before >> > you do more damage to the core thread libraries. >> > >> > I feel strongly about this! >> > >> > -- Tony >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 09:30:58 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 08:30:58 +0000 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: <4FC3FD8A-6992-4B4B-97AB-E68F8CA26B4C@cs.purdue.edu> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <66E87543-8486-4377-9405-2912E14CD96E@cs.purdue.edu> <4FC3FD8A-6992-4B4B-97AB-E68F8CA26B4C@cs.purdue.edu> Message-ID: Asking me? I don't know. What sysutils does, sort of does. Right? You know -- there is the exit code or the exit signal. It seems to be using roughly (exit signal << 8) | exit code. I tried to "just" read the code (~ two weeks) but I might have read it wrong and I don't remember what I found, only that I meant to retain semantics, except for the efficiency of the wait. I don't think that explains the repacking though. I have to read it again (again, again). That's what m3core was hiding, the exit signal? I'll check. - Jay From: hosking at cs.purdue.eduTo: hosking at cs.purdue.eduDate: Mon, 12 Jan 2009 19:13:38 +1100CC: m3devel at elegosoft.com; m3commit at elegosoft.com; jay.krell at cornell.eduSubject: Re: [M3commit] [M3devel] CVS Update: cm3What clients of waitpid actually care about the status bits? On 12 Jan 2009, at 18:07, Tony Hosking wrote: PS What is the name ThreadPScheduler supposed to connote? On 12 Jan 2009, at 17:44, Jay wrote: I basically agree here.I view thread.quake as temporary.Once m3core (that you bootstrap from) has SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. Or some other fix involving sysutils not knowing this (it sounds like you an easy one that I missed). And then the code that is generated when building m3core can be the exact checked in code, was my intention. I guess what I could/should have done is just put in SchedulerPosix.DoesWaitYield, wait some amount of time, and then move sysutils over it, not fix sysutils asap. I can go ahead and do that now -- "fix" m3core, re-"break" (slow down) sysutils, and then at whatever time, have sysutils use the new function. I had noticed cygwin builds seeming to take way way longer than I remember, like >12 hours instead of <1hour. I didn't track down if this is the cause. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:18:29 +1100> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > I really hate the idea that thread.quake exists.> > Screw sysutils working against old m3core versions. sysutils doing > thread-related scheduling is a big hack, and should be killed now > before it infects others. I don't want to see thread-dependent code > outside of m3core. We really need to come to consensus on this before > you do more damage to the core thread libraries.> > I feel strongly about this!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 09:51:55 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 19:51:55 +1100 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <66E87543-8486-4377-9405-2912E14CD96E@cs.purdue.edu> <4FC3FD8A-6992-4B4B-97AB-E68F8CA26B4C@cs.purdue.edu> Message-ID: Well, I find the repacking somewhat dubious, but without knowing what the clients of Process.Wait and System.Wait expect, perhaps we should leave it that way for now. Certainly, client code that has endian- ness assumptions built in regarding the status value is clearly broken and should be fixed at source, rather than relying on some weird underlying repacking hack. I will retain the current packings. As I understand it, the current contortions are to provide an implementation of SchedulerPosix for Win32 threads platforms like Cygwin that are otherwise POSIX. Correct? On 12 Jan 2009, at 19:30, Jay wrote: > Asking me? I don't know. > What sysutils does, sort of does. Right? > You know -- there is the exit code or the exit signal. > It seems to be using roughly (exit signal << 8) | exit code. > > I tried to "just" read the code (~ two weeks) but I might have read > it wrong and I don't remember what I found, only that I meant to > retain semantics, except for the efficiency of the wait. > > I don't think that explains the repacking though. > I have to read it again (again, again). > > That's what m3core was hiding, the exit signal? > I'll check. > > - Jay > > > From: hosking at cs.purdue.edu > To: hosking at cs.purdue.edu > Date: Mon, 12 Jan 2009 19:13:38 +1100 > CC: m3devel at elegosoft.com; m3commit at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3commit] [M3devel] CVS Update: cm3 > > What clients of waitpid actually care about the status bits? > > > On 12 Jan 2009, at 18:07, Tony Hosking wrote: > > PS What is the name ThreadPScheduler supposed to connote? > > On 12 Jan 2009, at 17:44, Jay wrote: > > I basically agree here. > I view thread.quake as temporary. > Once m3core (that you bootstrap from) has > SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. > Or some other fix involving sysutils not knowing this (it sounds > like you an easy one that I missed). > > And then the code that is generated when building m3core can be the > exact checked in code, was my intention. > > I guess what I could/should have done is just put in > SchedulerPosix.DoesWaitYield, wait some amount of time, and then > move sysutils over it, not fix sysutils asap. > > I can go ahead and do that now -- "fix" m3core, re-"break" (slow > down) sysutils, and then at whatever time, have sysutils use the new > function. > > I had noticed cygwin builds seeming to take way way longer than I > remember, like >12 hours instead of <1hour. I didn't track down if > this is the cause. > > - Jay > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:18:29 +1100 > > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > I really hate the idea that thread.quake exists. > > > > Screw sysutils working against old m3core versions. sysutils doing > > thread-related scheduling is a big hack, and should be killed now > > before it infects others. I don't want to see thread-dependent code > > outside of m3core. We really need to come to consensus on this > before > > you do more damage to the core thread libraries. > > > > I feel strongly about this! > > > > -- Tony > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 10:06:12 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 09:06:12 +0000 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <66E87543-8486-4377-9405-2912E14CD96E@cs.purdue.edu> <4FC3FD8A-6992-4B4B-97AB-E68F8CA26B4C@cs.purdue.edu> Message-ID: Right, the point was to provide a correct seeming SchedulerPosix.i3 on Cygwin, using Win32 threads. It, and NT386 (same code -- ThreadWin32.m3), had a dummy one before. I probably put that dummy in myself without thinking about it. I can't say that I really tested the implementation or measure anything before/after. (in fact, I can say I did not). But it definitely looks better (functionality, not structure). Maybe time to test Cygwin pthreads again? - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 19:51:55 +1100CC: m3devel at elegosoft.com; m3commit at elegosoft.comSubject: Re: [M3commit] [M3devel] CVS Update: cm3 Well, I find the repacking somewhat dubious, but without knowing what the clients of Process.Wait and System.Wait expect, perhaps we should leave it that way for now. Certainly, client code that has endian-ness assumptions built in regarding the status value is clearly broken and should be fixed at source, rather than relying on some weird underlying repacking hack. I will retain the current packings. As I understand it, the current contortions are to provide an implementation of SchedulerPosix for Win32 threads platforms like Cygwin that are otherwise POSIX. Correct? On 12 Jan 2009, at 19:30, Jay wrote: Asking me? I don't know.What sysutils does, sort of does. Right?You know -- there is the exit code or the exit signal.It seems to be using roughly (exit signal << 8) | exit code. I tried to "just" read the code (~ two weeks) but I might have read it wrong and I don't remember what I found, only that I meant to retain semantics, except for the efficiency of the wait. I don't think that explains the repacking though.I have to read it again (again, again). That's what m3core was hiding, the exit signal?I'll check. - Jay From: hosking at cs.purdue.eduTo: hosking at cs.purdue.eduDate: Mon, 12 Jan 2009 19:13:38 +1100CC: m3devel at elegosoft.com; m3commit at elegosoft.com; jay.krell at cornell.eduSubject: Re: [M3commit] [M3devel] CVS Update: cm3What clients of waitpid actually care about the status bits? On 12 Jan 2009, at 18:07, Tony Hosking wrote: PS What is the name ThreadPScheduler supposed to connote? On 12 Jan 2009, at 17:44, Jay wrote: I basically agree here.I view thread.quake as temporary.Once m3core (that you bootstrap from) has SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. Or some other fix involving sysutils not knowing this (it sounds like you an easy one that I missed). And then the code that is generated when building m3core can be the exact checked in code, was my intention. I guess what I could/should have done is just put in SchedulerPosix.DoesWaitYield, wait some amount of time, and then move sysutils over it, not fix sysutils asap. I can go ahead and do that now -- "fix" m3core, re-"break" (slow down) sysutils, and then at whatever time, have sysutils use the new function. I had noticed cygwin builds seeming to take way way longer than I remember, like >12 hours instead of <1hour. I didn't track down if this is the cause. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:18:29 +1100> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > I really hate the idea that thread.quake exists.> > Screw sysutils working against old m3core versions. sysutils doing > thread-related scheduling is a big hack, and should be killed now > before it infects others. I don't want to see thread-dependent code > outside of m3core. We really need to come to consensus on this before > you do more damage to the core thread libraries.> > I feel strongly about this!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at elego.de Mon Jan 12 10:20:33 2009 From: hosking at elego.de (Antony Hosking) Date: Mon, 12 Jan 2009 10:20:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112092033.2748010D5FD1@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 09/01/12 10:20:33 Modified files: cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 ThreadPWait.m3 cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 m3makefile cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile Log message: Try to clean up mess with Process.Wait and System.Wait based on waitpid. Packing is now returned to Process.Wait and System.Wait where it used to be. Not sure if this re-packing is needed by clients, but should verify. From jay.krell at cornell.edu Mon Jan 12 11:11:17 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 10:11:17 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20090112092033.2748010D5FD1@birch.elegosoft.com> References: <20090112092033.2748010D5FD1@birch.elegosoft.com> Message-ID: > relies on particular endian-ness of the status > word they return. Really, those clients should > be using proper bit-shifts and bit-masks to extract > the right values rather than some endian- dependent RECORD layout defined in Uexec Wasn't Uwaitpid.c a good portable way to do exactly that? I guess it can be written in Modula-3 though, if the headers are cloned as they are. Aren't {I386,AMD64}_DARWIN broken here? Besides all "my" ports, which don't define those types. Yeah yeah, all I have to do is switch on endian and I can introduce them.. I'll see about Cygwin pthreads. - Jay> Date: Mon, 12 Jan 2009 10:20:33 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 09/01/12 10:20:33> > Modified files:> cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > ThreadPWait.m3 > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > m3makefile > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > Log message:> Try to clean up mess with Process.Wait and System.Wait based on waitpid.> > Packing is now returned to Process.Wait and System.Wait where it used to be.> > Not sure if this re-packing is needed by clients, but should verify.> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 11:28:10 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 10:28:10 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20090112092033.2748010D5FD1@birch.elegosoft.com> References: <20090112092033.2748010D5FD1@birch.elegosoft.com> Message-ID: Eek, was this really the way to go? It really seemed better before to me. Before it was automatically portable without declaring the packed return type or NOHANG. - Jay From: jay.krell at cornell.eduTo: hosking at elego.de; m3commit at elegosoft.comSubject: RE: [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 10:11:17 +0000 > relies on particular endian-ness of the status > word they return. Really, those clients should > be using proper bit-shifts and bit-masks to extract > the right values rather than some endian- dependent RECORD layout defined in Uexec Wasn't Uwaitpid.c a good portable way to do exactly that? I guess it can be written in Modula-3 though, if the headers are cloned as they are. Aren't {I386,AMD64}_DARWIN broken here? Besides all "my" ports, which don't define those types. Yeah yeah, all I have to do is switch on endian and I can introduce them.. I'll see about Cygwin pthreads. - Jay> Date: Mon, 12 Jan 2009 10:20:33 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 09/01/12 10:20:33> > Modified files:> cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > ThreadPWait.m3 > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > m3makefile > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > Log message:> Try to clean up mess with Process.Wait and System.Wait based on waitpid.> > Packing is now returned to Process.Wait and System.Wait where it used to be.> > Not sure if this re-packing is needed by clients, but should verify.> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Mon Jan 12 11:41:36 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 11:41:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112104136.707C210D5FCF@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 11:41:36 Modified files: cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 Log message: remove unused type to fix warning From hosking at cs.purdue.edu Mon Jan 12 12:25:25 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 22:25:25 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20090112092033.2748010D5FD1@birch.elegosoft.com> Message-ID: <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> On 12 Jan 2009, at 21:11, Jay wrote: > > relies on particular endian-ness of the status > > word they return. Really, those clients should > > be using proper bit-shifts and bit-masks to extract > > the right values rather than some endian- dependent RECORD layout > defined in Uexec > > Wasn't Uwaitpid.c a good portable way to do exactly that? I didn't look too closely at that. I wanted something that retained the simplicity of calling waitpid as: PROCEDURE waitpid(pid: int; VAR status: int; options: int): int; > I guess it can be written in Modula-3 though, if the headers are > cloned as they are. > Aren't {I386,AMD64}_DARWIN broken here? I don't think so -- Uexec is still there. > Besides all "my" ports, which don't define those types. > Yeah yeah, all I have to do is switch on endian and I can introduce > them.. But really, clients of waitpid/SchedulerPosix.WaitProcess should be prepared to shift the status return value correctly! After all, the interface doc for Process.Wait indicates that the return value is the status word. > I'll see about Cygwin pthreads. Yes, it would be a more coherent solution. > > > - Jay > > > Date: Mon, 12 Jan 2009 10:20:33 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 09/01/12 10:20:33 > > > > Modified files: > > cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > > ThreadPWait.m3 > > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > > m3makefile > > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > > > Log message: > > Try to clean up mess with Process.Wait and System.Wait based on > waitpid. > > > > Packing is now returned to Process.Wait and System.Wait where it > used to be. > > > > Not sure if this re-packing is needed by clients, but should verify. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 12:26:01 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 22:26:01 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20090112092033.2748010D5FD1@birch.elegosoft.com> Message-ID: <3F2E7A20-E9AE-4D3D-8262-032F356E0253@cs.purdue.edu> Eek, what? On 12 Jan 2009, at 21:28, Jay wrote: > Eek, was this really the way to go? > It really seemed better before to me. > Before it was automatically portable without declaring the packed > return type or NOHANG. > > - Jay > > > > From: jay.krell at cornell.edu > To: hosking at elego.de; m3commit at elegosoft.com > Subject: RE: [M3commit] CVS Update: cm3 > Date: Mon, 12 Jan 2009 10:11:17 +0000 > > > relies on particular endian-ness of the status > > word they return. Really, those clients should > > be using proper bit-shifts and bit-masks to extract > > the right values rather than some endian- dependent RECORD layout > defined in Uexec > > Wasn't Uwaitpid.c a good portable way to do exactly that? > I guess it can be written in Modula-3 though, if the headers are > cloned as they are. > Aren't {I386,AMD64}_DARWIN broken here? > Besides all "my" ports, which don't define those types. > Yeah yeah, all I have to do is switch on endian and I can introduce > them.. > > I'll see about Cygwin pthreads. > > - Jay > > > Date: Mon, 12 Jan 2009 10:20:33 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 09/01/12 10:20:33 > > > > Modified files: > > cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > > ThreadPWait.m3 > > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > > m3makefile > > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > > > Log message: > > Try to clean up mess with Process.Wait and System.Wait based on > waitpid. > > > > Packing is now returned to Process.Wait and System.Wait where it > used to be. > > > > Not sure if this re-packing is needed by clients, but should verify. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Mon Jan 12 12:28:31 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 12:28:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112112831.5F3C810D5E8B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 12:28:31 Modified files: cm3/m3-libs/m3core/src/unix/big-endian/: m3makefile cm3/m3-libs/m3core/src/unix/little-endian/: m3makefile cm3/m3-libs/m3core/src/unix/Common/: m3makefile Added files: cm3/m3-libs/m3core/src/unix/big-endian/: Uexec.i3 cm3/m3-libs/m3core/src/unix/little-endian/: Uexec.i3 Log message: clone more headers to account for non portable waitpid reintroduction; what was wrong with what was here? Aren't several ports wrong e.g. {I386,AMD64}_DARWIN, PPC_LINUX? I guess the point is to stop anyone from using this data at all, so as to not need to return it one way or the other? From hosking at cs.purdue.edu Mon Jan 12 12:38:46 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 22:38:46 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20090112112831.5F3C810D5E8B@birch.elegosoft.com> References: <20090112112831.5F3C810D5E8B@birch.elegosoft.com> Message-ID: <64BB1AFE-D740-44B8-A576-DDE0125EAB24@cs.purdue.edu> I'm not sure what you mean by the ports being wrong. Can you explain more? On 12 Jan 2009, at 12:28, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/01/12 12:28:31 > > Modified files: > cm3/m3-libs/m3core/src/unix/big-endian/: m3makefile > cm3/m3-libs/m3core/src/unix/little-endian/: m3makefile > cm3/m3-libs/m3core/src/unix/Common/: m3makefile > Added files: > cm3/m3-libs/m3core/src/unix/big-endian/: Uexec.i3 > cm3/m3-libs/m3core/src/unix/little-endian/: Uexec.i3 > > Log message: > clone more headers to account for non portable waitpid > reintroduction; what was wrong with what was here? Aren't several > ports wrong e.g. {I386,AMD64}_DARWIN, PPC_LINUX? I guess the point > is to stop anyone from using this data at all, so as to not need to > return it one way or the other? From hosking at cs.purdue.edu Mon Jan 12 12:41:56 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 22:41:56 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20090112112831.5F3C810D5E8B@birch.elegosoft.com> References: <20090112112831.5F3C810D5E8B@birch.elegosoft.com> Message-ID: <9ADACB4E-1D6A-4FDB-9A63-90BFEBAAB169@cs.purdue.edu> PS I would love to avoid cloning the headers. waitpid would be invocable without any wrapper -- it's up to the client code to interpret the status word properly as needs. On 12 Jan 2009, at 12:28, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/01/12 12:28:31 > > Modified files: > cm3/m3-libs/m3core/src/unix/big-endian/: m3makefile > cm3/m3-libs/m3core/src/unix/little-endian/: m3makefile > cm3/m3-libs/m3core/src/unix/Common/: m3makefile > Added files: > cm3/m3-libs/m3core/src/unix/big-endian/: Uexec.i3 > cm3/m3-libs/m3core/src/unix/little-endian/: Uexec.i3 > > Log message: > clone more headers to account for non portable waitpid > reintroduction; what was wrong with what was here? Aren't several > ports wrong e.g. {I386,AMD64}_DARWIN, PPC_LINUX? I guess the point > is to stop anyone from using this data at all, so as to not need to > return it one way or the other? From hosking at cs.purdue.edu Mon Jan 12 12:42:06 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 22:42:06 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20090112112831.5F3C810D5E8B@birch.elegosoft.com> References: <20090112112831.5F3C810D5E8B@birch.elegosoft.com> Message-ID: PS I would love to avoid cloning the headers. waitpid would be invocable without any wrapper -- it's up to the client code to interpret the status word properly as needs. On 12 Jan 2009, at 12:28, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/01/12 12:28:31 > > Modified files: > cm3/m3-libs/m3core/src/unix/big-endian/: m3makefile > cm3/m3-libs/m3core/src/unix/little-endian/: m3makefile > cm3/m3-libs/m3core/src/unix/Common/: m3makefile > Added files: > cm3/m3-libs/m3core/src/unix/big-endian/: Uexec.i3 > cm3/m3-libs/m3core/src/unix/little-endian/: Uexec.i3 > > Log message: > clone more headers to account for non portable waitpid > reintroduction; what was wrong with what was here? Aren't several > ports wrong e.g. {I386,AMD64}_DARWIN, PPC_LINUX? I guess the point > is to stop anyone from using this data at all, so as to not need to > return it one way or the other? From jay.krell at cornell.edu Mon Jan 12 12:49:32 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 11:49:32 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20090112112831.5F3C810D5E8B@birch.elegosoft.com> Message-ID: [all tangent] This indirectly answers one of my questions perhaps, as to the level of avoiding cloning headers. You have no problem with this level of header cloning: Uexec.i3 <*external*> PROCEDURE waitpid(pid:Utypes.pid_t, status:UNTRACED REF int, int options):int; You know -- 1) the need to define pid_t correctly. 2) The assumption that it is trafficing in int, and not e.g. short or long? "portable enough"? I think maybe so. And even this can be "checked" on native builds, but always used "directly". There is an argument that even something "like this" would benefit from being wrapped in C where we have very tight control over the Modula-3<->C transition. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 22:42:06 +1100> CC: m3commit at elegosoft.com> Subject: Re: [M3commit] CVS Update: cm3> > PS I would love to avoid cloning the headers. waitpid would be > invocable without any wrapper -- it's up to the client code to > interpret the status word properly as needs.> > > On 12 Jan 2009, at 12:28, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 09/01/12 12:28:31> >> > Modified files:> > cm3/m3-libs/m3core/src/unix/big-endian/: m3makefile> > cm3/m3-libs/m3core/src/unix/little-endian/: m3makefile> > cm3/m3-libs/m3core/src/unix/Common/: m3makefile> > Added files:> > cm3/m3-libs/m3core/src/unix/big-endian/: Uexec.i3> > cm3/m3-libs/m3core/src/unix/little-endian/: Uexec.i3> >> > Log message:> > clone more headers to account for non portable waitpid > > reintroduction; what was wrong with what was here? Aren't several > > ports wrong e.g. {I386,AMD64}_DARWIN, PPC_LINUX? I guess the point > > is to stop anyone from using this data at all, so as to not need to > > return it one way or the other?> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 12:53:50 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 11:53:50 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <9ADACB4E-1D6A-4FDB-9A63-90BFEBAAB169@cs.purdue.edu> References: <20090112112831.5F3C810D5E8B@birch.elegosoft.com> <9ADACB4E-1D6A-4FDB-9A63-90BFEBAAB169@cs.purdue.edu> Message-ID: uh oh.I sense a possible big vocabulary difference. There are, indeed, two ways of cloning headers. One way is with super tight fidelity.Declaring the types in Modula-3 to match exactly what it is in the .h files..h files that you don't write yourself, that vary from system to system,and may be full of #ifdefs and hard to read (but sure, preprocess them).This is what I don't like.It is tedious, error prone, dangerous.This is historically what was done. The alternative is, well, also cloning headers.You write your own.But you don't put any #ifdefs in them.You make them easy to read.They are the same for Solaris, Linux, little endian, big endian (no bit fields), etc. The ones you write yourself, you write in both Modula-3 and C.You have your Modula-3 code call your C code, and then your C calls "the OS", viaits headers, that you no longer have to read and clone. This is what I have been doing. In fact, maybe the ones you write yourself you write in xml or some otherconstrained language/schema, and write a tool to spit out Modula .i3 and C .h files. We are on the same page, right? Bad to clone /usr/include. Ok to clone stuff you write yourself. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 22:41:56 +1100> CC: m3commit at elegosoft.com> Subject: Re: [M3commit] CVS Update: cm3> > PS I would love to avoid cloning the headers. waitpid would be > invocable without any wrapper -- it's up to the client code to > interpret the status word properly as needs.> > > On 12 Jan 2009, at 12:28, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 09/01/12 12:28:31> >> > Modified files:> > cm3/m3-libs/m3core/src/unix/big-endian/: m3makefile> > cm3/m3-libs/m3core/src/unix/little-endian/: m3makefile> > cm3/m3-libs/m3core/src/unix/Common/: m3makefile> > Added files:> > cm3/m3-libs/m3core/src/unix/big-endian/: Uexec.i3> > cm3/m3-libs/m3core/src/unix/little-endian/: Uexec.i3> >> > Log message:> > clone more headers to account for non portable waitpid > > reintroduction; what was wrong with what was here? Aren't several > > ports wrong e.g. {I386,AMD64}_DARWIN, PPC_LINUX? I guess the point > > is to stop anyone from using this data at all, so as to not need to > > return it one way or the other?> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 12:55:39 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 11:55:39 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <64BB1AFE-D740-44B8-A576-DDE0125EAB24@cs.purdue.edu> References: <20090112112831.5F3C810D5E8B@birch.elegosoft.com> <64BB1AFE-D740-44B8-A576-DDE0125EAB24@cs.purdue.edu> Message-ID: I believe: linux-libc6 defines the little endian types. PPC_LINUX is wrong. darwin-generic defines the big endian types. I386_DARWIN and AMD64_DARWIN are wrong. All the platforms I have been hammering on don't define any of the types. My Uwaitpid.c was "automatically" correct for any platform. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 22:38:46 +1100> CC: m3commit at elegosoft.com> Subject: Re: [M3commit] CVS Update: cm3> > I'm not sure what you mean by the ports being wrong. Can you explain > more?> > On 12 Jan 2009, at 12:28, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 09/01/12 12:28:31> >> > Modified files:> > cm3/m3-libs/m3core/src/unix/big-endian/: m3makefile> > cm3/m3-libs/m3core/src/unix/little-endian/: m3makefile> > cm3/m3-libs/m3core/src/unix/Common/: m3makefile> > Added files:> > cm3/m3-libs/m3core/src/unix/big-endian/: Uexec.i3> > cm3/m3-libs/m3core/src/unix/little-endian/: Uexec.i3> >> > Log message:> > clone more headers to account for non portable waitpid > > reintroduction; what was wrong with what was here? Aren't several > > ports wrong e.g. {I386,AMD64}_DARWIN, PPC_LINUX? I guess the point > > is to stop anyone from using this data at all, so as to not need to > > return it one way or the other?> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 12:58:34 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 11:58:34 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <3F2E7A20-E9AE-4D3D-8262-032F356E0253@cs.purdue.edu> References: <20090112092033.2748010D5FD1@birch.elegosoft.com> <3F2E7A20-E9AE-4D3D-8262-032F356E0253@cs.purdue.edu> Message-ID: Eek using the packed types in Uexec.i3 instead of my portable Uwaitpid.i3, Uwaitpid.c that unpacked everything into a whole number of bytes (no bit fields or shifting for the caller to wory about), and formed the value that I believe the loopholes were historically getting. A big part of the change. - Jay CC: hosking at elego.de; m3commit at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 22:26:01 +1100 Eek, what? On 12 Jan 2009, at 21:28, Jay wrote: Eek, was this really the way to go?It really seemed better before to me.Before it was automatically portable without declaring the packed return type or NOHANG. - Jay From: jay.krell at cornell.eduTo: hosking at elego.de; m3commit at elegosoft.comSubject: RE: [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 10:11:17 +0000 > relies on particular endian-ness of the status > word they return. Really, those clients should > be using proper bit-shifts and bit-masks to extract > the right values rather than some endian- dependent RECORD layout defined in Uexec Wasn't Uwaitpid.c a good portable way to do exactly that? I guess it can be written in Modula-3 though, if the headers are cloned as they are. Aren't {I386,AMD64}_DARWIN broken here? Besides all "my" ports, which don't define those types. Yeah yeah, all I have to do is switch on endian and I can introduce them.. I'll see about Cygwin pthreads. - Jay> Date: Mon, 12 Jan 2009 10:20:33 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 09/01/12 10:20:33> > Modified files:> cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > ThreadPWait.m3 > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > m3makefile > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > Log message:> Try to clean up mess with Process.Wait and System.Wait based on waitpid.> > Packing is now returned to Process.Wait and System.Wait where it used to be.> > Not sure if this re-packing is needed by clients, but should verify.> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 13:08:29 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 12:08:29 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> References: <20090112092033.2748010D5FD1@birch.elegosoft.com> <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> Message-ID: Hm. So I guess the point then is to return one "reasonable" integer, and "reasonable" is actually defined as (coredump << 15) | (termsig << 8) | exitcode That's the point of the repacking? and coredump and termsig are usually 0. Anyway, I don't think even this 7/1/8/16 split is specified by Posix. Right? Uwaitpid.c was a good portable method I think. It was based on the example code in online Posix docs (which you originally pointed me to). - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 22:25:25 +1100CC: m3commit at elegosoft.comSubject: Re: [M3commit] CVS Update: cm3 On 12 Jan 2009, at 21:11, Jay wrote: > relies on particular endian-ness of the status > word they return. Really, those clients should > be using proper bit-shifts and bit-masks to extract > the right values rather than some endian- dependent RECORD layout defined in Uexec Wasn't Uwaitpid.c a good portable way to do exactly that? I didn't look too closely at that. I wanted something that retained the simplicity of calling waitpid as: PROCEDURE waitpid(pid: int; VAR status: int; options: int): int; I guess it can be written in Modula-3 though, if the headers are cloned as they are. Aren't {I386,AMD64}_DARWIN broken here? I don't think so -- Uexec is still there. Besides all "my" ports, which don't define those types. Yeah yeah, all I have to do is switch on endian and I can introduce them.. But really, clients of waitpid/SchedulerPosix.WaitProcess should be prepared to shift the status return value correctly! After all, the interface doc for Process.Wait indicates that the return value is the status word. I'll see about Cygwin pthreads. Yes, it would be a more coherent solution. - Jay> Date: Mon, 12 Jan 2009 10:20:33 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 09/01/12 10:20:33> > Modified files:> cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > ThreadPWait.m3 > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > m3makefile > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > Log message:> Try to clean up mess with Process.Wait and System.Wait based on waitpid.> > Packing is now returned to Process.Wait and System.Wait where it used to be.> > Not sure if this re-packing is needed by clients, but should verify.> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Mon Jan 12 13:26:56 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 13:26:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112122656.AE89510D5FD1@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 13:26:56 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Log message: fix cygwin From jkrell at elego.de Mon Jan 12 14:25:27 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 14:25:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112132528.0CA6310D4E24@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 14:25:27 Modified files: cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 Log message: Convert errno case to 'if ladder' so we can use auto-ported C variables instead of port-requiring constants From jkrell at elego.de Mon Jan 12 14:44:25 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 14:44:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112134425.CEA0C10D5F24@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 14:44:25 Modified files: cm3/m3-libs/m3core/src/unix/Common/: m3makefile cm3/m3-libs/m3core/src/unix/linux-common/: m3makefile cm3/m3-libs/m3core/src/unix/linux-sparc/: m3makefile cm3/m3-libs/m3core/src/unix/openbsd-common/: m3makefile Added files: cm3/m3-libs/m3core/src/unix/Common/: Uerror.c Uerror.i3 UerrorX.h Removed files: cm3/m3-libs/m3core/src/unix/linux-common/: Uerror.i3 cm3/m3-libs/m3core/src/unix/linux-sparc/: Uerror.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Uerror.i3 Log message: move to portable rendition of Uerror for now exclude Cygwin From jkrell at elego.de Mon Jan 12 14:46:18 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 14:46:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112134618.2D79510D5F24@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 14:46:18 Modified files: cm3/m3-libs/m3core/src/unix/freebsd-common/: m3makefile Removed files: cm3/m3-libs/m3core/src/unix/freebsd-common/: Uerror.i3 Log message: this one too From jkrell at elego.de Mon Jan 12 15:09:08 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 15:09:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112140908.77D4E10D5F28@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 15:09:08 Modified files: cm3/m3-libs/m3core/src/C/PPC_LINUX/: Csetjmp.i3 Log message: remove unused import From hosking at cs.purdue.edu Mon Jan 12 01:18:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 11:18:29 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> Message-ID: I really hate the idea that thread.quake exists. Screw sysutils working against old m3core versions. sysutils doing thread-related scheduling is a big hack, and should be killed now before it infects others. I don't want to see thread-dependent code outside of m3core. We really need to come to consensus on this before you do more damage to the core thread libraries. I feel strongly about this! -- Tony From jkrell at elego.de Mon Jan 12 15:49:07 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 15:49:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112144907.B25CC10D5F28@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 15:49:07 Modified files: cm3/m3-comm/tcp/src/POSIX/: TCP.m3 Log message: convert another case on errno to an 'if ladder' so that CONST can be VAR for auto-porting From hosking at cs.purdue.edu Mon Jan 12 21:23:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 13 Jan 2009 07:23:29 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20090112092033.2748010D5FD1@birch.elegosoft.com> <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> Message-ID: I guess I'd like to get rid of the re-packing and fix the clients instead. On 12 Jan 2009, at 23:08, Jay wrote: > Hm. So I guess the point then is to return one "reasonable" integer, > and > "reasonable" is actually defined as > > (coredump << 15) | (termsig << 8) | exitcode > > That's the point of the repacking? > and coredump and termsig are usually 0. > > Anyway, I don't think even this 7/1/8/16 split is specified by > Posix. Right? > Uwaitpid.c was a good portable method I think. > It was based on the example code in online Posix docs (which you > originally pointed me to). > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 22:25:25 +1100 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > On 12 Jan 2009, at 21:11, Jay wrote: > > > relies on particular endian-ness of the status > > word they return. Really, those clients should > > be using proper bit-shifts and bit-masks to extract > > the right values rather than some endian- dependent RECORD layout > defined in Uexec > > Wasn't Uwaitpid.c a good portable way to do exactly that? > > I didn't look too closely at that. I wanted something that retained > the simplicity of calling waitpid as: > > PROCEDURE waitpid(pid: int; VAR status: int; options: int): int; > > I guess it can be written in Modula-3 though, if the headers are > cloned as they are. > Aren't {I386,AMD64}_DARWIN broken here? > > I don't think so -- Uexec is still there. > > Besides all "my" ports, which don't define those types. > Yeah yeah, all I have to do is switch on endian and I can introduce > them.. > > But really, clients of waitpid/SchedulerPosix.WaitProcess should be > prepared to shift the status return value correctly! After all, the > interface doc for Process.Wait indicates that the return value is > the status word. > > I'll see about Cygwin pthreads. > > Yes, it would be a more coherent solution. > > > > - Jay > > > Date: Mon, 12 Jan 2009 10:20:33 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 09/01/12 10:20:33 > > > > Modified files: > > cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > > ThreadPWait.m3 > > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > > m3makefile > > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > > > Log message: > > Try to clean up mess with Process.Wait and System.Wait based on > waitpid. > > > > Packing is now returned to Process.Wait and System.Wait where it > used to be. > > > > Not sure if this re-packing is needed by clients, but should verify. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 21:34:38 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 13 Jan 2009 07:34:38 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20090112092033.2748010D5FD1@birch.elegosoft.com> <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> Message-ID: <54C1E71A-CCCD-4E09-9426-A0F300402858@cs.purdue.edu> I guess I'd like to get rid of the re-packing and fix the clients instead. On 12 Jan 2009, at 23:08, Jay wrote: > Hm. So I guess the point then is to return one "reasonable" integer, > and > "reasonable" is actually defined as > > (coredump << 15) | (termsig << 8) | exitcode > > That's the point of the repacking? > and coredump and termsig are usually 0. > > Anyway, I don't think even this 7/1/8/16 split is specified by > Posix. Right? > Uwaitpid.c was a good portable method I think. > It was based on the example code in online Posix docs (which you > originally pointed me to). > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 22:25:25 +1100 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > On 12 Jan 2009, at 21:11, Jay wrote: > > > relies on particular endian-ness of the status > > word they return. Really, those clients should > > be using proper bit-shifts and bit-masks to extract > > the right values rather than some endian- dependent RECORD layout > defined in Uexec > > Wasn't Uwaitpid.c a good portable way to do exactly that? > > I didn't look too closely at that. I wanted something that retained > the simplicity of calling waitpid as: > > PROCEDURE waitpid(pid: int; VAR status: int; options: int): int; > > I guess it can be written in Modula-3 though, if the headers are > cloned as they are. > Aren't {I386,AMD64}_DARWIN broken here? > > I don't think so -- Uexec is still there. > > Besides all "my" ports, which don't define those types. > Yeah yeah, all I have to do is switch on endian and I can introduce > them.. > > But really, clients of waitpid/SchedulerPosix.WaitProcess should be > prepared to shift the status return value correctly! After all, the > interface doc for Process.Wait indicates that the return value is > the status word. > > I'll see about Cygwin pthreads. > > Yes, it would be a more coherent solution. > > > > - Jay > > > Date: Mon, 12 Jan 2009 10:20:33 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 09/01/12 10:20:33 > > > > Modified files: > > cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > > ThreadPWait.m3 > > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > > m3makefile > > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > > > Log message: > > Try to clean up mess with Process.Wait and System.Wait based on > waitpid. > > > > Packing is now returned to Process.Wait and System.Wait where it > used to be. > > > > Not sure if this re-packing is needed by clients, but should verify. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Mon Jan 12 23:42:28 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 23:42:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112224228.13F7110D5EBC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 23:42:28 Modified files: cm3/m3-sys/cminstall/src/config/: NT386.common Log message: Ship and statically link to Uerror.obj IF it exists, it will exist after I finish investigating cygwin/pthreads. Data cannot be dynamically linked on Win32 without more work. The really portable solution is to use functions, but that is not source compatible and I'm reluctant, but maybe.. From hosking at elego.de Tue Jan 13 00:46:03 2009 From: hosking at elego.de (Antony Hosking) Date: Tue, 13 Jan 2009 0:46:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112234604.07A6110D5DAA@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 09/01/13 00:46:03 Modified files: cm3/m3-libs/m3core/src/thread/: m3makefile cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 cm3/m3-libs/m3core/src/thread/WIN32/: m3makefile Added files: cm3/m3-libs/m3core/src/thread/WIN32/: SchedulerPosix.m3 ThreadInternal.i3 Removed files: cm3/m3-libs/m3core/src/thread/: ThreadInternal.i3 ThreadPScheduler.m3 ThreadPWait.m3 Log message: Restore the coherence of the thread packages (keeping code for different thread implementations together, and avoiding smearing across implementations). The only weird hybrid (which should in probably anyway use PTHREAD instead of WIN32) is CygWin. Keep the mess created by this hybrid in the WIN32 implementation where it belongs rather than complicating all the other pure pthread-based implementations. From jay.krell at cornell.edu Tue Jan 13 06:50:43 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 13 Jan 2009 05:50:43 +0000 Subject: [M3commit] waitpit In-Reply-To: <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> References: <20090112092033.2748010D5FD1@birch.elegosoft.com> <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> Message-ID: I think "what I was missing" here is the option of changing the Process.Wait or SchedulerPosix.WaitProcess interface to return the status bits. I don't think this is how it was before, (which I think was implied). Maybe I misread it, between returning the pid/success vs. the status word? I had added the new interface SchedulerPosix.DoesWaitPidYield, but left others asis. Now, true, I'm arguing both sides, since I did make Uerror.i3 incompatible with some clients. Exposing more information like that seems a good solution, leaving the next level down to waitpid(0) or waitpid(nohang). I think user threads are missing some code now, since ThreadPWait (but not ThreadPScheduler) was used by them. But I admit, I didn't build them either, so whether they worked or not, and whether I kept them working or not, don't know. They are never build by default. I think the problem with the encoded exit status it is just a bit "wierd", and hardly anyone would want to use it asis. The repacked value makes more sense? Slightly? Hm..how about this...? interface Uexec; <*external Uexec_WIFEXITED> PROCEDURE WIFEXITED(int status):BOOLEAN; etc. the various other macros/functions in Posix, well, at least two or three of them, the ones that access the relevant fields. Uexec.c typedef size_t BOOLEAN; /* ? safe at least, to return a full word's worth of bits */ #define TRUE 1 #define FALSE 1 BOOLEAN Uexec_WIFEEXITED(int status) { return WIFEEXITED(status) ? TRUE : FALSE; } That fits one of the molds well imho. I like what I had in Uwaitpid, but it is hard to argue for it vs. this. They are very similar. This has the advantage of only returning what is asked for. Uwaitpid had the advantage of probably being faster -- less storage efficient, but fewer function calls / roundtrips and such, since WIFEEXITED is likely a macro and Modula-3 loses the inlining. Surely not a big deal either way. Both options are very portable. Then, the rejiggering/repacking of the bits can be done portably, without regard to endiannness and without regard to the bitfield layout of the int; the bitfields can go away, leaving just the int to be unpacked by these macros-wrapped-in-functions. (I believe it is portable defined as an int but I'll check). Ok? - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3commit at elegosoft.comSubject: RE: [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 12:08:29 +0000 Hm. So I guess the point then is to return one "reasonable" integer, and"reasonable" is actually defined as (coredump << 15) | (termsig << 8) | exitcode That's the point of the repacking?and coredump and termsig are usually 0. Anyway, I don't think even this 7/1/8/16 split is specified by Posix. Right?Uwaitpid.c was a good portable method I think.It was based on the example code in online Posix docs (which you originally pointed me to). - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 22:25:25 +1100CC: m3commit at elegosoft.comSubject: Re: [M3commit] CVS Update: cm3 On 12 Jan 2009, at 21:11, Jay wrote: > relies on particular endian-ness of the status > word they return. Really, those clients should > be using proper bit-shifts and bit-masks to extract > the right values rather than some endian- dependent RECORD layout defined in Uexec Wasn't Uwaitpid.c a good portable way to do exactly that? I didn't look too closely at that. I wanted something that retained the simplicity of calling waitpid as: PROCEDURE waitpid(pid: int; VAR status: int; options: int): int; I guess it can be written in Modula-3 though, if the headers are cloned as they are. Aren't {I386,AMD64}_DARWIN broken here? I don't think so -- Uexec is still there. Besides all "my" ports, which don't define those types. Yeah yeah, all I have to do is switch on endian and I can introduce them.. But really, clients of waitpid/SchedulerPosix.WaitProcess should be prepared to shift the status return value correctly! After all, the interface doc for Process.Wait indicates that the return value is the status word. I'll see about Cygwin pthreads. Yes, it would be a more coherent solution. - Jay> Date: Mon, 12 Jan 2009 10:20:33 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 09/01/12 10:20:33> > Modified files:> cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > ThreadPWait.m3 > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > m3makefile > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > Log message:> Try to clean up mess with Process.Wait and System.Wait based on waitpid.> > Packing is now returned to Process.Wait and System.Wait where it used to be.> > Not sure if this re-packing is needed by clients, but should verify.> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at elego.de Tue Jan 13 08:03:37 2009 From: hosking at elego.de (Antony Hosking) Date: Tue, 13 Jan 2009 8:03:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113070337.ACE1E10D5D11@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 09/01/13 08:03:37 Modified files: cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosix.m3 Log message: Repair ThreadPosix.m3 as well. Forgot to do this earlier. From hosking at elego.de Tue Jan 13 08:07:56 2009 From: hosking at elego.de (Antony Hosking) Date: Tue, 13 Jan 2009 8:07:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113070756.93F3C10D5D11@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 09/01/13 08:07:56 Modified files: cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosix.m3 Log message: Fix syntax error and restore Delay constant. What about just calling Yield instead of Delay to get better performance at the expense of niceness w.r.to other processes? From jkrell at elego.de Tue Jan 13 12:06:25 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 12:06:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113110625.72EB710D5F41@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 12:06:25 Modified files: cm3/m3-libs/m3core/src/unix/ultrix-3-1.SEQUENT/: m3makefile cm3/m3-libs/m3core/src/unix/ultrix-3-1.SUN3/: m3makefile cm3/m3-libs/m3core/src/unix/ultrix-3-1.SUN386/: m3makefile cm3/m3-libs/m3core/src/unix/ultrix-3-1.UMAX/: m3makefile cm3/m3-libs/m3core/src/unix/ultrix-3-1.VAX/: m3makefile cm3/m3-libs/m3core/src/unix/sunos-4-x/: m3makefile cm3/m3-libs/m3core/src/unix/sysv-4.0/: m3makefile cm3/m3-libs/m3core/src/unix/ultrix-3-1.AP3000/: m3makefile cm3/m3-libs/m3core/src/unix/ultrix-3-1.ARM/: m3makefile cm3/m3-libs/m3core/src/unix/ultrix-3-1.DS3100/: m3makefile cm3/m3-libs/m3core/src/unix/ultrix-3-1.NEXT/: m3makefile cm3/m3-libs/m3core/src/unix/linux-libc6/: m3makefile cm3/m3-libs/m3core/src/unix/little-endian/: m3makefile cm3/m3-libs/m3core/src/unix/netbsd2-i386/: m3makefile cm3/m3-libs/m3core/src/unix/os2/: m3makefile cm3/m3-libs/m3core/src/unix/osf-1.generic/: m3makefile cm3/m3-libs/m3core/src/unix/solaris-2-x/: m3makefile cm3/m3-libs/m3core/src/unix/aix-3-2/: m3makefile cm3/m3-libs/m3core/src/unix/aix-ps2-1-2/: m3makefile cm3/m3-libs/m3core/src/unix/big-endian/: m3makefile cm3/m3-libs/m3core/src/unix/darwin-generic/: m3makefile cm3/m3-libs/m3core/src/unix/freebsd-1/: m3makefile cm3/m3-libs/m3core/src/unix/freebsd-2/: m3makefile cm3/m3-libs/m3core/src/unix/freebsd-3/: m3makefile cm3/m3-libs/m3core/src/unix/freebsd-4/: m3makefile cm3/m3-libs/m3core/src/unix/hpux-7-0/: m3makefile cm3/m3-libs/m3core/src/unix/ibm-4-3/: m3makefile cm3/m3-libs/m3core/src/unix/irix-5.2/: m3makefile cm3/m3-libs/m3core/src/unix/linux/: m3makefile cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 Removed files: cm3/m3-libs/m3core/src/unix/ultrix-3-1.SEQUENT/: Uexec.i3 cm3/m3-libs/m3core/src/unix/ultrix-3-1.SUN3/: Uexec.i3 cm3/m3-libs/m3core/src/unix/ultrix-3-1.SUN386/: Uexec.i3 cm3/m3-libs/m3core/src/unix/ultrix-3-1.UMAX/: Uexec.i3 cm3/m3-libs/m3core/src/unix/ultrix-3-1.VAX/: Uexec.i3 cm3/m3-libs/m3core/src/unix/sunos-4-x/: Uexec.i3 cm3/m3-libs/m3core/src/unix/sysv-4.0/: Uexec.i3 cm3/m3-libs/m3core/src/unix/ultrix-3-1.AP3000/: Uexec.i3 cm3/m3-libs/m3core/src/unix/ultrix-3-1.ARM/: Uexec.i3 cm3/m3-libs/m3core/src/unix/ultrix-3-1.DS3100/: Uexec.i3 cm3/m3-libs/m3core/src/unix/ultrix-3-1.NEXT/: Uexec.i3 cm3/m3-libs/m3core/src/unix/linux-libc6/: Uexec.i3 cm3/m3-libs/m3core/src/unix/little-endian/: Uexec.i3 cm3/m3-libs/m3core/src/unix/netbsd2-i386/: Uexec.i3 cm3/m3-libs/m3core/src/unix/os2/: Uexec.i3 cm3/m3-libs/m3core/src/unix/osf-1.generic/: Uexec.i3 cm3/m3-libs/m3core/src/unix/solaris-2-x/: Uexec.i3 cm3/m3-libs/m3core/src/unix/aix-3-2/: Uexec.i3 cm3/m3-libs/m3core/src/unix/aix-ps2-1-2/: Uexec.i3 cm3/m3-libs/m3core/src/unix/big-endian/: Uexec.i3 cm3/m3-libs/m3core/src/unix/darwin-generic/: Uexec.i3 cm3/m3-libs/m3core/src/unix/freebsd-1/: Uexec.i3 cm3/m3-libs/m3core/src/unix/freebsd-2/: Uexec.i3 cm3/m3-libs/m3core/src/unix/freebsd-3/: Uexec.i3 cm3/m3-libs/m3core/src/unix/freebsd-4/: Uexec.i3 cm3/m3-libs/m3core/src/unix/hpux-7-0/: Uexec.i3 cm3/m3-libs/m3core/src/unix/ibm-4-3/: Uexec.i3 cm3/m3-libs/m3core/src/unix/irix-5.2/: Uexec.i3 cm3/m3-libs/m3core/src/unix/linux/: Uexec.i3 Log message: make it portable From jkrell at elego.de Tue Jan 13 12:09:39 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 12:09:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113110939.1EEE010D5DA1@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 12:09:39 Removed files: cm3/m3-libs/m3core/src/unix/Common/: Uwaitpid.i3 Uwaitpid.c Log message: and delete these too From jkrell at elego.de Tue Jan 13 12:59:29 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 12:59:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113115929.1B8B410D5F41@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 12:59:29 Modified files: cm3/m3-libs/m3core/src/unix/Common/: m3makefile Log message: forgot to commit this (cvs commit isn't commiting anything I have to manually list files; granted, cvs diff would have shown me) From jkrell at elego.de Tue Jan 13 13:01:30 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 13:01:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113120135.1F0BD10D5F5B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 13:01:30 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Uexec.i3 Added files: cm3/m3-libs/m3core/src/unix/Common/: Uexec.c Log message: and these From jkrell at elego.de Tue Jan 13 13:22:44 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 13:22:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113122244.8FAEB714573@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 13:22:44 Modified files: cm3/m3-libs/m3core/src/win32/: WinNT.i3 Log message: fix warning on large numbers by using unsigned From jkrell at elego.de Tue Jan 13 13:28:49 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 13:28:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113122849.4C70B10D4EAA@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 13:28:49 Removed files: cm3/m3-libs/sysutils/src/POSIX/: Sysutils_DoesWaitPidYield.i3 Sysutils_Uwaitpid.c Sysutils_Uwaitpid.i3 Log message: and delete these From jkrell at elego.de Tue Jan 13 13:30:33 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 13:30:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113123036.AD5F610D5F41@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 13:30:33 Modified files: cm3/m3-sys/cminstall/src/config/: NT386.common Log message: fix copy/paste error, no effect as long as cygwin using win32 threads From jkrell at elego.de Tue Jan 13 14:47:16 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 14:47:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113134716.7367910D5FCD@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 14:47:16 Modified files: cm3/m3-libs/m3core/src/Csupport/libgcc/: libgcc.c Log message: Quash warning on Darwin about libgcc.o having no symbols, by introducing an arbitrary symbol. From jkrell at elego.de Tue Jan 13 15:20:19 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 15:20:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113142019.7A93010D5FD0@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 15:20:19 Modified files: cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 Log message: both my change and Tony's change are 'difficult' to bootstrap; cut the dependency from sysutils to newer m3core, somewhat sleazily; this should be changed as indicated once newer m3core is well established, or maybe, again, by copying code From jkrell at elego.de Tue Jan 13 15:24:05 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 15:24:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113142405.CC98710D5FD0@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 15:24:05 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Log message: fix for Darwin (10.4) From jkrell at elego.de Tue Jan 13 15:24:59 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 15:24:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113142459.7953810D5FD0@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 15:24:59 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Usignal.i3 Log message: fix line endings From jkrell at elego.de Tue Jan 13 15:33:28 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 15:33:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113143328.E9B7D10D5359@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 15:33:28 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 ThreadPThreadC.c ThreadPThreadC.i3 cm3/m3-libs/m3core/src/unix/Common/: Usignal.i3 m3makefile Removed files: cm3/m3-libs/m3core/src/unix/Common/: Usem.i3 Log message: Darwin tools didn't like these variables, something about common variables and shared/dynamic libs. Possibly merely initializing them would fix this, however there was also the nagging problem of the incorrect type declarations, which arguably could be fixed by just removing them and declaring the variables to be ints. Anyway, the solution here is /very/ portable, mechanical, and a little contorted. Uses of sem_* and sigsuspend are moved into small C wrappers. The global variables they operate on are implied at the Modula-3 level. From jkrell at elego.de Tue Jan 13 15:39:13 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 15:39:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113143913.0DC1910D5359@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 15:39:13 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: PPC_DARWIN Log message: share a bunch of code From jay.krell at cornell.edu Wed Jan 14 00:59:30 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 13 Jan 2009 23:59:30 +0000 Subject: [M3commit] waitpit In-Reply-To: <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> References: <20090112092033.2748010D5FD1@birch.elegosoft.com> <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> Message-ID: > I think "what I was missing" here is the option of changing the Process.Wait or > SchedulerPosix.WaitProcess interface to return the status bits. I don't think this > is how it was before, (which I think was implied). It looks like I added SchedulerPosix.WaitProcess only in 2008, while fixing the inefficient waitpid in libm3, so it wasn't some long standing interface, and changing it very reasonable. Had I only noticed sysutils at the time, I /might/ have thought to define it the way you did. (Still the bootstrap issue, neither WaitProcess signature is in older m3core.) - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3commit at elegosoft.comSubject: RE: waitpitDate: Tue, 13 Jan 2009 05:50:43 +0000 I think "what I was missing" here is the option of changing the Process.Wait or SchedulerPosix.WaitProcess interface to return the status bits. I don't think this is how it was before, (which I think was implied).Maybe I misread it, between returning the pid/success vs. the status word?I had added the new interface SchedulerPosix.DoesWaitPidYield, but left others asis.Now, true, I'm arguing both sides, since I did make Uerror.i3 incompatible with some clients.Exposing more information like that seems a good solution, leaving the next level down to waitpid(0) or waitpid(nohang).I think user threads are missing some code now, since ThreadPWait (but not ThreadPScheduler) was used by them. But I admit, I didn't build them either, so whether they worked or not, and whether I kept them working or not, don't know. They are never build by default. I think the problem with the encoded exit status it is just a bit "wierd", and hardly anyone would want to use it asis.The repacked value makes more sense? Slightly?Hm..how about this...? interface Uexec; <*external Uexec_WIFEXITED> PROCEDURE WIFEXITED(int status):BOOLEAN;etc. the various other macros/functions in Posix, well, at least two or three of them, theones that access the relevant fields. Uexec.c typedef size_t BOOLEAN; /* ? safe at least, to return a full word's worth of bits */ #define TRUE 1 #define FALSE 1 BOOLEAN Uexec_WIFEEXITED(int status) { return WIFEEXITED(status) ? TRUE : FALSE; } That fits one of the molds well imho.I like what I had in Uwaitpid, but it is hard to argue for it vs. this.They are very similar.This has the advantage of only returning what is asked for.Uwaitpid had the advantage of probably being faster -- less storage efficient, but fewer function calls / roundtrips and such, since WIFEEXITED is likely a macro and Modula-3 loses the inlining. Surely not a big deal either way. Both options are very portable. Then, the rejiggering/repacking of the bits can be done portably, without regard to endiannness and without regard to the bitfield layout of the int; the bitfields can go away, leaving just the int to be unpacked by these macros-wrapped-in-functions. (I believe it is portable defined as an int but I'll check). Ok? - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3commit at elegosoft.comSubject: RE: [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 12:08:29 +0000 Hm. So I guess the point then is to return one "reasonable" integer, and"reasonable" is actually defined as (coredump << 15) | (termsig << 8) | exitcode That's the point of the repacking?and coredump and termsig are usually 0. Anyway, I don't think even this 7/1/8/16 split is specified by Posix. Right?Uwaitpid.c was a good portable method I think.It was based on the example code in online Posix docs (which you originally pointed me to). - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 22:25:25 +1100CC: m3commit at elegosoft.comSubject: Re: [M3commit] CVS Update: cm3 On 12 Jan 2009, at 21:11, Jay wrote: > relies on particular endian-ness of the status > word they return. Really, those clients should > be using proper bit-shifts and bit-masks to extract > the right values rather than some endian- dependent RECORD layout defined in Uexec Wasn't Uwaitpid.c a good portable way to do exactly that? I didn't look too closely at that. I wanted something that retained the simplicity of calling waitpid as: PROCEDURE waitpid(pid: int; VAR status: int; options: int): int; I guess it can be written in Modula-3 though, if the headers are cloned as they are. Aren't {I386,AMD64}_DARWIN broken here? I don't think so -- Uexec is still there. Besides all "my" ports, which don't define those types. Yeah yeah, all I have to do is switch on endian and I can introduce them.. But really, clients of waitpid/SchedulerPosix.WaitProcess should be prepared to shift the status return value correctly! After all, the interface doc for Process.Wait indicates that the return value is the status word. I'll see about Cygwin pthreads. Yes, it would be a more coherent solution. - Jay> Date: Mon, 12 Jan 2009 10:20:33 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 09/01/12 10:20:33> > Modified files:> cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > ThreadPWait.m3 > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > m3makefile > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > Log message:> Try to clean up mess with Process.Wait and System.Wait based on waitpid.> > Packing is now returned to Process.Wait and System.Wait where it used to be.> > Not sure if this re-packing is needed by clients, but should verify.> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 14 01:25:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 14 Jan 2009 11:25:07 +1100 Subject: [M3commit] waitpit In-Reply-To: References: <20090112092033.2748010D5FD1@birch.elegosoft.com> <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> Message-ID: <164AB63E-E3CA-4E08-B15B-9F78F2B648B9@cs.purdue.edu> Yeah, that's right. I think we should still ensure that clients of Process.Wait and System.Wait don't do anything more than check the non- zero status value that they return. I suspect the packing was there to ensure that current clients were able to do that reliably (are there systems that encode non-zero successful exit status for processes?). Hmm. On 14 Jan 2009, at 10:59, Jay wrote: > > I think "what I was missing" here is the option of changing the > Process.Wait or > > SchedulerPosix.WaitProcess interface to return the status bits. > I don't think this > > is how it was before, (which I think was implied). > > It looks like I added SchedulerPosix.WaitProcess only in 2008, while > fixing the inefficient waitpid in libm3, > so it wasn't some long standing interface, and changing it very > reasonable. > Had I only noticed sysutils at the time, I /might/ have thought to > define it the way you did. > (Still the bootstrap issue, neither WaitProcess signature is in > older m3core.) > > - Jay > > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3commit at elegosoft.com > Subject: RE: waitpit > Date: Tue, 13 Jan 2009 05:50:43 +0000 > > I think "what I was missing" here is the option of changing the > Process.Wait or SchedulerPosix.WaitProcess interface to return the > status bits. I don't think this is how it was before, (which I think > was implied). > Maybe I misread it, between returning the pid/success vs. the status > word? > I had added the new interface SchedulerPosix.DoesWaitPidYield, but > left others asis. > Now, true, I'm arguing both sides, since I did make Uerror.i3 > incompatible with some clients. > Exposing more information like that seems a good solution, leaving > the next level down to waitpid(0) or waitpid(nohang). > I think user threads are missing some code now, since ThreadPWait > (but not ThreadPScheduler) was used by them. But I admit, I didn't > build them either, so whether they worked or not, and whether I kept > them working or not, don't know. They are never build by default. > > I think the problem with the encoded exit status it is just a bit > "wierd", and hardly anyone would want to use it asis. > The repacked value makes more sense? Slightly? > Hm..how about this...? > > > interface Uexec; > > <*external Uexec_WIFEXITED> PROCEDURE WIFEXITED(int status):BOOLEAN; > etc. the various other macros/functions in Posix, well, at least two > or three of them, the > ones that access the relevant fields. > > Uexec.c > typedef size_t BOOLEAN; /* ? safe at least, to return a full > word's worth of bits */ > #define TRUE 1 > #define FALSE 1 > > BOOLEAN Uexec_WIFEEXITED(int status) > { > return WIFEEXITED(status) ? TRUE : FALSE; > } > > That fits one of the molds well imho. > I like what I had in Uwaitpid, but it is hard to argue for it vs. > this. > They are very similar. > This has the advantage of only returning what is asked for. > Uwaitpid had the advantage of probably being faster -- less storage > efficient, but fewer function calls / roundtrips and such, since > WIFEEXITED is likely a macro and Modula-3 loses the inlining. Surely > not a big deal either way. Both options are very portable. > > Then, the rejiggering/repacking of the bits can be done portably, > without regard to endiannness and without regard to the bitfield > layout of the int; the bitfields can go away, leaving just the int > to be unpacked by these macros-wrapped-in-functions. (I believe it > is portable defined as an int but I'll check). > > Ok? > > - Jay > > > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3commit at elegosoft.com > Subject: RE: [M3commit] CVS Update: cm3 > Date: Mon, 12 Jan 2009 12:08:29 +0000 > > Hm. So I guess the point then is to return one "reasonable" integer, > and > "reasonable" is actually defined as > > (coredump << 15) | (termsig << 8) | exitcode > > That's the point of the repacking? > and coredump and termsig are usually 0. > > Anyway, I don't think even this 7/1/8/16 split is specified by > Posix. Right? > Uwaitpid.c was a good portable method I think. > It was based on the example code in online Posix docs (which you > originally pointed me to). > > - Jay > > > > > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 22:25:25 +1100 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > > > On 12 Jan 2009, at 21:11, Jay wrote: > > > relies on particular endian-ness of the status > > word they return. Really, those clients should > > be using proper bit-shifts and bit-masks to extract > > the right values rather than some endian- dependent RECORD layout > defined in Uexec > > Wasn't Uwaitpid.c a good portable way to do exactly that? > > I didn't look too closely at that. I wanted something that retained > the simplicity of calling waitpid as: > > PROCEDURE waitpid(pid: int; VAR status: int; options: int): int; > > I guess it can be written in Modula-3 though, if the headers are > cloned as they are. > Aren't {I386,AMD64}_DARWIN broken here? > > I don't think so -- Uexec is still there. > > Besides all "my" ports, which don't define those types. > Yeah yeah, all I have to do is switch on endian and I can introduce > them.. > > But really, clients of waitpid/SchedulerPosix.WaitProcess should be > prepared to shift the status return value correctly! After all, the > interface doc for Process.Wait indicates that the return value is > the status word. > > I'll see about Cygwin pthreads. > > Yes, it would be a more coherent solution. > > > > - Jay > > > Date: Mon, 12 Jan 2009 10:20:33 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 09/01/12 10:20:33 > > > > Modified files: > > cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > > ThreadPWait.m3 > > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > > m3makefile > > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > > > Log message: > > Try to clean up mess with Process.Wait and System.Wait based on > waitpid. > > > > Packing is now returned to Process.Wait and System.Wait where it > used to be. > > > > Not sure if this re-packing is needed by clients, but should verify. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 14 00:45:23 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 14 Jan 2009 10:45:23 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20090113142019.7A93010D5FD0@birch.elegosoft.com> References: <20090113142019.7A93010D5FD0@birch.elegosoft.com> Message-ID: <034D3CBF-C0D2-46F6-9F82-1DA6737D1A7B@cs.purdue.edu> I don't see what's difficult to bootstrap here. Why do you need to build against old m3core? On 13 Jan 2009, at 15:20, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/01/13 15:20:19 > > Modified files: > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 > > Log message: > both my change and Tony's change are 'difficult' to bootstrap; cut > the dependency from sysutils to newer m3core, somewhat sleazily; > this should be changed as indicated once newer m3core is well > established, or maybe, again, by copying code From jay.krell at cornell.edu Wed Jan 14 03:42:42 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 14 Jan 2009 02:42:42 +0000 Subject: [M3commit] waitpid In-Reply-To: <164AB63E-E3CA-4E08-B15B-9F78F2B648B9@cs.purdue.edu> References: <20090112092033.2748010D5FD1@birch.elegosoft.com> <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> <164AB63E-E3CA-4E08-B15B-9F78F2B648B9@cs.purdue.edu> Message-ID: > (are there systems that encode non-zero successful exit status for processes?). Hmm. I don't know, but I read that Posix says something like "zero is zero". Like, if child process calls exit(0) or _exit(0), then the full int status will be 0 (even if only 8 bits of exit's parameter are preserved). I thought I read long ago that VMS inverted the meaning, but then C development libraries had to reinvert it for source compatibility. Maybe I'll know better when I bring Modula-3 on VMS back. :) Whatever I was reading gave EXIT_SUCCESS and EXIT_FAILURE as the only portable values...but certainly there is plenty of hardcoded exit(0), thus the theoretically compat hacks. Nevertheless, a "rich" exit code has its uses. Like "number of files copies" or such various common conditions. But maybe we don't care. > I suspect the packing was there to ensure that current clients were able to do that reliably I don't follow. Do you mean, like, guarding against "zero is not zero", such as, like, the filler being "random"? I'll try poke around. In the meantime, see Uexec.RepackStatus that I put in? And definitely look at what I did to ThreadPThread. Perhaps too contorted. Perhaps declare ackSem and mask as arbibrary int and the relevant functions taking ADDRESS, and see if initializing the variables with { 0 } will fix the problem I had on Darwin. Or, if not, I can put in accessor functions for the globals, leaving them static. That'll surely work, didn't think of it till just now. ps: The Darwin PPC 10.4 dylibs don't have make/get/set/swapcontext either. I think I checked both System.dylib and libc.dylib. A "hybrid" where some platforms use setjmp/long and some use context is probably ok. A larger issue here..another thread... - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Wed, 14 Jan 2009 11:25:07 +1100CC: m3commit at elegosoft.comSubject: Re: [M3commit] waitpit Yeah, that's right. I think we should still ensure that clients of Process.Wait and System.Wait don't do anything more than check the non-zero status value that they return. I suspect the packing was there to ensure that current clients were able to do that reliably (are there systems that encode non-zero successful exit status for processes?). Hmm. On 14 Jan 2009, at 10:59, Jay wrote: > I think "what I was missing" here is the option of changing the Process.Wait or > SchedulerPosix.WaitProcess interface to return the status bits. I don't think this > is how it was before, (which I think was implied). It looks like I added SchedulerPosix.WaitProcess only in 2008, while fixing the inefficient waitpid in libm3,so it wasn't some long standing interface, and changing it very reasonable.Had I only noticed sysutils at the time, I /might/ have thought to define it the way you did.(Still the bootstrap issue, neither WaitProcess signature is in older m3core.) - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3commit at elegosoft.comSubject: RE: waitpitDate: Tue, 13 Jan 2009 05:50:43 +0000I think "what I was missing" here is the option of changing the Process.Wait or SchedulerPosix.WaitProcess interface to return the status bits. I don't think this is how it was before, (which I think was implied).Maybe I misread it, between returning the pid/success vs. the status word?I had added the new interface SchedulerPosix.DoesWaitPidYield, but left others asis.Now, true, I'm arguing both sides, since I did make Uerror.i3 incompatible with some clients.Exposing more information like that seems a good solution, leaving the next level down to waitpid(0) or waitpid(nohang).I think user threads are missing some code now, since ThreadPWait (but not ThreadPScheduler) was used by them. But I admit, I didn't build them either, so whether they worked or not, and whether I kept them working or not, don't know. They are never build by default. I think the problem with the encoded exit status it is just a bit "wierd", and hardly anyone would want to use it asis.The repacked value makes more sense? Slightly?Hm..how about this...? interface Uexec; <*external Uexec_WIFEXITED> PROCEDURE WIFEXITED(int status):BOOLEAN;etc. the various other macros/functions in Posix, well, at least two or three of them, theones that access the relevant fields. Uexec.c typedef size_t BOOLEAN; /* ? safe at least, to return a full word's worth of bits */ #define TRUE 1 #define FALSE 1 BOOLEAN Uexec_WIFEEXITED(int status) { return WIFEEXITED(status) ? TRUE : FALSE; } That fits one of the molds well imho.I like what I had in Uwaitpid, but it is hard to argue for it vs. this.They are very similar.This has the advantage of only returning what is asked for.Uwaitpid had the advantage of probably being faster -- less storage efficient, but fewer function calls / roundtrips and such, since WIFEEXITED is likely a macro and Modula-3 loses the inlining. Surely not a big deal either way. Both options are very portable. Then, the rejiggering/repacking of the bits can be done portably, without regard to endiannness and without regard to the bitfield layout of the int; the bitfields can go away, leaving just the int to be unpacked by these macros-wrapped-in-functions. (I believe it is portable defined as an int but I'll check). Ok? - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3commit at elegosoft.comSubject: RE: [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 12:08:29 +0000Hm. So I guess the point then is to return one "reasonable" integer, and"reasonable" is actually defined as (coredump << 15) | (termsig << 8) | exitcode That's the point of the repacking?and coredump and termsig are usually 0. Anyway, I don't think even this 7/1/8/16 split is specified by Posix. Right?Uwaitpid.c was a good portable method I think.It was based on the example code in online Posix docs (which you originally pointed me to). - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 22:25:25 +1100CC: m3commit at elegosoft.comSubject: Re: [M3commit] CVS Update: cm3 On 12 Jan 2009, at 21:11, Jay wrote: > relies on particular endian-ness of the status > word they return. Really, those clients should > be using proper bit-shifts and bit-masks to extract > the right values rather than some endian- dependent RECORD layout defined in Uexec Wasn't Uwaitpid.c a good portable way to do exactly that? I didn't look too closely at that. I wanted something that retained the simplicity of calling waitpid as: PROCEDURE waitpid(pid: int; VAR status: int; options: int): int; I guess it can be written in Modula-3 though, if the headers are cloned as they are. Aren't {I386,AMD64}_DARWIN broken here? I don't think so -- Uexec is still there. Besides all "my" ports, which don't define those types. Yeah yeah, all I have to do is switch on endian and I can introduce them.. But really, clients of waitpid/SchedulerPosix.WaitProcess should be prepared to shift the status return value correctly! After all, the interface doc for Process.Wait indicates that the return value is the status word. I'll see about Cygwin pthreads. Yes, it would be a more coherent solution. - Jay> Date: Mon, 12 Jan 2009 10:20:33 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 09/01/12 10:20:33> > Modified files:> cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > ThreadPWait.m3 > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > m3makefile > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > Log message:> Try to clean up mess with Process.Wait and System.Wait based on waitpid.> > Packing is now returned to Process.Wait and System.Wait where it used to be.> > Not sure if this re-packing is needed by clients, but should verify.> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jan 14 03:48:48 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 14 Jan 2009 02:48:48 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <034D3CBF-C0D2-46F6-9F82-1DA6737D1A7B@cs.purdue.edu> References: <20090113142019.7A93010D5FD0@birch.elegosoft.com> <034D3CBF-C0D2-46F6-9F82-1DA6737D1A7B@cs.purdue.edu> Message-ID: I didn't check for PPC_DARWIN has Tinderbox outputs, so I was bootstrapping from the latest release -- 5.5. If I was desparate I could bootstrap cross. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Wed, 14 Jan 2009 10:45:23 +1100> CC: m3commit at elegosoft.com> Subject: Re: [M3commit] CVS Update: cm3> > I don't see what's difficult to bootstrap here. Why do you need to > build against old m3core?> > On 13 Jan 2009, at 15:20, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 09/01/13 15:20:19> >> > Modified files:> > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3> >> > Log message:> > both my change and Tony's change are 'difficult' to bootstrap; cut > > the dependency from sysutils to newer m3core, somewhat sleazily; > > this should be changed as indicated once newer m3core is well > > established, or maybe, again, by copying code> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 14 05:34:43 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 14 Jan 2009 15:34:43 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20090113142019.7A93010D5FD0@birch.elegosoft.com> <034D3CBF-C0D2-46F6-9F82-1DA6737D1A7B@cs.purdue.edu> Message-ID: There used to PPC_DARWIN Tinderbox, but my machines at home are packed up in my basement... You should be able to use the bootstrap files from ftp://ftp.cs.purdue.edu/m3/PPC_DARWIN . I have AMD64_DARWIN there too. On 14 Jan 2009, at 13:48, Jay wrote: > I didn't check for PPC_DARWIN has Tinderbox outputs, so I was > bootstrapping from the latest release -- 5.5. > If I was desparate I could bootstrap cross. > > - Jay > > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Wed, 14 Jan 2009 10:45:23 +1100 > > CC: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > I don't see what's difficult to bootstrap here. Why do you need to > > build against old m3core? > > > > On 13 Jan 2009, at 15:20, Jay Krell wrote: > > > > > CVSROOT: /usr/cvs > > > Changes by: jkrell at birch. 09/01/13 15:20:19 > > > > > > Modified files: > > > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 > > > > > > Log message: > > > both my change and Tony's change are 'difficult' to bootstrap; cut > > > the dependency from sysutils to newer m3core, somewhat sleazily; > > > this should be changed as indicated once newer m3core is well > > > established, or maybe, again, by copying code > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Wed Jan 14 10:34:21 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jan 2009 10:34:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090114093421.6DE5A10D5EC8@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/14 10:34:20 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Uexec.c Unix.i3 Ustat.i3 m3makefile Added files: cm3/m3-libs/m3core/src/unix/Common/: Uconstants.c Removed files: cm3/m3-libs/m3core/src/unix/Common/: Uerror.c Log message: Move all constants-implemented-as-variables to one file dedicated to them -- Uconstants.c. This way we don't have to keep picking up nickels and dimes on platforms that need to statically link to them (cygwin), and we keep functions and data separate. Not all of the constants in this file are yet active, but they are ok to be there ahead of time. More will migrate here soon. We should perhaps rely on Posix mandating some of the values, or perhaps that some of the values happen to be identical on all platforms, and then make them consts, or we can just play it very safe and err toward making them variables. As well we will look into removing their uses behind C wrappers. From jkrell at elego.de Wed Jan 14 10:36:24 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jan 2009 10:36:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090114093625.1A75D10D5EC8@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/14 10:36:24 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Uconstants.c Log message: add more #includes so it compiles From jkrell at elego.de Mon Jan 19 06:14:26 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 6:14:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119051426.3D5A2714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 06:14:26 Added files: cm3/scripts/: config.c Log message: something like autoconf; sniffs a bunch about a system, though not yet for example the pthread initializers or the exact layout of struct tm From jkrell at elego.de Mon Jan 19 06:34:40 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 6:34:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119053442.3656E10D5F16@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 06:34:40 Modified files: cm3/scripts/: config.c Log message: some cleanup and improvements From jkrell at elego.de Mon Jan 19 10:43:40 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 10:43:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119094340.2D0CB714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 10:43:40 Modified files: cm3/scripts/: config.c Log message: demonstrate start of 'fully dynamic struct reconstitution', at least for structs composed of particular types; this could be developed into a more complete struct declaration cloner, but I don't think we'll need it From jkrell at elego.de Mon Jan 19 11:03:19 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 11:03:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119100319.D1009714573@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 11:03:19 Modified files: cm3/scripts/: config.c Log message: output struct linger, though again, probably will just use more C wrappers instead From jkrell at elego.de Mon Jan 19 11:19:12 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 11:19:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119101912.850EF714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 11:19:12 Modified files: cm3/scripts/: config.c Log message: support CC and CFLAGS environment variables, not clear if we should still try -lpthread and -Werror, or if we should split the 'possible' array between binary name and flags, and then probe only whichever is not an environment variable; really should support command line switches too but none of this likely matters much From jkrell at elego.de Mon Jan 19 12:11:28 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 12:11:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119111128.61BBA10D5F2E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 12:11:28 Modified files: cm3/m3-comm/tcp/src/POSIX/: IP.m3 Log message: let Unetdb.TRY_AGAIN, NO_RECOVERY, NO_ADDRESS be constant variables initialized in C instead of constants, for easier portability; alternatively, move this lone use to C From jkrell at elego.de Mon Jan 19 12:16:10 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 12:16:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119111610.827C4714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 12:16:10 Modified files: cm3/m3-comm/tcp/src/POSIX/: TCP.m3 Log message: convert a few tabs to spaces From jkrell at elego.de Mon Jan 19 14:05:50 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 14:05:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119130550.E9B272200076@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 14:05:50 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: ProcessCygwin.m3 Log message: fix newlines From jkrell at elego.de Mon Jan 19 14:09:15 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 14:09:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119130917.67F06744003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 14:09:15 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: FSPosix.m3 FilePosix.m3 SocketPosix.m3 Log message: allow for more constants to be constant variables initialized in C to reduce header cloning From jkrell at elego.de Mon Jan 19 14:09:39 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 14:09:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119130940.64A5810D4C64@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 14:09:39 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 Log message: allow for more constants to be constant variables initialized in C to reduce header cloning From jkrell at elego.de Mon Jan 19 14:31:32 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 14:31:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119133133.3C1CF10D5ECA@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 14:31:32 Modified files: cm3/m3-libs/m3core/src/C/NT386/: Csetjmp.i3 Log message: fix newlines From jkrell at elego.de Mon Jan 19 14:32:45 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 14:32:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119133246.059EC72575C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 14:32:45 Modified files: cm3/m3-libs/m3core/src/C/NT386/: Csetjmp.i3 Log message: Don't trash the stack on Cygwin when using pthreads; the usual suspect, how did I miss it..? From jkrell at elego.de Mon Jan 19 14:40:43 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 14:40:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119134043.977C610D5ECA@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 14:40:43 Modified files: cm3/m3-libs/m3core/src/thread/WIN32/: m3makefile Log message: fix NT386; maybe more surgery here once Cygwin uses pthreads From jkrell at elego.de Mon Jan 19 14:47:15 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 14:47:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119134715.2B80410D5F14@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 14:47:15 Modified files: cm3/scripts/python/: pylib.py Log message: verbosity tweaks From jkrell at elego.de Mon Jan 19 15:59:04 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 15:59:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119145904.4816F10D5F14@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 15:59:04 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Uconstants.c Log message: Prepare to move a bunch of constants to constant variables. Content can be added here ahead of the use, assuming there are no global namespace clashes. Also mechanize some of the tedium here. From jkrell at elego.de Mon Jan 19 16:03:29 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 16:03:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119150329.D00582200008@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 16:03:29 Removed files: cm3/m3-libs/m3core/src/unix/Common/: Uerror.i3.cpp Uutsname.i3.cpp cm3/m3-libs/m3core/src/unix/cygwin/: Unix.i3.cpp Utypes.i3.cpp 1.cmd cm3/m3-libs/m3core/src/unix/openbsd-common/: 1.cpp 1.sh Log message: delete files that used to be used to help clone headers but which are no longer used since other better tactics have been adopted From jkrell at elego.de Mon Jan 19 16:05:21 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 16:05:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119150521.6ED3D10D5F14@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 16:05:21 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Uexec.i3 Unix.i3 UnixC.c Ustat.i3 Log message: Fix newlines. From jkrell at elego.de Mon Jan 19 16:57:22 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 16:57:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119155722.BD24710D5F30@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 16:57:22 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile cm3/m3-libs/m3core/src/unix/Common/: Uconstants.c Uexec.c Unetdb.i3 Unix.i3 Upthread.i3 Uresource.i3 Usignal.i3 Usocket.i3 Ustat.i3 Utime.i3 Utypes.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 m3makefile cm3/m3-libs/m3core/src/unix/freebsd-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 cm3/m3-sys/cminstall/src/config/: NT386.common Removed files: cm3/m3-libs/m3core/src/unix/cygwin/: 1.c Uerror.i3 Usignal.i3 Usignal.i3.c Ustat.i3 cm3/m3-libs/m3core/src/unix/linux-sparc/: Usignal.i3 Usocket.i3 m3makefile Log message: add Cygwin Upthread support, to be used very soon move a lot of constants out of cloned headers and into constant variables in C Upthread.i3 remove commented out pthread_mutexattr_t, pthread_condattr_t for now, we always pass NULL destructor_t is always the same start_routine_t is always the same move PTHREAD_MUTEX_INITIALIZER, PTHREAD_COND_INITIALIZER to be constant variables in C Unix.i3 move constants to constant C variables: O_RDONLY O_RDWR O_CREAT O_EXCL O_TRUNC O_NONBLOCK Usignal.i3: move constants to constant C variables: SIGINT SIGKILL Usocket.i3: move constants to constant C variables: SOCK_STREAM SOCK_DGRAM SO_REUSEADDR SO_KEEPALIVE SO_LINGER SOL_SOCKET AF_INET MSG_PEEK Utypes.i3: clock_t is never used; remove it Uresource.i3: move constant RUSAGE_SELF to constant C variable Unetdb.i3 move constants to constant C variables: TRY_AGAIN NO_RECOVERY NO_ADDRESS as part of this then, we can delete linux-sparc and some cygwin files, leaving only Usysdep.i3 in openbsd-common, cygwin, linux-common, freebsd-common From jkrell at elego.de Mon Jan 19 17:01:33 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 17:01:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119160134.05AE910D5F74@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 17:01:33 Modified files: cm3/m3-libs/m3core/src/unix/Common/: m3makefile Log message: forgot this From jkrell at elego.de Mon Jan 19 17:04:03 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 17:04:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119160403.4037D10D5F74@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 17:04:03 Modified files: cm3/m3-libs/m3core/src/runtime/: m3makefile cm3/m3-libs/m3core/src/runtime/common/: m3makefile cm3/m3-libs/m3core/src/thread/: m3makefile cm3/m3-libs/m3core/src/thread/WIN32/: m3makefile Removed files: cm3/m3-libs/m3core/src/thread/WIN32/: SchedulerPosix.m3 Log message: Switch NT386GNU (aka I386_CYGWIN) to use pthreads. From jkrell at elego.de Mon Jan 19 17:11:30 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 17:11:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119161130.826B710D5F74@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 17:11:30 Modified files: cm3/m3-libs/m3core/src/thread/WIN32/: ThreadWin32.m3 Log message: go back to version 26 now that Cygwin uses pthreads From jkrell at elego.de Mon Jan 19 17:12:59 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 17:12:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119161259.6223310D5F74@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 17:12:59 Modified files: cm3/m3-libs/m3core/src/thread/WIN32/: m3makefile ThreadWin32.m3 Removed files: cm3/m3-libs/m3core/src/thread/WIN32/: ThreadInternal.i3 Log message: finish cleanup now that cygwin uses pthreads -- remove dummy SchedulerPosix implementation From jkrell at elego.de Mon Jan 19 17:20:10 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 17:20:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119162010.6BEC110D5F74@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 17:20:10 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Utime.i3 Log message: fix -- was missing int import (had copied changes across source trees..) From jkrell at elego.de Mon Jan 19 17:37:09 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 17:37:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119163709.583C510D5F74@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 17:37:09 Added files: cm3/m3-libs/m3core/src/runtime/POSIX/: RTProcessPosixC.c RTProcessPosixC.i3 Log message: prepare to remove Uresource.i3; once confirmed this is the only user From jkrell at elego.de Mon Jan 19 17:38:38 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 17:38:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119163838.26B0A714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 17:38:38 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Utime.i3 Log message: oops From jkrell at elego.de Mon Jan 19 23:37:09 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 23:37:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119223710.01AD7714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 23:37:09 Modified files: cm3/scripts/python/: make-dist.py Log message: make-dist needs to copy Uerror.obj to bootstrap cygwin distribution; take hand.obj while at it (lib/*.obj) From jkrell at elego.de Mon Jan 19 23:57:53 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 23:57:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119225753.92E8B10D5F31@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 23:57:53 Modified files: cm3/scripts/python/: make-dist.py Log message: pylib.py doesn't filter packages when they are a function parameter, only if they are on the command line; this should fix filtering out of serial on cygwin in make-dist From jay.krell at cornell.edu Tue Jan 20 06:40:07 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 20 Jan 2009 05:40:07 +0000 Subject: [M3commit] FW: [M3devel] move to version 5.7.1? In-Reply-To: <4974CB61.1E75.00D7.1@scires.com> References: <4974CB61.1E75.00D7.1@scires.com> Message-ID: [was truncated] ---------------------------------------- > From: jay.krell at cornell.edu > To: rcoleburn at scires.com; m3devel at elegosoft.com > Subject: RE: [M3devel] move to version 5.7.1? > Date: Tue, 20 Jan 2009 02:28:07 +0000 > > > I meant, can we update the version stamp in the compiler. > Nothing about releases or what not. > But I'll take some of the bait. :) > > > My archives are already pretty easy to use, but need a short readme. > > > HP-UX is not yet supported, but will be fairly soon, maybe this week. > 64bit first, this week, then 32bit, by end of next week? > (HP-UX also runs on IA64 btw, but I couldn't get my hardware to boot > my OS, maybe too old OS, maybe need to fiddle with EFI console settings. > I will be doing IA64_LINUX before long. IA64_FREEBSD also wouldn't boot > for me.) > > > Where is the line between "free Microsoft tools" and "free Python"? > > > Python is NOT needed to build cm3, just as bash is not needed. > > > There are VERY handy scripts for doing so, in both languages. > They are just slightly elaborate ways to cd around and run cm3. > > > I know, I know..they are each line crossing, everything I have to > install is a line. If it was just "free Python" and no need for "free Microsoft", > that would be similar as just "free Microsoft". And "free Microsoft" > is higher quality and more trusted than "free Python", and, clearly, > simply more necessary, unless you use Cygwin. > > > Cmd is an awful language for nearly any purpose. > Please don't ask me to support any cmd files. > > > Maybe I will rewrite the automation in JScript. > It is a half decent language and works plenty well for command line automation. > It is been "in the OS" for many years, probably at least since Windows 2000, and > with any install of Internet Explorer. > > > But really..you know..all the Python I write...is somewhat of an indictment > of either Modula-3 or myself -- I don't "like" Modula-3 enough to write much > of anything in it.. That is..these "scripts" perhaps should be written in Modula-3. > > > Or maybe actually in Quake? > Quake is kind of limited though. > Maybe with the updates though that Olaf made? > I'll think about it. > > > The system is "easier" to build from a "current" system than from an "older" system. > upgrade.sh and upgrade.py work with either. > If your system is already current, you can just build in dependency order. > If your system is not current, you first build "just the compiler", in dependency > order, but skipping and m3core, libm3. Or you possibly hack them slightly. > (Btw Tony there are few other instances of LONGINT in m3core than the one, but not many.) > > > Most of this confusion is probably only for people that build the system. > As well, maybe it could be reduced by just having an "output root" > like I've said, but I know that'd be disruptive. > > > The archives I upload are not bad. > You just extract them, set $PATH, install Python, get/install a > C compiler and linker and runtime (either Cygwin or Microsoft) and go. > > > I think they are better than the cminstall-based ones. > > > I am not likely to get around to much additional polish. > > > > - Jay > > > > ________________________________ >> Date: Mon, 19 Jan 2009 18:50:40 -0500 >> From: rcoleburn at scires.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] move to version 5.7.1? >> >> >> >> >> >> >> >> Jay et al: >> >> >> >> I have not updated any of my cm3 code base since I released my last application to my customer in late 3Q2008. >> >> >> >> Based on all the activity, I don't think I want to do an update until we've decided to make a new release. This decision should be based primarily on stability of the code base across platforms. >> >> >> >> I can backup my cm3 tree, update to latest code, and run tests on Windows XP using my current apps if that would be helpful. Let me know. Also, I may be able to do some tests on HP-UX if that platform is supported. In addition, I also now have access to a Solaris box. >> >> >> >> One of the things I want to do for the next release is to provide detailed documentation on how to install cm3 on Windows using just the tools that comes with Windows or that are available free from Microsoft. I've already got a good start on this, but will want to get input on the exact order of package builds and which have to be repeated when. >> >> >> >> My idea is that we should have a minimal install archive for Windows (NT386) available from which the "customer" (end-user) can build all of the supported packages in the correct order, including rebuilding the base/core cm3 to prove his system is fully functional. On Windows, the build would be handled via .CMD files and not require python or anything else not supplied with Windows or free from Microsoft. >> >> >> >> I also want "us" to give explicit, documented, definitions of the terms "build", "ship", "clean", "spotless", etc. etc. that are used in various scripts et al and make these consistent. We also need to have good documentation on all the pragmas, environment variables, options, and command line switches that CM3 and CM3IDE recognize. I believe a number of these currently exist that are not well-known or properly documented. >> >> >> >> IMO, this next release needs to be as professional as possible and provide end users (customers) with the best possible experience in terms of ease of installation and use. >> >> >> >> I'll help as much as I can. >> >> >> >> Regards, >> >> Randy Coleburn >> >>>>> Jay 1/19/2009 5:39 PM>>> >> >> Should we move to move version 5.7.1? >> >> To mark the new year, and NT386GNU defaulting to pthreads (I'm thinking I should go back and make it a command line option, it's very very easy). >> >> Just edit two lines in sysinfo.sh and everything keeps working, right? >> >> - Jay From jkrell at elego.de Tue Jan 20 12:57:25 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 12:57:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120115725.81A1910D5DA0@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 12:57:25 Modified files: cm3/m3-libs/m3core/src/runtime/POSIX/: RTProcessPosix.m3 m3makefile cm3/m3-libs/m3core/src/unix/Common/: Uconstants.c m3makefile cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 Added files: cm3/m3-libs/m3core/src/unix/Common/: Utermio.i3 Removed files: cm3/m3-libs/m3core/src/unix/Common/: Uresource.i3 Log message: Remove only Uresource.i3 client, and then Uresource.i3 itself. Add Utermio.i3 so Cygwin can use Posix serial, which does at least compile. There's some chance this would work for other platforms too, at the cost of defining Usysdep.struct_termios and Usysdep.speed_t. For now it is #if __CYGWIN__ in Uconstant.c though. From jkrell at elego.de Tue Jan 20 12:58:15 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 12:58:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120115815.A338610D5DA0@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 12:58:15 Modified files: cm3/m3-comm/serial/src/: m3makefile cm3/m3-comm/serial/src/POSIX/: SerialPort.m3 Log message: Switch some "CONST" to "VAR" to be compatible with constants implemented as constant variables in C. Switch Cygwin to use Posix implementation. It at least compiles and links. From jkrell at elego.de Tue Jan 20 12:59:27 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 12:59:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120115927.3824710D5DA0@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 12:59:27 Modified files: cm3/scripts/python/: pylib.py Log message: The HAVE_SERIAL filtering was still not working..remove the block on Cygwin in favor of..Cygwin has termios.h, maybe it works. From jkrell at elego.de Tue Jan 20 13:37:30 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 13:37:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120123730.E01CF10D5DA0@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 13:37:30 Modified files: cm3/m3-libs/m3core/src/time/POSIX/: DatePosix.m3 m3makefile cm3/m3-libs/m3core/src/unix/solaris-2-x/: Utime.i3 Log message: Switch the "clock" parameters in ctime_r, localtime_r, gmtime_r from long_star requiring an unsafe ADR to READONLY. VAR would also be reasonable, but they are const in C so READONLY slightly better. Might as well switch the output parameter to VAR instead of "star"? (Would be nice to change this code such as to avoid declaring sysdep struct tm..) Switch Cygwin from DateLinux to DatePosix. Note that DateLinux is dead, it is only used by Linux 1.x. DateBsd is the overwhelmingly used one, except Cygwin and Solaris. It corresponds to having gmtoff and zone at the end of struct tm. DatePosix vs. DateLinux uses the "_r" functions instead of a lock. (Where do they store the zone string, in BSD versions?) From jkrell at elego.de Tue Jan 20 14:06:07 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 14:06:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120130608.20EFA2200095@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 14:06:07 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Uconstants.c cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/freebsd-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 Log message: Crack the Modula-3 renaming code: MSETUID <=> S_ISUID MSETGID <=> S_ISGID MSTICKY <=> S_ISVTX Now that I figured that out, make them portable too, and give Cygwin its values (not sure they do anything there; the ISVTX feature is a bit in executable headers, not the file system, and setuid/setgid don't exist as far as I know, but Interix apparently offers it somehow). (See also how Unix.MROWNER == Ustat.S_IREAD == S_IRUSR, if I got those right..) From jkrell at elego.de Tue Jan 20 14:34:57 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 14:34:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120133458.1356910D5C54@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 14:34:57 Modified files: cm3/scripts/: config.c Log message: collect information about mode_t, struct timeval, let use -DCC when building it, and it will use that, cover up annoying gcc warning about -lpthread when only compiling From jkrell at elego.de Tue Jan 20 14:48:50 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 14:48:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120134850.788E310D5C54@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 14:48:50 Modified files: cm3/scripts/: config.c Log message: fix From jkrell at elego.de Tue Jan 20 15:24:18 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 15:24:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120142418.966A710D5C54@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 15:24:18 Modified files: cm3/m3-libs/m3core/src/Csupport/: m3makefile cm3/m3-libs/m3core/src/float/: m3makefile cm3/m3-libs/m3core/src/runtime/: m3makefile cm3/m3-libs/m3core/src/runtime/common/: m3makefile cm3/m3-libs/m3core/src/unix/: m3makefile cm3/m3-libs/m3core/src/unix/Common/: m3makefile Added files: cm3/m3-libs/m3core/src/unix/hpux-common/: Usysdep.i3 m3makefile Log message: Some PA32_HPUX and PA64_HPUX support, work in progress. From jkrell at elego.de Tue Jan 20 20:11:58 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 20:11:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120191158.A9158714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 20:11:58 Modified files: cm3/scripts/python/: pylib.py Log message: root around more for windows.h so I don't have to switch environment From jkrell at elego.de Tue Jan 20 20:17:46 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 20:17:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120191746.D053810D4EAA@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 20:17:46 Modified files: cm3/scripts/: config.c Log message: socklent_t, sigsuspend, always add a particular prefix From jkrell at elego.de Tue Jan 20 20:27:50 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 20:27:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120192750.919D410D4EAA@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 20:27:50 Removed files: cm3/scripts/: config.c Log message: make directory (cvs crashing again for multifile commit From jkrell at elego.de Tue Jan 20 20:28:00 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 20:28:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120192800.A9E0A10D4EAA@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 20:28:00 Added files: cm3/scripts/config/: config.c Log message: make directory (cvs crashing again for multifile commit) From jkrell at elego.de Tue Jan 20 20:42:09 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 20:42:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120194209.8672F714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 20:42:09 Added files: cm3/scripts/config/: mode.c sigsuspend.c time.c Log message: experiment with smaller programs From jkrell at elego.de Tue Jan 20 21:21:55 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 21:21:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120202155.ACE7010D4EAA@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 21:21:55 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile cm3/m3-libs/m3core/src/unix/Common/: m3makefile Added files: cm3/m3-libs/m3core/src/unix/Common/: Uutmp.i3 Removed files: cm3/m3-libs/m3core/src/unix/Uutmp1/: m3makefile Uutmp.i3 Log message: move Uutmp1 to Common From jkrell at elego.de Tue Jan 20 22:04:15 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 22:04:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120210415.333EE714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 22:04:15 Modified files: cm3/scripts/config/: config.c Log message: need to check that which is in common also, not just determine what is sysdep From jkrell at elego.de Tue Jan 20 22:08:36 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 22:08:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120210836.E0491714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 22:08:36 Modified files: cm3/scripts/config/: config.c Log message: should check function signatures too -- ultimately this should probably be output by cm3 rather than tediously maintain parallel content From jkrell at elego.de Tue Jan 20 22:12:03 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 22:12:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120211203.C0BF1714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 22:12:03 Modified files: cm3/scripts/config/: config.c Log message: fix gcc -Wall warnings -- portable and warning-free is difficult From rodney at elego.de Tue Jan 20 22:34:52 2009 From: rodney at elego.de (Rodney M. Bates) Date: Tue, 20 Jan 2009 22:34:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120213452.1CFB8714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: rodney at birch. 09/01/20 22:34:52 Modified files: cm3/m3-sys/m3gdb/gdb/gdb/: m3-util.c Log message: Fix two bugs in accessing open array dope. From jkrell at elego.de Tue Jan 20 22:35:49 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 22:35:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120213549.5A6EB714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 22:35:49 Modified files: cm3/m3-libs/libm3/src/random/: m3makefile Log message: PA32_HPUX, PA64_HPUX From jkrell at elego.de Tue Jan 20 22:37:26 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 22:37:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120213726.7D9F3714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 22:37:26 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: m3makefile SocketPosix.m3 Log message: reduce dependency of libm3 on list of supported platforms -- fewer errors when building new runtime with old compiler; elimination will come later, OSConfigPosix.m3 is the other file that needs work, and fixing it will also make it more optimal, it doesn't need to carry all the strings From jkrell at elego.de Tue Jan 20 22:40:44 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 22:40:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120214044.7D324714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 22:40:44 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: m3makefile Log message: fix incrementality -- don't recompile and relink for every run, only if the file changes From jkrell at elego.de Tue Jan 20 22:57:18 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 22:57:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120215718.60101714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 22:57:18 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: OSConfigPosix.m3 SocketPosix.m3 m3makefile Log message: Elminate the other dependency by libm3 on the list of supported platforms, and namespacify the previous one. m3core still depends on the list. From jkrell at elego.de Tue Jan 20 23:28:20 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 23:28:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120222820.D9AD710D4EAA@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 23:28:20 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Log message: fix get_altzone for Solaris From jkrell at elego.de Tue Jan 20 23:36:46 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 23:36:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120223646.12E0110D5D54@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 23:36:46 Modified files: cm3/scripts/config/: config.c Log message: fix for Solaris From jkrell at elego.de Tue Jan 20 23:47:40 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 23:47:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120224740.6303C10D5F2F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 23:47:40 Added files: cm3/m3-libs/m3core/src/unix/solaris-common/: Usysdep.i3 m3makefile Log message: add first try at Solaris Usysdep, should be double checked (config.c doesn't report MAX_FDSET for example); only checked on 32bit and 64bit SPARC, not x86/AMD64 From jkrell at elego.de Tue Jan 20 23:52:50 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 23:52:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120225250.7B1E0714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 23:52:50 Modified files: cm3/m3-libs/m3core/src/unix/solaris-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/hpux-common/: Usysdep.i3 Log message: fixup imports From jkrell at elego.de Tue Jan 20 23:53:11 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 23:53:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120225311.36DD3714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 23:53:11 Modified files: cm3/m3-libs/m3core/src/unix/hpux-common/: Usysdep.i3 Log message: fixup imports From jkrell at elego.de Wed Jan 21 16:25:14 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jan 2009 16:25:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090121152514.748DE72575B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/21 16:25:13 Modified files: cm3/m3-libs/m3core/src/runtime/AMD64_DARWIN/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/FreeBSD4/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/I386_DARWIN/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/LINUXLIBC6/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/NT386GNU/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/PPC_DARWIN/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/SOLgnu/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/SOLsun/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/common/: RTMachine.i3 cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 ThreadPThreadC.c ThreadPThreadC.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/freebsd-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/hpux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/solaris-common/: Usysdep.i3 Log message: slightly easier porting wrt SIG_SUSPEND From jkrell at elego.de Wed Jan 21 16:30:44 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jan 2009 16:30:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090121153046.49F5110D5F31@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/21 16:30:44 Modified files: cm3/m3-libs/m3core/src/runtime/FreeBSD4/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/LINUXLIBC6/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/SOLgnu/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/SOLsun/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTMachine.i3 Log message: fix warnings by removing IMPORT of Usignal From jkrell at elego.de Wed Jan 21 16:32:59 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jan 2009 16:32:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090121153300.3A56110D5F7B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/21 16:32:59 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: m3makefile Log message: remove a few spaces that make a critical difference -- PPC_LINUX was broken From jkrell at elego.de Wed Jan 21 16:57:55 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jan 2009 16:57:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090121155755.B9DFB10D6394@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/21 16:57:55 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Uconstants.c Log message: missing #includes -- at least Linux and FreeBSD broken From jkrell at elego.de Wed Jan 21 17:13:35 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jan 2009 17:13:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090121161336.02FFA10D5DA3@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/21 17:13:35 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Uconstants.c Uerror.i3 UtimeC.c Log message: fixes for Solaris: remove const to fix warning, raise Uerror.Max to 151, missing sys/filio.h #include (put it under #ifdef __sun) From jkrell at elego.de Thu Jan 22 01:58:29 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jan 2009 1:58:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090122005829.86FF4744001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/22 01:58:29 Modified files: cm3/scripts/: sysinfo.sh Log message: upgrade version from 5.7.0 to 5.7.1 From jay.krell at cornell.edu Thu Jan 22 02:00:37 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 22 Jan 2009 01:00:37 +0000 Subject: [M3commit] m3commit test.. Message-ID: I'm not seeing m3commit mail any longer. - Jay From jay.krell at cornell.edu Thu Jan 22 02:01:48 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 22 Jan 2009 01:01:48 +0000 Subject: [M3commit] m3commit not working? Message-ID: I'm not seeing m3commit mail. - Jay From jkrell at elego.de Thu Jan 22 02:09:36 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jan 2009 2:09:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090122010950.7ED17714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/22 02:09:36 Modified files: cm3/scripts/python/: pylib.py Log message: test m3commit; seems maybe working now From jay.krell at cornell.edu Thu Jan 22 02:30:07 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 22 Jan 2009 01:30:07 +0000 Subject: [M3commit] [M3devel] m3commit not working? (now working) In-Reply-To: References: Message-ID: sorry, nevermind, I see it now. A few were skipped though, like upping the version from 5.7.0 to 5.7.1, fixes for Solaris, Linux, FreeBSD though I think only in inactive files or less active platforms, not sure (i.e. Uconstants.c errors not active, UtimeC.c was only a warning, though it was also broken on Solaris a few days wrt altzone). They are in the archives on the web page. e.g.: http://mail.elegosoft.com/pipermail/m3commit/2009-January/002618.html http://mail.elegosoft.com/pipermail/m3commit/2009-January/002618.html http://mail.elegosoft.com/pipermail/m3commit/2009-January/002617.html http://mail.elegosoft.com/pipermail/m3commit/2009-January/002616.html - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3commit at elegosoft.com; m3devel at elegosoft.com > Date: Thu, 22 Jan 2009 01:01:48 +0000 > Subject: [M3devel] m3commit not working? > > > I'm not seeing m3commit mail. > > - Jay From jay.krell at cornell.edu Thu Jan 22 02:36:14 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 22 Jan 2009 01:36:14 +0000 Subject: [M3commit] [M3devel] m3commit not working? (now working) In-Reply-To: References: Message-ID: er, I see mail I send directly, but I think still not checkins. sorry for confusion... - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3commit at elegosoft.com; m3devel at elegosoft.com > Subject: RE: [M3devel] m3commit not working? (now working) > Date: Thu, 22 Jan 2009 01:30:07 +0000 > > > sorry, nevermind, I see it now. A few were skipped though, like upping the version from 5.7.0 to 5.7.1, fixes for Solaris, Linux, FreeBSD though I think only in inactive files or less active platforms, not sure (i.e. Uconstants.c errors not active, UtimeC.c was only a warning, though it was also broken on Solaris a few days wrt altzone). They are in the archives on the web page. > > e.g.: > http://mail.elegosoft.com/pipermail/m3commit/2009-January/002618.html > http://mail.elegosoft.com/pipermail/m3commit/2009-January/002618.html > http://mail.elegosoft.com/pipermail/m3commit/2009-January/002617.html > http://mail.elegosoft.com/pipermail/m3commit/2009-January/002616.html > > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3commit at elegosoft.com; m3devel at elegosoft.com >> Date: Thu, 22 Jan 2009 01:01:48 +0000 >> Subject: [M3devel] m3commit not working? >> >> >> I'm not seeing m3commit mail. >> >> - Jay From jkrell at elego.de Thu Jan 22 03:01:41 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jan 2009 3:01:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090122020141.3119810D5A74@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/22 03:01:41 Modified files: cm3/scripts/python/: pylib.py Log message: test m3commit From jkrell at elego.de Thu Jan 22 15:21:10 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jan 2009 15:21:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090122142110.45A5010D49FC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/22 15:21:10 Modified files: cm3/scripts/config/: config.c Log message: print some maxpath stuff, print about fd_set, fix for platforms that do have sockaddr_in.len From jkrell at elego.de Thu Jan 22 15:23:24 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jan 2009 15:23:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090122142324.B206810D49FC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/22 15:23:24 Added files: cm3/m3-libs/m3core/src/unix/darwin-common/: Usysdep.i3 m3makefile Log message: initial Darwin version, based only on 32bit PowerPC From jkrell at elego.de Thu Jan 22 16:20:58 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jan 2009 16:20:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090122152058.5EFE1714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/22 16:20:58 Modified files: cm3/scripts/: lzma.sh Log message: gzcat is much more portably gzip than zcat is (Darwin, Solaris) From jkrell at elego.de Sun Jan 25 17:36:15 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 25 Jan 2009 17:36:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090125163615.DABA3904003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/25 17:36:15 Modified files: cm3/m3-sys/windowsResources/src/: winRes.tmpl Log message: Surely there is no need to run cvtres manually. Not doing so works with a few toolsets I have tried. The linker accepts .res files and it is normal to give them to it. The invocation here is incompatible with very old toolsets (Visual C++ 2.0) and a minor porting nuisance due to the use of /machine:x86. The only savings I can imagine is if some resources are used "like a library" and linked into multiple binaries, that invocations of cvtres can be reduced, from once per link to just once. From jkrell at elego.de Sun Jan 25 17:57:41 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 25 Jan 2009 17:57:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090125165741.91110904003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/25 17:57:41 Modified files: cm3/scripts/python/: pylib.py Log message: m3commit test From jkrell at elego.de Sun Jan 25 19:30:27 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 25 Jan 2009 19:30:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090125183028.1799810D6357@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/25 19:30:27 Modified files: cm3/m3-tools/uniq/src/: Main.m3 Log message: Fix the problem where the Modula-3 implementation of uniq.exe causes building gcc to hang if it is first in %PATH%. The problem is that building gcc invokes uniq with a file path on the command line, rather than feeding it stdin. Modula-3 uniq.exe only was expecting stdin and hangs reading from it and getting nothing. From jkrell at elego.de Mon Jan 26 10:57:32 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jan 2009 10:57:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090126095732.B29E610D63BB@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/26 10:57:32 Modified files: cm3/m3-sys/windowsResources/src/: winRes.tmpl Log message: go ahead and remove the unnecessary stuff, rather than just comment it out From jkrell at elego.de Mon Jan 26 13:36:15 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jan 2009 13:36:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090126123615.73B1B10D6491@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/26 13:36:15 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RT0.i3 Log message: fix comment to refer to correct interface, since the interface doesn't actually exist (the fiel does, but it isn't built) From jkrell at elego.de Mon Jan 26 13:38:12 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jan 2009 13:38:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090126123812.C7F4B10D63BC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/26 13:38:12 Modified files: cm3/m3-libs/m3core/src/runtime/FreeBSD/: m3makefile Removed files: cm3/m3-libs/m3core/src/runtime/FreeBSD/: DEFS.h RTStackASM.s Log message: remove unused files, esp. in obsolete target From jkrell at elego.de Mon Jan 26 13:39:20 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jan 2009 13:39:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090126123920.05B9910D63BC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/26 13:39:20 Removed files: cm3/m3-libs/m3core/src/runtime/FreeBSD2/: DEFS.h RTStackASM.s Log message: remove unused files, esp. in obsolete targets From jkrell at elego.de Mon Jan 26 13:41:29 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jan 2009 13:41:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090126124129.0A04B10D63BC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/26 13:41:29 Removed files: cm3/m3-libs/m3core/src/runtime/FreeBSD3/: RTStackASM.s Log message: remove unused file, esp. from obsolete targets From jkrell at elego.de Mon Jan 26 13:42:51 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jan 2009 13:42:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090126124251.C4F8A10D63BC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/26 13:42:51 Removed files: cm3/m3-libs/m3core/src/runtime/FreeBSD4/: RTStackASM.s Log message: remove unused file From jkrell at elego.de Mon Jan 26 13:43:47 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jan 2009 13:43:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090126124347.3E19A10D63BC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/26 13:43:47 Removed files: cm3/m3-libs/m3core/src/runtime/LINUXLIBC6/: RTStackASM.s Log message: remove unused file From jkrell at elego.de Mon Jan 26 13:44:56 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jan 2009 13:44:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090126124456.E46CA10D63BC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/26 13:44:56 Removed files: cm3/m3-libs/m3core/src/runtime/LINUX/: RTStackASM.s Log message: remove unused file, in obsolete Linux 1.x a.out target From jkrell at elego.de Wed Jan 28 00:28:42 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 0:28:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090127232842.99F2310D63C2@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 00:28:42 Removed files: cm3/m3-libs/m3core/src/runtime/I386_DARWIN/: RTStackASM.s _fpsetjmp.s Log message: delete unused files From jkrell at elego.de Wed Jan 28 00:29:48 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 0:29:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090127232948.7195910D63C2@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 00:29:48 Removed files: cm3/m3-libs/m3core/src/runtime/LINUXELF/: RTStackASM.s Log message: remove unused file, in obsolete target From jkrell at elego.de Wed Jan 28 00:30:59 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 0:30:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090127233102.782A7744006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 00:30:59 Modified files: cm3/m3-libs/m3core/src/runtime/OS2/: m3makefile Removed files: cm3/m3-libs/m3core/src/runtime/OS2/: RTStackASM.s Log message: remove unused file From jkrell at elego.de Wed Jan 28 00:32:34 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 0:32:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090127233234.B08F9F04006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 00:32:34 Modified files: cm3/m3-libs/m3core/src/runtime/NetBSD2_i386/: m3makefile Log message: remove remnants of unused file From jkrell at elego.de Wed Jan 28 00:36:57 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 0:36:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090127233657.3532210D63C5@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 00:36:57 Removed files: cm3/m3-libs/m3core/src/runtime/SOLsun/: RTStackASM.s.sav RTStackASM.s Log message: remove unused files From jkrell at elego.de Wed Jan 28 00:37:51 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 0:37:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090127233751.9414710D63C5@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 00:37:51 Removed files: cm3/m3-libs/m3core/src/runtime/SOLgnu/: RTStackASM.s Log message: remove unused file From jkrell at elego.de Wed Jan 28 16:23:53 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 16:23:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090128152353.9BDDF714575@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 16:23:53 Modified files: cm3/m3-libs/m3core/src/runtime/IBMR2/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/LINUXLIBC6/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/SOLgnu/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/SOLsun/: RTThread.m3 Log message: gratuitous formating difference From jkrell at elego.de Wed Jan 28 16:47:15 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 16:47:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090128154716.3138F1704004@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 16:47:15 Modified files: cm3/m3-libs/m3core/src/runtime/FreeBSD4/: RTSignal.m3 Log message: eliminate gratuitous platform specific diff -- change local variable 'dummy' to 'old From jkrell at elego.de Wed Jan 28 16:49:46 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 16:49:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090128154952.A2A8F220001A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 16:49:46 Modified files: cm3/m3-libs/m3core/src/runtime/ALPHA_OSF/: RTThread.m3 Log message: eliminate gratuitous formating difference, missed this before From jkrell at elego.de Wed Jan 28 16:52:56 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 16:52:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090128155256.C58E8220001A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 16:52:56 Modified files: cm3/m3-libs/m3core/src/runtime/ALPHA_OSF/: RTSignal.m3 cm3/m3-libs/m3core/src/runtime/AMD64_DARWIN/: RTSignal.m3 cm3/m3-libs/m3core/src/runtime/FreeBSD4/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/I386_DARWIN/: RTSignal.m3 cm3/m3-libs/m3core/src/runtime/LINUXLIBC6/: RTSignal.m3 cm3/m3-libs/m3core/src/runtime/NetBSD2_i386/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/PPC_DARWIN/: RTSignal.m3 cm3/m3-libs/m3core/src/runtime/SOLgnu/: RTSignal.m3 cm3/m3-libs/m3core/src/runtime/SOLsun/: RTSignal.m3 Log message: eliminate gratuitous whitespace diff between platforms before: <*ASSERT i = 0*> after: <* ASSERT i = 0 *> From jkrell at elego.de Wed Jan 28 17:21:19 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 17:21:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090128162119.7294D10D5ECB@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 17:21:19 Modified files: cm3/m3-libs/m3core/src/runtime/AMD64_DARWIN/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/I386_DARWIN/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/LINUXLIBC6/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/PPC_DARWIN/: RTThread.m3 Log message: eliminate more gratuitous platform specific diffs These platforms were doing FROM Usignal IMPORT sigaction, sigprocmask, etc. whereas other platforms just IMPORT Usignal; and then reference qualified Usignal.sigaction, etc. From jkrell at elego.de Wed Jan 28 18:44:42 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 18:44:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090128174442.D2AD210D63A2@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 18:44:42 Modified files: cm3/m3-libs/m3core/src/runtime/ALPHA_OSF/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/AMD64_DARWIN/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/FreeBSD4/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/I386_DARWIN/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/LINUXLIBC6/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/NetBSD2_i386/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/PPC_DARWIN/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/SOLgnu/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/SOLsun/: RTThread.m3 Log message: eliminate more gratuitous platform differences Some platforms uses + to combine mprotect protections, some used Word.Or. Use + because it is terser, assuming these are all independent flags. Some platforms used WITH i = foo; ASSERT(i = 0); Some used VAR i := foo; ASSERT(i = 0); Use VAR, in order to elminate indentation. some platforms said IF (page_size = 0) and some said IF page_size = 0. Use the second shorter form. This code kinda looks like it has a race condition, but probably not, since it is the code that is involved in creating threads, there cannot be multiple threads until after it runs. Platforms still vary as to what protections they use on the last stack page. From jkrell at elego.de Thu Jan 29 08:43:23 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 29 Jan 2009 8:43:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090129074323.C5F4010D6493@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/29 08:43:23 Modified files: cm3/m3-libs/m3core/src/unix/darwin-common/: Usysdep.i3 Log message: add missing semicolons; this code is not yet active From jkrell at elego.de Thu Jan 29 18:07:09 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 29 Jan 2009 18:07:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090129170709.CBB9110D5F23@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/29 18:07:09 Modified files: cm3/scripts/config/: config.c Log message: Cygwin's setjmp.h reports the wrong size for jmp_buf; detect and report that. From jkrell at elego.de Fri Jan 30 04:25:37 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 30 Jan 2009 4:25:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090130032538.030B410D5DAA@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/30 04:25:37 Added files: cm3/m3-libs/m3core/src/context/: context.c context.h tcontext.c Log message: highly non-portable working version of set/get/make/swapcontext for NT386; should assist in providing e.g. Cygwin, OpenBSD/x86, and perhaps non-x86, though again, it is highly system specific, and inline assembly syntax is very different between Visual C++ and gcc From jkrell at elego.de Fri Jan 30 16:26:42 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 30 Jan 2009 16:26:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090130152642.30B8F71457D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/30 16:26:42 Modified files: cm3/m3-libs/m3core/src/context/: context.c context.h tcontext.c Log message: fix newlines From jkrell at elego.de Fri Jan 30 16:28:35 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 30 Jan 2009 16:28:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090130152835.E94DC10D5A8D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/30 16:28:35 Modified files: cm3/m3-libs/m3core/src/context/: context.c context.h Log message: use pushad/popad, and keep registers as all size_t, only change the type of esp for convenience via a local; note that real NT386/Cygwin usermode threads should use Win32 fibers, this is just a prototype that maybe could be applied to OpenBSD/x86 and proof of concept of how difficult/possible the context APIs are to implement -- very difficult actually, just that x86 is familiar From jkrell at elego.de Fri Jan 30 16:35:57 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 30 Jan 2009 16:35:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090130153557.C9A0771457E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/30 16:35:57 Modified files: cm3/m3-libs/m3core/src/unix/linux-64/: m3makefile Removed files: cm3/m3-libs/m3core/src/unix/linux-64/: Uucontext.i3 Log message: should fix AMD64_LINUX and SPARC64_LINUX -- no need for Uucontext.i3 here, just use the common one From jkrell at elego.de Fri Jan 30 20:06:51 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 30 Jan 2009 20:06:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090130190651.EDAF2744002@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/30 20:06:51 Modified files: cm3/m3-libs/m3core/src/context/: tcontext.c Added files: cm3/m3-libs/m3core/src/context/winfiber/: context.c context.h cm3/m3-libs/m3core/src/context/x86msvc/: context.c context.h readme.txt Removed files: cm3/m3-libs/m3core/src/context/: context.c context.h Log message: A more realistic implementation of *context portable to all Windows platforms by using fibers. Move previous to "x86msvc". From jkrell at elego.de Fri Jan 30 23:16:58 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 30 Jan 2009 23:16:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090130221658.B4A8B744002@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/30 23:16:58 Added files: cm3/m3-libs/m3core/src/context/x86/: Makefile context.c context.h contextasm.s Log message: works on OpenBSD/x86, neat From jkrell at elego.de Sat Jan 31 00:10:47 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jan 2009 0:10:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090130231047.2354410D63AB@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/31 00:10:47 Modified files: cm3/m3-libs/m3core/src/context/x86/: Makefile context.c contextasm.s Log message: adapt to Cygwin -- which uses coff, so symbols with underscores, and different validity/meaning of .type and .size; and its make doesn't understand $> From jkrell at elego.de Sat Jan 31 00:14:13 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jan 2009 0:14:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090130231413.2086710D63AB@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/31 00:14:13 Modified files: cm3/m3-libs/m3core/src/context/x86/: Makefile contextasm.s Log message: finish adapting to Cygwin and quash make clean output From jkrell at elego.de Sat Jan 31 05:25:43 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jan 2009 5:25:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090131042543.ED60710D5F16@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/31 05:25:43 Modified files: cm3/m3-libs/m3core/src/context/: tcontext.c cm3/m3-libs/m3core/src/context/x86/: Makefile Log message: preemptive version works on OpenBSD/x86 From jkrell at elego.de Thu Jan 1 01:02:45 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jan 2009 1:02:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090101000246.4E23210D5F06@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/01 01:02:45 Modified files: cm3/m3-libs/m3core/src/: Uwaitpid.quake m3makefile cm3/m3-libs/m3core/src/thread/: m3makefile cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile Added files: cm3/m3-libs/m3core/src/: thread.quake Log message: Remove the Sleep from [Process]Wait in sysutils, as it was removed from libm3, at least for non-user threads platforms. This should accomplish some speedup, but not measured. NOTE: historically m3core is built for userthreads or kernelthreads; now sysutils is too. Ideally such "switches" are contained within one .dll and then exported to others that adapt. In this case, both .dlls contain the constant. The roundabout structuring here, as well as the previous non-ideal situation, is in the interest of letting sysutils work against old m3core, while still getting this fix. Another approach to consider, if it can be easily reliably achieved, is to only do the "copying" when building against an old m3core, and go ahead and use the usual share-by-call mechanisms when building against newer m3core. Another approach is..what is this import_pkg quake feature? It seems to allow sharing-by-automated-copy instead of sharing-by-call, like static linking vs. dynamic linking. There does seem to be a bunch of redundancy in sysutils compared to m3core or libm3..but the compiler works with older m3core/libm3 whereas there sort of is no such thing as an 'old' sysutils, since it was introduced relatively recently. Really just need to bump forward the bootstrap start?? From jkrell at elego.de Thu Jan 1 01:55:29 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jan 2009 1:55:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090101005529.A85E510D5F02@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/01 01:55:29 Modified files: cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 Log message: share some common code From jkrell at elego.de Thu Jan 1 08:51:02 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jan 2009 8:51:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090101075102.B8A9710D4524@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/01 08:51:02 Added files: cm3/scripts/: lzma.sh Log message: make-dist helper -- for any *.tar.gz in current directory, produce equiv .tar.lzma; my current thinking is to always release both, folks that have lzma can spare the download bandwidth, of course one of the downsides is that people might be confused or lazy and download both From jkrell at elego.de Thu Jan 1 09:31:37 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jan 2009 9:31:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090101083138.9FE3B10D5E61@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/01 09:31:37 Modified files: cm3/m3-libs/m3core/src/unix/Common/: m3unix.h Log message: fix newlines From jkrell at elego.de Thu Jan 1 09:43:06 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jan 2009 9:43:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090101084306.57E8110D4524@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/01 09:43:06 Modified files: cm3/m3-libs/m3core/src/unix/Common/: m3unix.h UdirC.c Log message: having done some research on the myriad macros guiding 64 vs. 32 bit file offsets/sizes, this should suffice From jkrell at elego.de Thu Jan 1 09:44:50 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 1 Jan 2009 9:44:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090101084450.653A110D4524@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/01 09:44:50 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UstatC.c Log message: fix one newline From jkrell at elego.de Fri Jan 2 01:21:20 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 1:21:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102002120.D5FF610D5D5D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 01:21:20 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c cm3/m3-libs/m3core/src/unix/cygwin/: Unix.i3 Usignal.i3 Usocket.i3 Ustat.i3 Utime.i3 Utypes.i3 Uutsname.i3 m3makefile Added files: cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 Removed files: cm3/m3-libs/m3core/src/unix/cygwin/: Utime.m3 Log message: tighten up UtimeC.c a little, perhaps unnecessarily in particular, function that takes [0..1] assert its parameter, and in the unlikely case that doesn't suffice (compile with -DNDEBUG?), truncate it as well. If the extern function is declared as taking [0..1], presumably the range checks are on the caller side and not the callee side??? That is more bloated, but seems better, maybe. Remove some unused prototypes. Dubious to put them here. Might have quashed compiler warnings(as errors) in some contexts, will put them back as needed, probably in m3unix.h. The code is definitely standard-correct, but might not pass all command lines, like gcc -Wmissing-prototypes or such. (Er, at least Metrowerks was the worst here, making you prototype functions that were implemented prior to use, or not even used.., gcc hopefully only complains about used stuff..?) First round of moving Unix constants and types into new Usysdep.i3, and then exporting those from files that contain some portable content. plan: do this one platform at a time (cygwin, linux, openbsd) do each platform twice it is very tedious, copy/paste intensive, error-prone first round not commited, just saved away and then compared to second round once each platform done, go back and extract the common parts the intention is that every file but Usysdep.i3 is identical, but this is best verified and acted upon only once they are all three there and seeming to work Here just Cygwin. This should significantly reduce the system dependent content, even though it may lead to more lines over all, since sysdep content must be declared AND forwarded. Note that this discovered duplicate declarations of timezone or such, one in Utime.i3, the other in Utypes.i3. Investigate this more later. As well, Usysdep probably contains some portable content, to be whittled down later. As well, the resulting portable files -- Unix.i3 and such -- are likely to be in varying order after the first round, and Cygwin's suffers (arguably) from a lack of comments and unreadable order (flags/types/functions not near relatives). At some point this was to reduce the size of the cloned headers, but once their duplication is reduced, the trade off starts shifting. Merge Utime.m3 into UtimeC.c. Perhaps not ideal. Cygwin is the only Posix platform that needs this C wrapper. Perhaps the calling Modula-3 should be modified to either ignore errors, or ignore errors on Cygwin (you can do runtime checks of what platform you are on, after all, some code does). From jkrell at elego.de Fri Jan 2 02:58:52 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 2:58:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102015852.5F47F10D5D5E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 02:58:52 Modified files: cm3/m3-libs/m3core/src/Csupport/: m3makefile cm3/m3-libs/m3core/src/Csupport/libgcc/: libgcc.c Log message: Account for NT386 and NT386GNU clashing over /cm3/lib/hand.obj, which should probably be moved. As well, this will be needed for any 32bit system that doesn't use gcc as the compiler/linker (AIX, HP-UX, IRIX, etc.). It is already needed/used by SOLsun. From jkrell at elego.de Fri Jan 2 06:00:55 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 6:00:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102050055.4096D10D5EDB@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 06:00:55 Modified files: cm3/m3-ui/zeus/src/: m3zume.tmpl Log message: % % Allow native I386_NT (NT386) cm3 to run I386_CYGWIN (NT386GNU) m3zume. % This is a fairly real scenario in my workflow that I was ignoring. % I386_CYGWIN does not like commands like: % m3zume ..\foo\bar => invalid extension, it probably % thinks \foo\bar is the extension. % This is a more general problem, not fully solved here. % For this to be OK on native Win32 depends on that / are now accepted on Win32. % (Which I question from time to time, if it was a good idea.) % % % A problem is that on "biarch" systems, such as NT386 + NT386GNU, or % LINUXLIBC6 + AMD64_LINUX, /cm3/bin/cm3 can bounce back and forth between the two, % leading to the two worlds to come together somewhat, and perhaps interop. % % Probably there should be /cm3/bin/target/cm3, and a "portable" /cm3/bin/cm3 that % figures out which one to call. On Posix it would be an extensionless sh % that ends with "exec". It could sniff host platform with uname, like sysinfo.sh does, % though sysinfo.sh would also compute it, allowing skipping running the sniffing repeatedly. % On NT it would be nice if it could be .cmd, but more likely an NT386 binary. % On uniarch systems, just link the two. % % This way the systems don't have to interop, nor would the general problem of differing % slashes have to be dealt with. Though, it is a dilemna beyond Modula-3 as to interop % of Cygwin binaries with Win32 binaries. % From jkrell at elego.de Fri Jan 2 08:28:23 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 8:28:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102072823.705C810D5EDD@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 08:28:23 Removed files: cm3/m3-libs/m3core/src/unix/solaris-2-x/: Udir.m3 Log message: remove unused file From jkrell at elego.de Fri Jan 2 09:06:26 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 9:06:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102080626.93D0210D5F04@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 09:06:26 Modified files: cm3/m3-libs/m3core/src/time/POSIX/: m3makefile Log message: add missing SPARC64_OPENBSD; and put all the OPENBSD platforms next to each other From jkrell at elego.de Fri Jan 2 09:10:50 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 9:10:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102081050.BE50210D5EDC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 09:10:50 Modified files: cm3/m3-libs/m3core/src/unix/openbsd-common/: Udir.i3 Unix.i3 Upthread.i3 Usignal.i3 Usocket.i3 Utime.i3 Utypes.i3 Uucontext.i3 Uutsname.i3 m3makefile Added files: cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 Log message: refactor system dependent lines (ie: types and constants) into Usysdep, with the intent that all the other files will be identical across all targets and move into the Common directory (and even still, then and Usysdep might be further reduced, and Usysdep.i3 generated automatically) Note that Uerror.i3 is left alone (as it was for Cygwin, but forgot to mention that); it has a /very/ high density of sysdep lines, like essentially every line; unless we wrap the constants up in accessor functions written in C, then it becomes completely portable. (Other files like Uucontext are also highly sysdep, and might become more so when make/set/get/swapcontext supported added; we'll see; also, most of the stat values are sysdep, except a few that Cygwin uses zero for; again, this is just a step, more before and after.) From jkrell at elego.de Fri Jan 2 21:08:56 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 21:08:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102200856.3960610D5CFC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 21:08:56 Modified files: cm3/m3-libs/libm3/src/os/WIN32/: OSConfigWin32.m3 cm3/m3-libs/libm3/src/os/POSIX/: OSConfigPosix.m3 Log message: eliminate race condition that could occur if the code is highly optimized -- don't depend on write ordering From jkrell at elego.de Fri Jan 2 21:22:55 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 21:22:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102202255.9177E10D5D00@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 21:22:55 Modified files: cm3/m3-libs/libm3/src/os/WIN32/: OSConfigWin32.m3 Log message: add in some missing architectures, though arguably this should be either GetEnv(PROCESSOR_ARCHITECTURE) (does it work on CE?) or a constant determined at build time; the historical code goes obsolete automatically and quietly From jkrell at elego.de Fri Jan 2 21:36:45 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 21:36:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102203645.6902110D5D00@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 21:36:45 Modified files: cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 m3makefile cm3/m3-libs/libm3/src/os/POSIX/: OSConfigPosix.m3 m3makefile cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 m3makefile Added files: cm3/m3-libs/libm3/src/os/POSIX/: OSConfigPosixC.c OSConfigPosixC.i3 Removed files: cm3/m3-libs/m3core/src/unix/cygwin/: Uutsname.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Uutsname.i3 Log message: eliminate lone Uutsname.i3 usage and then system-dependent Uutsname.i3 itself, via portable C wrapper The vast bulk of OSConfig appears dead within cm3 anyway. All I see is OSConfig.LineSep (for writing only; readers should accept any of the three usages) and OSConfig.UserName(). So maybe we should just aggressively prune it down? Could be users outside the tree, granted. From jkrell at elego.de Fri Jan 2 21:49:31 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 21:49:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102204931.4718610D461B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 21:49:31 Modified files: cm3/m3-libs/m3core/src/unix/linux-common/: m3makefile Removed files: cm3/m3-libs/m3core/src/unix/linux-common/: Uutsname.i3 Log message: delete this one too From jkrell at elego.de Fri Jan 2 23:04:54 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 23:04:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102220454.B9EF910D5481@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 23:04:54 Modified files: cm3/m3-libs/m3core/src/unix/Common/: m3makefile Log message: fix newlines From jkrell at elego.de Fri Jan 2 23:07:05 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 23:07:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102220705.3EA0810D5481@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 23:07:05 Modified files: cm3/m3-libs/m3core/src/unix/linux-common/: Unix.i3 Upthread.i3 Usignal.i3 Usocket.i3 Utime.i3 Utypes.i3 m3makefile Log message: refactor linux-common using Usysdep a little more needed for Usignal and Usocket due to linux-sparc variant (should be ok, just hasn't achieved as much commonality as in the openbsd-common change) From jkrell at elego.de Fri Jan 2 23:38:40 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 23:38:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102223840.CB17110D542A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 23:38:40 Modified files: cm3/m3-libs/m3core/src/C/Common/: m3makefile Log message: fix newlines From jkrell at elego.de Fri Jan 2 23:40:45 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 2 Jan 2009 23:40:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102224045.734F510D542A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/02 23:40:45 Added files: cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 Log message: forgot to add this From jkrell at elego.de Sat Jan 3 00:49:44 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 0:49:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102234944.CA23510D4D19@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 00:49:44 Modified files: cm3/m3-libs/m3core/src/unix/cygwin/: m3makefile Log message: forgot to delete Uutsname.i3 here From jkrell at elego.de Sat Jan 3 00:52:05 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 0:52:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090102235205.995B110D4D19@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 00:52:05 Modified files: cm3/m3-libs/m3core/src/unix/openbsd-common/: Utypes.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Utypes.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Utypes.i3 Log message: make these three files identical From jkrell at elego.de Sat Jan 3 01:57:20 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 1:57:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103005721.001F410D54EF@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 01:57:20 Modified files: cm3/m3-libs/m3core/src/unix/hpux-7-0/: Utime.i3 cm3/m3-libs/m3core/src/unix/irix-5.2/: Utime.i3 cm3/m3-libs/m3core/src/unix/linux/: Utime.i3 Log message: go ahead and break these three old dormant platforms rather than determine interfaces regarding timezones, alt timezones, daylight savings, etc.; will probably actually repair Irix and HPUX in the next few months (! I have Irix running at home and HP-UX maybe soon) but Linux 1.x a.out not likely; this is part of other Utime-related cleanup. From jkrell at elego.de Sat Jan 3 01:59:30 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 1:59:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103005930.4A0F010D569E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 01:59:30 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c cm3/m3-libs/m3core/src/unix/cygwin/: Utime.i3 cm3/m3-libs/m3core/src/unix/linux-libc6/: Utime.i3 cm3/m3-libs/m3core/src/unix/solaris-2-x/: Utime.i3 Log message: 1: put "m3_" in front of the functions we implement outselves, for clarity, and in case there are "real" functions with these names 2: add comments indicating what should perhaps be re-investigated no "real" change From jkrell at elego.de Sat Jan 3 02:51:36 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 2:51:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103015136.1C9BC10D458D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 02:51:36 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c cm3/m3-libs/m3core/src/unix/cygwin/: Utime.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Utime.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Utime.i3 Log message: make these three files identical too From jkrell at elego.de Sat Jan 3 06:22:25 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 6:22:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103052225.413CA170400C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 06:22:25 Modified files: cm3/m3-sys/cm3/src/: M3Build.m3 Log message: (* Host and Target paths sometimes get confused, leading to many warnings such as: package "libm3" is already overridden to C:\dev2\cm3.2/m3-libs, ignoring new override to C:/dev2/cm3.2/m3-libs PathEqual is defined as Text.Equal or Text.Equal(replacing backward slashes with forward slashes). It would also be reasonable to be case insensitive if the path contains any backward slashes, or if they both contain colon as the second character. *) From jkrell at elego.de Sat Jan 3 06:36:43 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 6:36:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103053644.E810410D4624@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 06:36:43 Modified files: cm3/m3-ui/juno-2/juno-app/src/: m3makefile Log message: Fix more substantial cross build scenarios. Previously fixed cross scenarios where host and target could run on the same machine (NT386/NT386GNU, LINUXLIBC6/AMD64_LINUX). This fixes 'normal' cross scenarios, where they can't. Why are we even using unshipped binaries here? How about just trust $PATH, knowing that binaries ship next to cm3, and that cm3 is probably in $PATH? (Granted, it need not be, and perhaps PklFonts doesn't ship?) Also, why are we cd'ing around? Why doesn't the the package whose output directory we are stomping in do this, or why don't we just stay in our own output directory? It seems like a generally bad idea what is going on here -- you know, imagine a multithreaded build..packages should keep to themselves. This does impact all builds but should be simply correct. From jkrell at elego.de Sat Jan 3 06:52:54 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 6:52:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103055254.A161A10D582F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 06:52:53 Modified files: cm3/m3-libs/m3core/src/unix/openbsd-common/: Usocket.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usocket.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Usocket.i3 Log message: three more identical files, they almost already were save for whitespace, and an int vs. size_t but in cygwin/recvfrom; and get size_t from Cstddef instead of Utypes From jkrell at elego.de Sat Jan 3 13:07:00 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 13:07:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103120700.D0D7F10D5E88@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 13:07:00 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile Log message: fix newlines From jkrell at elego.de Sat Jan 3 13:07:34 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 13:07:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103120734.31A5110D5E88@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 13:07:34 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile Log message: use Common on all platforms From jkrell at elego.de Sat Jan 3 14:14:18 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 14:14:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103131421.6B73D10D5E9E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 14:14:18 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: don't leak attributes used for setting thread stack size From jkrell at elego.de Sat Jan 3 14:54:38 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 14:54:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103135438.CB44A10D43B4@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 14:54:38 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: ProcessCygwin.m3 cm3/m3-libs/m3core/src/unix/Common/: m3makefile cm3/m3-libs/m3core/src/unix/cygwin/: Unix.i3 Usysdep.i3 Utypes.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Unix.i3 Upthread.i3 Usignal.i3 Usysdep.i3 Utypes.i3 m3makefile cm3/m3-libs/m3core/src/unix/linux-sparc/: Usignal.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Unix.i3 Upthread.i3 Usignal.i3 Usysdep.i3 Utypes.i3 Added files: cm3/m3-libs/m3core/src/unix/Common/: UnixC.c Log message: on going header cleanup/merge (in non-mainstream platforms) some lengths were incorrectly int instead of size_t flesh out cygwin's Usignal (not used, but need to be the same) add wrappers for anything dealing with off_t or opening files so that we can be sure to get 64bit off_t and O_LARGEFILE, even on 32bit platforms, and with common headers; otherwise we'd have to fiddle with the <*extern*> name on 32bit Linux and Solaris (Solaris not yet relevant here, but it will be) Darwin does very similar. start adding comments back; they won't be so annoyingly bloated when we only have one copy of them instead of per-platform add mode_t; we were using the wrong type there in a few places (int) remove bogus sigaction type, some editing error problem, it is a field not a type cleanup the NDELAY / NONBLOCK / M3_NONBLOCK stuff /somewhat/ still leaving stuff around for compat cleanup is that Usysdep only defines NDELAY, and then portable layer aliases all three as one Cygwin will hold back with its own Usignal.i3. In particular, pthreads platforms need more in Usignal than non-pthreads. Cygwin also won't have pthreads.i3 at all, unless/until we use it. From jkrell at elego.de Sat Jan 3 15:00:20 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 15:00:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103140025.DC62010D5E88@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 15:00:20 Modified files: cm3/m3-libs/m3core/src/unix/linux-common/: Unix.i3 Log message: missed a spot of semantically meaningless diff From jkrell at elego.de Sat Jan 3 15:01:05 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 15:01:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103140106.1947B10D5E88@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 15:01:05 Modified files: cm3/m3-libs/m3core/src/unix/cygwin/: Utypes.i3 Log message: fix newlines From jkrell at elego.de Sat Jan 3 16:15:38 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 16:15:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103151538.4BE6C10D458D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 16:15:38 Modified files: cm3/m3-libs/m3core/src/unix/Common/: m3makefile Added files: cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Usignal.i3 Usocket.i3 Utime.i3 Utypes.i3 Removed files: cm3/m3-libs/m3core/src/unix/cygwin/: Unix.i3 Usocket.i3 Utime.i3 Utypes.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Unix.i3 Upthread.i3 Usignal.i3 Usocket.i3 Utime.i3 Utypes.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Unix.i3 Upthread.i3 Usignal.i3 Usocket.i3 Utime.i3 Utypes.i3 Log message: move 2-way or 3-say identical files to Common From jkrell at elego.de Sat Jan 3 16:19:14 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 16:19:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103151915.BDB1C10D458D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 16:19:14 Modified files: cm3/m3-libs/m3core/src/unix/openbsd-common/: m3makefile cm3/m3-libs/m3core/src/unix/linux-common/: m3makefile cm3/m3-libs/m3core/src/unix/cygwin/: m3makefile Log message: move (partly) common files to common From jkrell at elego.de Sat Jan 3 16:25:24 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 16:25:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103152525.25FB610D458D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 16:25:24 Added files: cm3/m3-libs/m3core/src/unix/Common/: Upthread.i3 Log message: forgot to add this From jkrell at elego.de Sat Jan 3 17:03:31 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 17:03:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103160332.0C5AC10D5AF4@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 17:03:31 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: fix the fallback; this never affects me because the probing finds my unshipped codegenerators From jkrell at elego.de Sat Jan 3 17:03:53 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 3 Jan 2009 17:03:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090103160354.0332A10D5AF4@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/03 17:03:53 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: fix the disabled debugprint too From jkrell at elego.de Sun Jan 4 01:43:42 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 1:43:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104004342.B1BD310D5E9A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 01:43:42 Modified files: cm3/m3-libs/m3core/src/unix/irix-5.2/: Unix.i3 Log message: tediously convert to base 8 for easier comparison to other platforms, though base 16 really is far more natural than base 8 except for permission bits.. From jkrell at elego.de Sun Jan 4 01:47:39 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 1:47:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104004739.711E3F04010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 01:47:39 Modified files: cm3/m3-libs/m3core/src/unix/irix-5.2/: Ustat.i3 Log message: ditto: tediously convert to base 8 for easier comparison to other platforms, though base 16 really is far more natural than base 8 except for permission bits.. From jkrell at elego.de Sun Jan 4 01:53:03 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 1:53:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104005303.84C7110D5E9A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 01:53:03 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utypes.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 Log message: significant reduction in sysdep content off_t is always 64 bits (or at least let's hope so) the dir/stat flags are mostly all the same, except for a few that are zero on cygwin M[RWX][OWNER GROUP OTHER] [FXWR]_OK F_SETFD, F_GETFL, F_SETFL FIONREAD ITIMER_REAL ITIMER_VIRTUAL Some of this might be by chance and not by-standard, so under review for new platforms, and probably should be verified during native builds. note that OS/2 has a different S_IFMT but not quite relevant here From jkrell at elego.de Sun Jan 4 02:09:58 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 2:09:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104010959.29D922200044@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 02:09:57 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Utime.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 Log message: struct_itimerval is always the same From jkrell at elego.de Sun Jan 4 02:13:22 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 2:13:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104011323.4603610D5EB1@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 02:13:22 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Utime.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 Log message: struct_timezone is always the same From jkrell at elego.de Sun Jan 4 02:56:16 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 2:56:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104015616.F307E10D5C54@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 02:56:16 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Utime.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 Log message: struct_timespec is always the same From hosking at cs.purdue.edu Sun Jan 4 02:57:28 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 4 Jan 2009 12:57:28 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20090104005303.84C7110D5E9A@birch.elegosoft.com> References: <20090104005303.84C7110D5E9A@birch.elegosoft.com> Message-ID: <13927A2A-F535-48EB-9A33-4813E2B74442@cs.purdue.edu> On some platforms off_t is not 64 bits. This from Solaris (see off_t==long): #if defined(_LARGEFILE_SOURCE) || defined(_XPG5) #ifndef _OFF_T #define _OFF_T #if defined(_LP64) || _FILE_OFFSET_BITS == 32 typedef long off_t; #else typedef __longlong_t off_t; #endif #ifdef _LARGEFILE64_SOURCE #ifdef _LP64 typedef off_t off64_t; #else typedef __longlong_t off64_t; #endif #endif /* _LARGEFILE64_SOURCE */ #endif /* _OFF_T */ #endif /* _LARGEFILE_SOURCE * Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 4 Jan 2009, at 01:53, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/01/04 01:53:03 > > Modified files: > cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utypes.i3 > cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 > > Log message: > significant reduction in sysdep content > > off_t is always 64 bits (or at least let's hope so) > the dir/stat flags are mostly all the same, > except for a few that are zero on cygwin > > M[RWX][OWNER GROUP OTHER] > [FXWR]_OK > F_SETFD, F_GETFL, F_SETFL > FIONREAD > ITIMER_REAL > ITIMER_VIRTUAL > > Some of this might be by chance and not by-standard, > so under review for new platforms, and probably should be verified > during native builds. > > note that OS/2 has a different S_IFMT but not quite relevant here -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 4 03:22:22 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 4 Jan 2009 02:22:22 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <13927A2A-F535-48EB-9A33-4813E2B74442@cs.purdue.edu> References: <20090104005303.84C7110D5E9A@birch.elegosoft.com> <13927A2A-F535-48EB-9A33-4813E2B74442@cs.purdue.edu> Message-ID: But how about if we always #define _FILE_OFFSET_BITS 64 and use C wrappers? As I have done. Or externs with "64" appended, but that prevents me from using one set of .i3 files. I mean, I know there are "modes" with 32 bit off_t, but we should really strive not to use them, if given a choice, eh? You think there are any systems we will ever care about that don't offer a 64 bit off_t (or off64_t, or whatever). - Jay From: hosking at To: jkrell at Date: Sun, 4 Jan 2009 12:57:28 +1100CC: m3commit at elegosoft.comSubject: Re: [M3commit] CVS Update: cm3On some platforms off_t is not 64 bits. This from Solaris (see off_t==long): #if defined(_LARGEFILE_SOURCE) || defined(_XPG5) #ifndef _OFF_T #define _OFF_T #if defined(_LP64) || _FILE_OFFSET_BITS == 32 typedef long off_t; #else typedef __longlong_t off_t; #endif #ifdef _LARGEFILE64_SOURCE #ifdef _LP64 typedef off_t off64_t; #else typedef __longlong_t off64_t; #endif #endif /* _LARGEFILE64_SOURCE */ #endif /* _OFF_T */ #endif /* _LARGEFILE_SOURCE * Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 4 Jan 2009, at 01:53, Jay Krell wrote: CVSROOT: /usr/cvsChanges by: jkrell at birch. 09/01/04 01:53:03Modified files:cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utypes.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 Log message:significant reduction in sysdep contentoff_t is always 64 bits (or at least let's hope so)the dir/stat flags are mostly all the same,except for a few that are zero on cygwinM[RWX][OWNER GROUP OTHER][FXWR]_OKF_SETFD, F_GETFL, F_SETFLFIONREADITIMER_REALITIMER_VIRTUALSome of this might be by chance and not by-standard,so under review for new platforms, and probably should be verifiedduring native builds.note that OS/2 has a different S_IFMT but not quite relevant here -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Sun Jan 4 07:10:59 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 7:10:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104061100.33872904003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 07:10:59 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Utime.i3 Log message: fix newlines From jkrell at elego.de Sun Jan 4 07:12:01 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 7:12:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104061201.D8FEE10D5EC8@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 07:12:01 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Utime.i3 Log message: messed this up earlier -- fix ITIMER_REAL and ITIMER_VIRTUAL From jkrell at elego.de Sun Jan 4 07:14:31 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 7:14:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104061431.A8CEC10D5EC8@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 07:14:31 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Utime.i3 Log message: fix.. From jkrell at elego.de Sun Jan 4 08:03:58 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 8:03:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104070359.010CE10D5EC7@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 08:03:58 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: FilePosixC.c Log message: use correct define for 64 bit file offsets; not sure if it matters here or not From jkrell at elego.de Sun Jan 4 08:04:33 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 8:04:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104070433.68A5010D5EC7@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 08:04:33 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: FSPosix.m3 m3makefile Added files: cm3/m3-libs/libm3/src/os/POSIX/: FSPosixC.c FSPosixC.i3 Log message: replace the lone use of wrapped readdir with a smaller bit of C From jkrell at elego.de Sun Jan 4 08:07:13 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 8:07:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104070713.E95A410D5EC7@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 08:07:13 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Udir.i3 m3makefile cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 Removed files: cm3/m3-libs/m3core/src/unix/Common/: UdirC.c cm3/m3-libs/m3core/src/unix/openbsd-common/: Udir.i3 Log message: remove dirent and varyingly wrapped readdir, having removed the only use pkgtools also uses dirent, but in a way that has 'never' worked on many platforms (e.g. LINUXLIBC), it uses a non-opaque DIR, which POSIX doesn't allow for, and none of the pkgtools directories currently builds; the code using non-opaque DIR could use realpath or something else From jkrell at elego.de Sun Jan 4 08:32:10 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 4 Jan 2009 8:32:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090104073211.7FC2810D5EC8@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/04 08:32:10 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Log message: fix PPC_LINUX, AMD64_LINUX, *_OPENBSD, I thought I already done this -- give them the m3_setitimer function From hosking at cs.purdue.edu Sun Jan 4 05:54:48 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 4 Jan 2009 15:54:48 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20090104005303.84C7110D5E9A@birch.elegosoft.com> <13927A2A-F535-48EB-9A33-4813E2B74442@cs.purdue.edu> Message-ID: <40684423-F337-4C58-BC88-7A0AB7085CF9@cs.purdue.edu> Why not just switch between 32-bit and 64-bit versions. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 4 Jan 2009, at 13:22, Jay wrote: > But how about if we always #define _FILE_OFFSET_BITS 64 and use C > wrappers? > As I have done. > Or externs with "64" appended, but that prevents me from using one > set of .i3 files. > > I mean, I know there are "modes" with 32 bit off_t, but we should > really strive not to use them, if given a choice, eh? > > You think there are any systems we will ever care about that don't > offer a 64 bit off_t (or off64_t, or whatever). > > - Jay > > > From: hosking@ > To: jkrell@ > Date: Sun, 4 Jan 2009 12:57:28 +1100 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > On some platforms off_t is not 64 bits. This from Solaris (see > off_t==long): > > #if defined(_LARGEFILE_SOURCE) || defined(_XPG5) > #ifndef _OFF_T > #define _OFF_T > #if defined(_LP64) || _FILE_OFFSET_BITS == 32 > typedef long off_t; > #else > typedef __longlong_t off_t; > #endif > #ifdef _LARGEFILE64_SOURCE > #ifdef _LP64 > typedef off_t off64_t; > #else > typedef __longlong_t off64_t; > #endif > #endif /* _LARGEFILE64_SOURCE */ > #endif /* _OFF_T */ > #endif /* _LARGEFILE_SOURCE * > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > On 4 Jan 2009, at 01:53, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/01/04 01:53:03 > > Modified files: > cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utypes.i3 > cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 > > Log message: > significant reduction in sysdep content > > off_t is always 64 bits (or at least let's hope so) > the dir/stat flags are mostly all the same, > except for a few that are zero on cygwin > > M[RWX][OWNER GROUP OTHER] > [FXWR]_OK > F_SETFD, F_GETFL, F_SETFL > FIONREAD > ITIMER_REAL > ITIMER_VIRTUAL > > Some of this might be by chance and not by-standard, > so under review for new platforms, and probably should be verified > during native builds. > > note that OS/2 has a different S_IFMT but not quite relevant here > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 4 09:35:40 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 4 Jan 2009 08:35:40 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <40684423-F337-4C58-BC88-7A0AB7085CF9@cs.purdue.edu> References: <20090104005303.84C7110D5E9A@birch.elegosoft.com> <13927A2A-F535-48EB-9A33-4813E2B74442@cs.purdue.edu> <40684423-F337-4C58-BC88-7A0AB7085CF9@cs.purdue.edu> Message-ID: Exactly how? Like off_t == word? That isn't right. Switch which files? I want to reduce switching more than what is needed. Can the string in an extern be "forwarded"? That would be the ideal granularity here. Darwin does stuff very similar or maybe the same as I am doing -- wrapper functions in C for reasons related to off_t, though the wrappers are a bit dubious, e.g.: int m3_pread(int d, void *buf, size_t nbytes, int offset){ off_t off = (off_t)offset; return pread(d, buf, nbytes, offset);} int m3_profil(char *samples, size_t size, u_long offset, u_int scale){ off_t off = (off_t)offset; return profil(samples, size, offset, scale);} int m3_pwrite(int d, const void *buf, size_t nbytes, int offset){ off_t off = (off_t)offset; return pwrite(d, buf, nbytes, offset);} int m3_ftruncate(int fd, int length){ off_t len = (off_t) length; return ftruncate(fd, length);} What does the first line of each of those accomplish? voidm3_assignOffT (off_t* dest, long src){ *dest = (off_t)src;} Is that widening or narrowing, and if it is narrowing, silent truncation? Granted, Modula-3 doesn't check for integer overflow anyway, so silent truncation I guess is "ok". Ideally, every system would have a 64 bit off_t, if not the default, at least via #defines, or using function names with "64" appended (or both). The case for 32bit off_t would be interop with existing code. Otherwise, it seems clear that it should always, if possible, be 64 bits. time_t should be 64 bits too, but that's another matter. I did just check and DJGPP seems limited to 32bit off_t. So eventually it might have to go back to Usysdep.i3, but ok. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Sun, 4 Jan 2009 15:54:48 +1100CC: m3commit at elegosoft.comSubject: Re: [M3commit] CVS Update: cm3Why not just switch between 32-bit and 64-bit versions. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 4 Jan 2009, at 13:22, Jay wrote: But how about if we always #define _FILE_OFFSET_BITS 64 and use C wrappers? As I have done. Or externs with "64" appended, but that prevents me from using one set of .i3 files. I mean, I know there are "modes" with 32 bit off_t, but we should really strive not to use them, if given a choice, eh? You think there are any systems we will ever care about that don't offer a 64 bit off_t (or off64_t, or whatever). - Jay From: hosking at To: jkrell at Date: Sun, 4 Jan 2009 12:57:28 +1100CC: m3commit at elegosoft.comSubject: Re: [M3commit] CVS Update: cm3On some platforms off_t is not 64 bits. This from Solaris (see off_t==long): #if defined(_LARGEFILE_SOURCE) || defined(_XPG5) #ifndef _OFF_T #define _OFF_T #if defined(_LP64) || _FILE_OFFSET_BITS == 32 typedef long off_t; #else typedef __longlong_t off_t; #endif #ifdef _LARGEFILE64_SOURCE #ifdef _LP64 typedef off_t off64_t; #else typedef __longlong_t off64_t; #endif #endif /* _LARGEFILE64_SOURCE */ #endif /* _OFF_T */ #endif /* _LARGEFILE_SOURCE * Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 4 Jan 2009, at 01:53, Jay Krell wrote: CVSROOT: /usr/cvsChanges by: jkrell at birch. 09/01/04 01:53:03Modified files:cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utypes.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 Log message:significant reduction in sysdep contentoff_t is always 64 bits (or at least let's hope so)the dir/stat flags are mostly all the same,except for a few that are zero on cygwinM[RWX][OWNER GROUP OTHER][FXWR]_OKF_SETFD, F_GETFL, F_SETFLFIONREADITIMER_REALITIMER_VIRTUALSome of this might be by chance and not by-standard,so under review for new platforms, and probably should be verifiedduring native builds.note that OS/2 has a different S_IFMT but not quite relevant here -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Jan 4 11:02:18 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 4 Jan 2009 21:02:18 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20090104005303.84C7110D5E9A@birch.elegosoft.com> <13927A2A-F535-48EB-9A33-4813E2B74442@cs.purdue.edu> <40684423-F337-4C58-BC88-7A0AB7085CF9@cs.purdue.edu> Message-ID: Darwin no longer uses wrapper functions for pread etc. I figured a static switch at build time. On 4 Jan 2009, at 19:35, Jay wrote: > Exactly how? > Like off_t == word? > That isn't right. > > Switch which files? > I want to reduce switching more than what is needed. > Can the string in an extern be "forwarded"? > That would be the ideal granularity here. > Darwin does stuff very similar or maybe the same as I am doing -- > wrapper functions in C for reasons related to off_t, though the > wrappers are a bit dubious, e.g.: > > int m3_pread(int d, void *buf, size_t nbytes, int offset) > { > off_t off = (off_t)offset; > return pread(d, buf, nbytes, offset); > } > > int m3_profil(char *samples, size_t size, u_long offset, u_int scale) > { > off_t off = (off_t)offset; > return profil(samples, size, offset, scale); > } > > int m3_pwrite(int d, const void *buf, size_t nbytes, int offset) > { > off_t off = (off_t)offset; > return pwrite(d, buf, nbytes, offset); > } > > int m3_ftruncate(int fd, int length) > { > off_t len = (off_t) length; > return ftruncate(fd, length); > } > > What does the first line of each of those accomplish? > > void > m3_assignOffT (off_t* dest, long src) > { > *dest = (off_t)src; > } > > Is that widening or narrowing, and if it is narrowing, silent > truncation? > Granted, Modula-3 doesn't check for integer overflow anyway, so > silent truncation I guess is "ok". > > Ideally, every system would have a 64 bit off_t, if not the default, > at least via #defines, or using function names with "64" appended > (or both). The case for 32bit off_t would be interop with existing > code. Otherwise, it seems clear that it should always, if possible, > be 64 bits. time_t should be 64 bits too, but that's another matter. > > I did just check and DJGPP seems limited to 32bit off_t. > So eventually it might have to go back to Usysdep.i3, but ok. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Sun, 4 Jan 2009 15:54:48 +1100 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Why not just switch between 32-bit and 64-bit versions. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > On 4 Jan 2009, at 13:22, Jay wrote: > > But how about if we always #define _FILE_OFFSET_BITS 64 and use C > wrappers? > As I have done. > Or externs with "64" appended, but that prevents me from using one > set of .i3 files. > > I mean, I know there are "modes" with 32 bit off_t, but we should > really strive not to use them, if given a choice, eh? > > You think there are any systems we will ever care about that don't > offer a 64 bit off_t (or off64_t, or whatever). > > - Jay > > > From: hosking@ > To: jkrell@ > Date: Sun, 4 Jan 2009 12:57:28 +1100 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > On some platforms off_t is not 64 bits. This from Solaris (see > off_t==long): > > #if defined(_LARGEFILE_SOURCE) || defined(_XPG5) > #ifndef _OFF_T > #define _OFF_T > #if defined(_LP64) || _FILE_OFFSET_BITS == 32 > typedef long off_t; > #else > typedef __longlong_t off_t; > #endif > #ifdef _LARGEFILE64_SOURCE > #ifdef _LP64 > typedef off_t off64_t; > #else > typedef __longlong_t off64_t; > #endif > #endif /* _LARGEFILE64_SOURCE */ > #endif /* _OFF_T */ > #endif /* _LARGEFILE_SOURCE * > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > On 4 Jan 2009, at 01:53, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/01/04 01:53:03 > > Modified files: > cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utypes.i3 > cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 > cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 > > Log message: > significant reduction in sysdep content > > off_t is always 64 bits (or at least let's hope so) > the dir/stat flags are mostly all the same, > except for a few that are zero on cygwin > > M[RWX][OWNER GROUP OTHER] > [FXWR]_OK > F_SETFD, F_GETFL, F_SETFL > FIONREAD > ITIMER_REAL > ITIMER_VIRTUAL > > Some of this might be by chance and not by-standard, > so under review for new platforms, and probably should be verified > during native builds. > > note that OS/2 has a different S_IFMT but not quite relevant here > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Mon Jan 5 04:53:07 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 4:53:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105035307.89FBE220043C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 04:53:07 Modified files: cm3/m3-libs/m3core/src/: Uwaitpid.quake m3makefile cm3/m3-libs/m3core/src/runtime/POSIX/: m3makefile Log message: try again to deal with m3unix.h, perhaps in a way that works with cross bootstrapping From jkrell at elego.de Mon Jan 5 05:19:08 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 5:19:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105041908.CC15010D582F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 05:19:08 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Udir.i3 Uexec.i3 Unetdb.i3 Unix.i3 Uprocess.i3 Upthread.i3 Upwd.i3 Uresource.i3 Usched.i3 Usem.i3 Usignal.i3 Usocket.i3 Ustat.i3 Utime.i3 Uugid.i3 Uuio.i3 Log message: Well, what do you know..I go looking into the compiler for a purpose too much to describe here, and I find that entire interfaces can be marked external, cool. From jkrell at elego.de Mon Jan 5 05:28:20 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 5:28:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105042820.B0BAB10D582F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 05:28:20 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: FilePosix.m3 Log message: remove a few tabs From jkrell at elego.de Mon Jan 5 05:37:13 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 5:37:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105043713.783AD10D5E5B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 05:37:13 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: FilePosix.m3 Log message: reduce but don't eliminate race condition; before there was a race in a multithreaded code, now there is 'only' a race in multithreaded code under optimization that reorders writes (we need MemoryBarrier() for this kind of lock free on demand initialization of globals..) From jkrell at elego.de Mon Jan 5 06:38:01 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 6:38:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105053802.B6F6710D5E65@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 06:38:01 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 Log message: remove a few tabs From jkrell at elego.de Mon Jan 5 06:46:28 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 6:46:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105054628.7E69C10D5E65@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 06:46:28 Modified files: cm3/m3-libs/m3core/src/unix/linux-sparc/: Usocket.i3 Usignal.i3 Log message: make it more like common, for later merge/refactor From jkrell at elego.de Mon Jan 5 07:58:35 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 7:58:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105065835.4E31710D5DD1@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 07:58:35 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile Log message: fix win32, it has its own minimal Unix/Uuio, probably useless From jkrell at elego.de Mon Jan 5 08:25:48 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 8:25:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105072548.AB46610D5D2A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 08:25:48 Modified files: cm3/m3-sys/m3front/src/builtinOps/: Adr.m3 Log message: minor cleanup; should see about switching this? Or removing it? Looks like some indecisiveness and that the switched off way is more type-safe.. From jkrell at elego.de Mon Jan 5 10:37:21 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 10:37:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105093721.E382810D5E7C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 10:37:21 Modified files: cm3/scripts/python/: pylib.py Log message: port CheckForLinkSwitch from scripts/win/sysinfo.cmd, but then, oops, it is redundant, print to make that clearer From jkrell at elego.de Mon Jan 5 10:43:43 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 10:43:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105094343.DA5E110D5E68@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 10:43:43 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Log message: keep the timezone/daylight code out of FreeBSD (tinderbox error) From jkrell at elego.de Mon Jan 5 10:48:34 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 10:48:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105094835.10F7110D5E68@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 10:48:34 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Log message: and NetBSD From jkrell at elego.de Mon Jan 5 10:53:02 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 10:53:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105095302.0802210D5E68@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 10:53:02 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Log message: fix comment From jkrell at elego.de Mon Jan 5 20:10:55 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 20:10:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105191055.CAA2C10D5AF4@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 20:10:55 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: FilePosix.m3 Log message: fix (tinderbox, all posix platforms, I must not have compiled) From jkrell at elego.de Mon Jan 5 20:46:11 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 20:46:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105194611.6CA0B10D5C41@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 20:46:11 Modified files: cm3/m3-libs/m3core/src/runtime/common/: m3makefile Log message: forgot this earlier, only non-mainstream platforms affected From jkrell at elego.de Mon Jan 5 20:54:24 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 20:54:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105195424.0B8ED10D5C41@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 20:54:24 Modified files: cm3/m3-libs/m3core/src/runtime/: m3makefile Removed files: cm3/m3-libs/m3core/src/runtime/AMD64_LINUX/: RTMachine.i3 RTSignal.m3 m3makefile Log message: I thought I commited this last night -- move fairly common files to common directory. Only non-mainstream (so far) platforms affected. RTMachine.i3 might become platform-dependent with user therad support but RTSignal.m3 is quite identical/similar across all platforms, though will shortly be rewritten in C so that we can remove more platform-dependent "cloned headers". From jkrell at elego.de Mon Jan 5 21:04:04 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 21:04:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105200404.B479410D5C41@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 21:04:04 Added files: cm3/m3-libs/m3core/src/runtime/common/: RTMachine.i3 RTSignal.m3 Log message: try try again to add these files (one problem I have is that cvs commit usually crashes on one machine so I have to copy to another) From jkrell at elego.de Mon Jan 5 21:05:33 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 21:05:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105200533.190D110D5C41@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 21:05:33 Added files: cm3/m3-libs/m3core/src/runtime/common/: RTError.h RTProcess.h RTSignalC.c RTSignalC.h m3text.h Log message: work in progress -- rewriting RTSignal.m3 in C saves us from declaring several system-depenedant things in cloned headers, and is easy and portable enough From jkrell at elego.de Mon Jan 5 21:07:51 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 21:07:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105200751.8450810D5C41@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 21:07:51 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTSignal.m3 Log message: the correct version of this -- written in Modula-3 for now From jkrell at elego.de Mon Jan 5 21:33:38 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 21:33:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105203338.0987310D5C41@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 21:33:38 Modified files: cm3/m3-libs/m3core/src/: Uwaitpid.quake Log message: give up on sharing the header and just copy the two lines, alas From jkrell at elego.de Mon Jan 5 23:33:05 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 23:33:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105223305.8F54D10D59A7@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 23:33:05 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTSignal.m3 Log message: fix paste error From jkrell at elego.de Mon Jan 5 23:34:43 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 5 Jan 2009 23:34:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105223443.9EB2610D59A7@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/05 23:34:43 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTLinkerC.c Log message: remove tab From jkrell at elego.de Tue Jan 6 00:33:06 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 6 Jan 2009 0:33:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090105233322.4C3E510D582D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/06 00:33:05 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: fix newline From jkrell at elego.de Tue Jan 6 12:07:04 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 6 Jan 2009 12:07:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090106110704.5AFAC10D5CFC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/06 12:07:04 Modified files: cm3/m3-libs/m3core/src/: Uwaitpid.quake Log message: need sys/types on Linux From jkrell at elego.de Thu Jan 8 01:02:02 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 8 Jan 2009 1:02:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090108000202.8643E904006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/08 01:02:01 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile Log message: sort the list From hosking at elego.de Fri Jan 9 04:43:17 2009 From: hosking at elego.de (Antony Hosking) Date: Fri, 9 Jan 2009 4:43:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090109034317.8FD97220004B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 09/01/09 04:43:17 Modified files: cm3/m3-libs/m3core/src/convert/: CConvert.i3 CConvert.m3 Convert.m3 Log message: Fix space leak in calls to dtoa. The result must be freed using freedtoa. From hosking at elego.de Fri Jan 9 21:43:00 2009 From: hosking at elego.de (Antony Hosking) Date: Fri, 9 Jan 2009 21:43:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090109204300.E5218904007@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 09/01/09 21:43:00 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: dtoa.h Log message: Oops, forgot this which has m3_freedtoa. From jkrell at elego.de Sat Jan 10 14:02:13 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 10 Jan 2009 14:02:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090110130219.4A91790403A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/10 14:02:08 Modified files: cm3/scripts/python/: pylib.py Log message: AMD64_FREEBSD support; put .SUFFIXES in boot makefile to avoid a bunch of warnings about circularity (there is a builtin rule for these suffixes?); add RTSignalC.c to bootstrap packages (if it exists, as usual) From jkrell at elego.de Sat Jan 10 14:36:57 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 10 Jan 2009 14:36:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090110133657.203E810D4E24@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/10 14:36:57 Modified files: cm3/scripts/python/: pylib.py Log message: SPARC64_LINUX needs -Av9 switch on gas to assemble, though the result still hangs (-64 selects 64 bit ELF, -Av9 selects V9 architecture; there is also V9a and V9b, but V9 seems to suffice) From jkrell at elego.de Sun Jan 11 00:19:00 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 0:19:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090110231900.228A5904006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 00:19:00 Modified files: cm3/m3-libs/m3core/src/unix/freebsd-4/: Upthread.i3 Log message: remove unused import to remove warning From jkrell at elego.de Sun Jan 11 00:19:38 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 0:19:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090110231938.7B813904006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 00:19:38 Modified files: cm3/m3-libs/m3core/src/unix/openbsd-common/: m3makefile Log message: Udir not here any longer From jkrell at elego.de Sun Jan 11 00:43:18 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 0:43:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090110234318.24C6010D458D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 00:43:18 Modified files: cm3/m3-libs/m3core/src/runtime/common/: m3text.h RTError.h RTProcess.h RTSignalC.c RTSignalC.h Added files: cm3/m3-libs/m3core/src/runtime/common/: RTSignalC.i3 Log message: add extern "C" prepare for more Usignal reduction and AMD64_FREEBSD port From jkrell at elego.de Sun Jan 11 00:46:42 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 0:46:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090110234642.A060710D458D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 00:46:42 Added files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThreadC.c ThreadPThreadC.i3 Log message: prepare for Usignal reduction and AMD64_FREEBSD port From jkrell at elego.de Sun Jan 11 00:48:55 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 0:48:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090110234855.A764610D535B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 00:48:55 Added files: cm3/m3-sys/cminstall/src/config-no-install/: FreeBSD4 AMD64_FREEBSD Log message: AMD64_FREEBSD support and at least partial FreeBSD4 (for some significant level of verification via cross building) From jkrell at elego.de Sun Jan 11 01:00:38 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 1:00:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111000039.2EB80904006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 01:00:38 Added files: cm3/m3-libs/m3core/src/C/AMD64_FREEBSD/: m3makefile Csetjmp.i3 Log message: add files for AMD64_FREEBSD; diffs later From jkrell at elego.de Sun Jan 11 01:01:15 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 1:01:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111000116.0835A10D5D5D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 01:01:15 Added files: cm3/m3-libs/m3core/src/unix/freebsd-common/: m3makefile Uerror.i3 Usysdep.i3 Uucontext.i3 Log message: add files for AMD64_FREEBSD; diffs later From jkrell at elego.de Sun Jan 11 01:44:47 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 1:44:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111004447.5014E10D535B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 01:44:47 Modified files: cm3/m3-libs/m3core/src/C/PPC_LINUX/: Csetjmp.i3 Log message: remove use of sigset_t so we can prune Usignal; just make the thing properly sized with opaque data; note that it is declared in C as being aligned to 16 bytes but we can't declare that and the comments in the C header say that is ok From jkrell at elego.de Sun Jan 11 01:45:08 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 1:45:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111004509.461AE10D535B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 01:45:08 Modified files: cm3/m3-libs/m3core/src/C/PPC_LINUX/: Csetjmp.i3 Log message: opaque From jkrell at elego.de Sun Jan 11 14:35:04 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 14:35:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111133509.AF03F10D5DA3@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 14:35:04 Modified files: cm3/m3-ui/ui/src/xvbt/: XSharedMem.m3 Log message: workaround fatal error starting up remoted X apps on FreeBSD by cloning underlying function and indicating if it would raise its fatal error; more insight would be welcome here; note that for local X apps (ie: if $DISPLAY is not set) there is no impact, other than allocating a lock From jkrell at elego.de Sun Jan 11 14:50:57 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 14:50:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 14:50:57 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: OSConfigPosix.m3 cm3/m3-libs/libm3/src/random/: m3makefile cm3/m3-libs/m3core/src/: thread.quake cm3/m3-libs/m3core/src/C/Common/: m3makefile cm3/m3-libs/m3core/src/Csupport/: m3makefile cm3/m3-libs/m3core/src/float/: m3makefile cm3/m3-libs/m3core/src/runtime/: m3makefile cm3/m3-libs/m3core/src/runtime/common/: Compiler.tmpl RTLinkerC.c RTMachine.i3 RTSignal.m3 m3makefile cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 ThreadPThreadC.c ThreadPThreadC.i3 m3makefile cm3/m3-libs/m3core/src/time/POSIX/: m3makefile cm3/m3-libs/m3core/src/unix/: m3makefile cm3/m3-libs/m3core/src/unix/Common/: Usem.i3 Usignal.i3 m3makefile cm3/m3-libs/m3core/src/unix/freebsd-common/: Usysdep.i3 m3makefile cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-sparc/: Usignal.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 m3makefile cm3/m3-sys/m3cc/src/: m3makefile cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 cm3/scripts/python/: pylib.py cm3/www/uploaded-archives/: targets.txt Added files: cm3/m3-libs/m3core/src/unix/Common/: Uucontext.i3 Removed files: cm3/m3-libs/m3core/src/unix/freebsd-common/: Uucontext.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Uucontext.i3 Log message: AMD64_FREEBSD port add a few more files to bootstrap archives Usignal reduction, remove: SIGHUP SIGQUIT SIGABRT SIGSEGV SIGPIPE SIGTERM NSIG (Linux specific) SA_RESTART SA_SIGINFO SignalHandler sigset_t siginfo_t_star struct_sigaction (important) sigaction (would be ok, but no longer used) sigdelset (would be ok, but no longer used) sigemptyset (would be ok, but no longer used) sigfillset (would be ok, but no longer used) sigpending (would be ok, but no longer used) sigprocmask (would be ok, but no longer used) make common: SignalActionHandler Uucontext, just ucontext_t_star = ADDRESS; sigset_t removed have Usysdep define SIG_SUSPEND instead of going through Usignal intermediate remove sem_t header clone; declare the variable in C likewise Upthread.mask speculatively add some more targets to m3-sys/m3cc/src/m3makefile, some of which have had backends built, but not all From jkrell at elego.de Sun Jan 11 15:20:14 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 15:20:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111142016.98AB410D5D5D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 15:20:14 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: outputing to _m3.log failing for some reason on SPARC32_LINUX, remove (temporary?) From jkrell at elego.de Sun Jan 11 15:29:16 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 15:29:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111142916.72D7B714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 15:29:16 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 ThreadPThreadC.i3 Log message: Some platforms call SignalActionHandler just 'SignalAction'. Drop the Usignal depdenency and just declare it ourselves here. From jkrell at elego.de Sun Jan 11 15:31:25 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 15:31:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111143125.B7E2B10D5C59@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 15:31:25 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: remove unused import Uucontext From jkrell at elego.de Sun Jan 11 15:32:36 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 15:32:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111143236.2C55B10D5C59@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 15:32:36 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThreadC.c Log message: fix newlines From jkrell at elego.de Sun Jan 11 23:46:40 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 23:46:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111224641.4BD58714574@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 23:46:40 Modified files: cm3/m3-libs/m3core/src/unix/Common/: m3makefile cm3/www/uploaded-archives/: targets.txt Log message: fix newlines From jkrell at elego.de Sun Jan 11 23:48:04 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 11 Jan 2009 23:48:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111224804.5855C714573@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/11 23:48:04 Modified files: cm3/m3-libs/m3core/src/unix/linux-32/: m3makefile Removed files: cm3/m3-libs/m3core/src/unix/linux-32/: Uucontext.i3 Log message: no more platform specific Uucontext (in some ports) From jkrell at elego.de Mon Jan 12 00:08:24 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 0:08:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111230824.8F8E710D5FAD@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 00:08:24 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: if ROOT is not defined (the root of the source tree), don't probe, rather than erroring for lack of ROOT From jkrell at elego.de Mon Jan 12 00:08:39 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 0:08:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111230839.AEC1910D5FAD@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 00:08:39 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: backwards From jkrell at elego.de Mon Jan 12 00:34:41 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 0:34:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090111233442.57DE510D5FB1@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 00:34:41 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThreadC.c Log message: make the assertions actually check each call, not just the first, duh From jkrell at elego.de Mon Jan 12 01:49:11 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 1:49:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112004911.D509F10D5FB5@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 01:49:11 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: SocketPosix.m3 Log message: change switches to if ladders so that Uerror can change constants to variables and replace system dependent cloned headers with portable C From hosking at cs.purdue.edu Mon Jan 12 01:59:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 11:59:07 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20090112004911.D509F10D5FB5@birch.elegosoft.com> References: <20090112004911.D509F10D5FB5@birch.elegosoft.com> Message-ID: <7F816AC4-68DD-4881-97A8-08C973E97E1A@cs.purdue.edu> Jay, I really don't like this. What's wrong with constants again? On 12 Jan 2009, at 01:49, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/01/12 01:49:11 > > Modified files: > cm3/m3-libs/libm3/src/os/POSIX/: SocketPosix.m3 > > Log message: > change switches to if ladders so that Uerror can change constants > to variables and replace system dependent cloned headers with > portable C From jay.krell at cornell.edu Mon Jan 12 07:44:20 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 06:44:20 +0000 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> Message-ID: I basically agree here. I view thread.quake as temporary. Once m3core (that you bootstrap from) has SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. Or some other fix involving sysutils not knowing this (it sounds like you an easy one that I missed). And then the code that is generated when building m3core can be the exact checked in code, was my intention. I guess what I could/should have done is just put in SchedulerPosix.DoesWaitYield, wait some amount of time, and then move sysutils over it, not fix sysutils asap. I can go ahead and do that now -- "fix" m3core, re-"break" (slow down) sysutils, and then at whatever time, have sysutils use the new function. I had noticed cygwin builds seeming to take way way longer than I remember, like >12 hours instead of <1hour. I didn't track down if this is the cause. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:18:29 +1100> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > I really hate the idea that thread.quake exists.> > Screw sysutils working against old m3core versions. sysutils doing > thread-related scheduling is a big hack, and should be killed now > before it infects others. I don't want to see thread-dependent code > outside of m3core. We really need to come to consensus on this before > you do more damage to the core thread libraries.> > I feel strongly about this!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 07:49:55 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 17:49:55 +1100 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> Message-ID: <2599269D-3447-4D5C-8D8B-2A535027EBCF@cs.purdue.edu> Why do you need DoesWaitPidYield? As I mentioned in another post, fixing sysutils to use a properly scheduled version of waitpid is trivial. I don't think you need all this DoesWaitPidYield junk. Frankly, I think the threads code is now a mess and needs to be reverted. On 12 Jan 2009, at 17:44, Jay wrote: > I basically agree here. > I view thread.quake as temporary. > Once m3core (that you bootstrap from) has > SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. > Or some other fix involving sysutils not knowing this (it sounds > like you an easy one that I missed). > > And then the code that is generated when building m3core can be the > exact checked in code, was my intention. > > I guess what I could/should have done is just put in > SchedulerPosix.DoesWaitYield, wait some amount of time, and then > move sysutils over it, not fix sysutils asap. > > I can go ahead and do that now -- "fix" m3core, re-"break" (slow > down) sysutils, and then at whatever time, have sysutils use the new > function. > > I had noticed cygwin builds seeming to take way way longer than I > remember, like >12 hours instead of <1hour. I didn't track down if > this is the cause. > > - Jay > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:18:29 +1100 > > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > I really hate the idea that thread.quake exists. > > > > Screw sysutils working against old m3core versions. sysutils doing > > thread-related scheduling is a big hack, and should be killed now > > before it infects others. I don't want to see thread-dependent code > > outside of m3core. We really need to come to consensus on this > before > > you do more damage to the core thread libraries. > > > > I feel strongly about this! > > > > -- Tony > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 08:01:50 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 07:01:50 +0000 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: <2599269D-3447-4D5C-8D8B-2A535027EBCF@cs.purdue.edu> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <2599269D-3447-4D5C-8D8B-2A535027EBCF@cs.purdue.edu> Message-ID: I need to go back and study that. It implies I missed something big when I made the change. I could have sworn I looked at the functions and decided one could not be implemented on top of the other but it sounds like I missed one. Hold on. DoesWaitPidYield is not the problem really though. We agree, at its worst, it would be cloned, in regular Modula-3 code (not quake). At its best, it would be gone. The bigger change is sharing the SchedulerPosix implementation on Win32 threads for Cygwin. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 17:49:55 +1100CC: m3devel at elegosoft.com; m3commit at elegosoft.comSubject: Re: [M3commit] [M3devel] CVS Update: cm3Why do you need DoesWaitPidYield? As I mentioned in another post, fixing sysutils to use a properly scheduled version of waitpid is trivial. I don't think you need all this DoesWaitPidYield junk. Frankly, I think the threads code is now a mess and needs to be reverted. On 12 Jan 2009, at 17:44, Jay wrote: I basically agree here.I view thread.quake as temporary.Once m3core (that you bootstrap from) has SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. Or some other fix involving sysutils not knowing this (it sounds like you an easy one that I missed). And then the code that is generated when building m3core can be the exact checked in code, was my intention. I guess what I could/should have done is just put in SchedulerPosix.DoesWaitYield, wait some amount of time, and then move sysutils over it, not fix sysutils asap. I can go ahead and do that now -- "fix" m3core, re-"break" (slow down) sysutils, and then at whatever time, have sysutils use the new function. I had noticed cygwin builds seeming to take way way longer than I remember, like >12 hours instead of <1hour. I didn't track down if this is the cause. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:18:29 +1100> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > I really hate the idea that thread.quake exists.> > Screw sysutils working against old m3core versions. sysutils doing > thread-related scheduling is a big hack, and should be killed now > before it infects others. I don't want to see thread-dependent code > outside of m3core. We really need to come to consensus on this before > you do more damage to the core thread libraries.> > I feel strongly about this!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 08:05:48 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 18:05:48 +1100 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <2599269D-3447-4D5C-8D8B-2A535027EBCF@cs.purdue.edu> Message-ID: <7A6A105A-B305-4F14-91D2-1D2DC6F09BEC@cs.purdue.edu> I think the whole DoesWaitPidYield thing is a red herring. Can you just wait for me to put in my fix to the CVS head and you can look and see what you think? I would really like to reinstate the original structure for m3core/src/thread too, but I don't know what the constraints are w.r.to your C header file hacking and the need for Cygwin to have a SchedulerPosix implementation. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 12 Jan 2009, at 18:01, Jay wrote: > I need to go back and study that. It implies I missed something big > when I made the change. > I could have sworn I looked at the functions and decided one could > not be implemented > on top of the other but it sounds like I missed one. Hold on. > > DoesWaitPidYield is not the problem really though. > We agree, at its worst, it would be cloned, in regular Modula-3 code > (not quake). > At its best, it would be gone. > > The bigger change is sharing the SchedulerPosix implementation on > Win32 threads for Cygwin. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 17:49:55 +1100 > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > Subject: Re: [M3commit] [M3devel] CVS Update: cm3 > > Why do you need DoesWaitPidYield? As I mentioned in another post, > fixing sysutils to use a properly scheduled version of waitpid is > trivial. I don't think you need all this DoesWaitPidYield junk. > > Frankly, I think the threads code is now a mess and needs to be > reverted. > > On 12 Jan 2009, at 17:44, Jay wrote: > > I basically agree here. > I view thread.quake as temporary. > Once m3core (that you bootstrap from) has > SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. > Or some other fix involving sysutils not knowing this (it sounds > like you an easy one that I missed). > > And then the code that is generated when building m3core can be the > exact checked in code, was my intention. > > I guess what I could/should have done is just put in > SchedulerPosix.DoesWaitYield, wait some amount of time, and then > move sysutils over it, not fix sysutils asap. > > I can go ahead and do that now -- "fix" m3core, re-"break" (slow > down) sysutils, and then at whatever time, have sysutils use the new > function. > > I had noticed cygwin builds seeming to take way way longer than I > remember, like >12 hours instead of <1hour. I didn't track down if > this is the cause. > > - Jay > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:18:29 +1100 > > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > I really hate the idea that thread.quake exists. > > > > Screw sysutils working against old m3core versions. sysutils doing > > thread-related scheduling is a big hack, and should be killed now > > before it infects others. I don't want to see thread-dependent code > > outside of m3core. We really need to come to consensus on this > before > > you do more damage to the core thread libraries. > > > > I feel strongly about this! > > > > -- Tony > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 08:07:18 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 18:07:18 +1100 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> Message-ID: <66E87543-8486-4377-9405-2912E14CD96E@cs.purdue.edu> PS What is the name ThreadPScheduler supposed to connote? On 12 Jan 2009, at 17:44, Jay wrote: > I basically agree here. > I view thread.quake as temporary. > Once m3core (that you bootstrap from) has > SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. > Or some other fix involving sysutils not knowing this (it sounds > like you an easy one that I missed). > > And then the code that is generated when building m3core can be the > exact checked in code, was my intention. > > I guess what I could/should have done is just put in > SchedulerPosix.DoesWaitYield, wait some amount of time, and then > move sysutils over it, not fix sysutils asap. > > I can go ahead and do that now -- "fix" m3core, re-"break" (slow > down) sysutils, and then at whatever time, have sysutils use the new > function. > > I had noticed cygwin builds seeming to take way way longer than I > remember, like >12 hours instead of <1hour. I didn't track down if > this is the cause. > > - Jay > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:18:29 +1100 > > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > I really hate the idea that thread.quake exists. > > > > Screw sysutils working against old m3core versions. sysutils doing > > thread-related scheduling is a big hack, and should be killed now > > before it infects others. I don't want to see thread-dependent code > > outside of m3core. We really need to come to consensus on this > before > > you do more damage to the core thread libraries. > > > > I feel strongly about this! > > > > -- Tony > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 08:13:35 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 07:13:35 +0000 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: <7A6A105A-B305-4F14-91D2-1D2DC6F09BEC@cs.purdue.edu> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <2599269D-3447-4D5C-8D8B-2A535027EBCF@cs.purdue.edu> <7A6A105A-B305-4F14-91D2-1D2DC6F09BEC@cs.purdue.edu> Message-ID: I can wait but I really don't think this structure is so awful, rehosting one SchedulerPosix implementation on top of two different threading libraries. Maybe just let Cygwin die? Was the restructuring to use "spawn" sometimes instead of fork/exec also so bad? I actually find that hard to read, but it is theoretically a very large improvement.Cygwin really fails badly compared to "Posix" in fork perf, even if the semantic matches. (and vfork, which is what Modula-3 uses, doesn't help. Cygwin's vfork == fork, both slow.) It is contorted also, but you know, we can't use a line by line #ifdef, so we have to break stuff up into separate files, which often seems less clear (but sometimes is more clear, it depends on how much is different and how much the same; the more that is the same, the better to have #ifdef, the more that is different, the better to have separate files). Or, can I replit out SchedulerPosix after you apply your "actual" changes -- you know, just a way to avoid the merge, but keep the contituent diffs? - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:05:48 +1100CC: m3devel at elegosoft.com; m3commit at elegosoft.comSubject: Re: [M3commit] [M3devel] CVS Update: cm3I think the whole DoesWaitPidYield thing is a red herring. Can you just wait for me to put in my fix to the CVS head and you can look and see what you think? I would really like to reinstate the original structure for m3core/src/thread too, but I don't know what the constraints are w.r.to your C header file hacking and the need for Cygwin to have a SchedulerPosix implementation. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 12 Jan 2009, at 18:01, Jay wrote: I need to go back and study that. It implies I missed something big when I made the change.I could have sworn I looked at the functions and decided one could not be implementedon top of the other but it sounds like I missed one. Hold on. DoesWaitPidYield is not the problem really though.We agree, at its worst, it would be cloned, in regular Modula-3 code (not quake).At its best, it would be gone. The bigger change is sharing the SchedulerPosix implementation on Win32 threads for Cygwin. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 17:49:55 +1100CC: m3devel at elegosoft.com; m3commit at elegosoft.comSubject: Re: [M3commit] [M3devel] CVS Update: cm3Why do you need DoesWaitPidYield? As I mentioned in another post, fixing sysutils to use a properly scheduled version of waitpid is trivial. I don't think you need all this DoesWaitPidYield junk. Frankly, I think the threads code is now a mess and needs to be reverted. On 12 Jan 2009, at 17:44, Jay wrote: I basically agree here.I view thread.quake as temporary.Once m3core (that you bootstrap from) has SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. Or some other fix involving sysutils not knowing this (it sounds like you an easy one that I missed). And then the code that is generated when building m3core can be the exact checked in code, was my intention. I guess what I could/should have done is just put in SchedulerPosix.DoesWaitYield, wait some amount of time, and then move sysutils over it, not fix sysutils asap. I can go ahead and do that now -- "fix" m3core, re-"break" (slow down) sysutils, and then at whatever time, have sysutils use the new function. I had noticed cygwin builds seeming to take way way longer than I remember, like >12 hours instead of <1hour. I didn't track down if this is the cause. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:18:29 +1100> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > I really hate the idea that thread.quake exists.> > Screw sysutils working against old m3core versions. sysutils doing > thread-related scheduling is a big hack, and should be killed now > before it infects others. I don't want to see thread-dependent code > outside of m3core. We really need to come to consensus on this before > you do more damage to the core thread libraries.> > I feel strongly about this!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 08:15:41 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 07:15:41 +0000 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: <66E87543-8486-4377-9405-2912E14CD96E@cs.purdue.edu> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <66E87543-8486-4377-9405-2912E14CD96E@cs.purdue.edu> Message-ID: It is ambiguous, I admit. Feel free to suggest another name. It is PosixScheduler.i3 implementation for Cygwin and pthreads. You could call it PosixSchedulerKernel.m3? PosixScheduler.i3 for threads that are kernel threads? You know -- what does "pthreads" mean -- posix threads, but we have ThreadPThread and ThreadPosix. Also wierd. But ok. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:07:18 +1100CC: jkrell at elego.de; m3devel at elegosoft.com; m3commit at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3PS What is the name ThreadPScheduler supposed to connote? On 12 Jan 2009, at 17:44, Jay wrote: I basically agree here.I view thread.quake as temporary.Once m3core (that you bootstrap from) has SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. Or some other fix involving sysutils not knowing this (it sounds like you an easy one that I missed). And then the code that is generated when building m3core can be the exact checked in code, was my intention. I guess what I could/should have done is just put in SchedulerPosix.DoesWaitYield, wait some amount of time, and then move sysutils over it, not fix sysutils asap. I can go ahead and do that now -- "fix" m3core, re-"break" (slow down) sysutils, and then at whatever time, have sysutils use the new function. I had noticed cygwin builds seeming to take way way longer than I remember, like >12 hours instead of <1hour. I didn't track down if this is the cause. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:18:29 +1100> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > I really hate the idea that thread.quake exists.> > Screw sysutils working against old m3core versions. sysutils doing > thread-related scheduling is a big hack, and should be killed now > before it infects others. I don't want to see thread-dependent code > outside of m3core. We really need to come to consensus on this before > you do more damage to the core thread libraries.> > I feel strongly about this!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 08:16:34 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 07:16:34 +0000 Subject: [M3commit] FW: [M3devel] CVS Update: cm3 In-Reply-To: <7A6A105A-B305-4F14-91D2-1D2DC6F09BEC@cs.purdue.edu> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <2599269D-3447-4D5C-8D8B-2A535027EBCF@cs.purdue.edu> <7A6A105A-B305-4F14-91D2-1D2DC6F09BEC@cs.purdue.edu> Message-ID: [important points/question truncated -- request permission to reapply scheduler split after you apply your diff] From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.com; m3commit at elegosoft.comSubject: RE: [M3commit] [M3devel] CVS Update: cm3Date: Mon, 12 Jan 2009 07:13:35 +0000 I can wait but I really don't think this structure is so awful, rehosting one SchedulerPosix implementation on top of two different threading libraries. Maybe just let Cygwin die? Was the restructuring to use "spawn" sometimes instead of fork/exec also so bad?I actually find that hard to read, but it is theoretically a very large improvement.Cygwin really fails badly compared to "Posix" in fork perf, even if the semantic matches.(and vfork, which is what Modula-3 uses, doesn't help. Cygwin's vfork == fork, both slow.) It is contorted also, but you know, we can't use a line by line #ifdef, so we have to break stuff up into separate files, which often seems less clear (but sometimes is more clear, it depends on how much is different and how much the same; the more that is the same, the better to have #ifdef, the more that is different, the better to have separate files). Or, can I replit out SchedulerPosix after you apply your "actual" changes -- you know, just a way to avoid the merge, but keep the contituent diffs? - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:05:48 +1100CC: m3devel at elegosoft.com; m3commit at elegosoft.comSubject: Re: [M3commit] [M3devel] CVS Update: cm3I think the whole DoesWaitPidYield thing is a red herring. Can you just wait for me to put in my fix to the CVS head and you can look and see what you think? I would really like to reinstate the original structure for m3core/src/thread too, but I don't know what the constraints are w.r.to your C header file hacking and the need for Cygwin to have a SchedulerPosix implementation. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 12 Jan 2009, at 18:01, Jay wrote: I need to go back and study that. It implies I missed something big when I made the change.I could have sworn I looked at the functions and decided one could not be implementedon top of the other but it sounds like I missed one. Hold on. DoesWaitPidYield is not the problem really though.We agree, at its worst, it would be cloned, in regular Modula-3 code (not quake).At its best, it would be gone. The bigger change is sharing the SchedulerPosix implementation on Win32 threads for Cygwin. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 17:49:55 +1100CC: m3devel at elegosoft.com; m3commit at elegosoft.comSubject: Re: [M3commit] [M3devel] CVS Update: cm3Why do you need DoesWaitPidYield? As I mentioned in another post, fixing sysutils to use a properly scheduled version of waitpid is trivial. I don't think you need all this DoesWaitPidYield junk. Frankly, I think the threads code is now a mess and needs to be reverted. On 12 Jan 2009, at 17:44, Jay wrote: I basically agree here.I view thread.quake as temporary.Once m3core (that you bootstrap from) has SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. Or some other fix involving sysutils not knowing this (it sounds like you an easy one that I missed). And then the code that is generated when building m3core can be the exact checked in code, was my intention. I guess what I could/should have done is just put in SchedulerPosix.DoesWaitYield, wait some amount of time, and then move sysutils over it, not fix sysutils asap. I can go ahead and do that now -- "fix" m3core, re-"break" (slow down) sysutils, and then at whatever time, have sysutils use the new function. I had noticed cygwin builds seeming to take way way longer than I remember, like >12 hours instead of <1hour. I didn't track down if this is the cause. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:18:29 +1100> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > I really hate the idea that thread.quake exists.> > Screw sysutils working against old m3core versions. sysutils doing > thread-related scheduling is a big hack, and should be killed now > before it infects others. I don't want to see thread-dependent code > outside of m3core. We really need to come to consensus on this before > you do more damage to the core thread libraries.> > I feel strongly about this!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 08:22:31 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 18:22:31 +1100 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <66E87543-8486-4377-9405-2912E14CD96E@cs.purdue.edu> Message-ID: ThreadPosix is a historic name for threads built on top of simple POSIX primitives. The name was given before POSIX pthreads were even defined. ThreadPThread describes an implementation of threads built on top of POSIX pthreads. ThreadWin32 describes an implementation of threads built on top of Win32 threads. SchedulerPosix is indeed a misnomer, but again that name is a historic artefact. On 12 Jan 2009, at 18:15, Jay wrote: > It is ambiguous, I admit. > Feel free to suggest another name. > It is PosixScheduler.i3 implementation for Cygwin and pthreads. > You could call it PosixSchedulerKernel.m3? PosixScheduler.i3 for > threads that are kernel threads? > > You know -- what does "pthreads" mean -- posix threads, but we have > ThreadPThread and ThreadPosix. > Also wierd. But ok. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 18:07:18 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com; m3commit at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > PS What is the name ThreadPScheduler supposed to connote? > > > On 12 Jan 2009, at 17:44, Jay wrote: > > I basically agree here. > I view thread.quake as temporary. > Once m3core (that you bootstrap from) has > SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. > Or some other fix involving sysutils not knowing this (it sounds > like you an easy one that I missed). > > And then the code that is generated when building m3core can be the > exact checked in code, was my intention. > > I guess what I could/should have done is just put in > SchedulerPosix.DoesWaitYield, wait some amount of time, and then > move sysutils over it, not fix sysutils asap. > > I can go ahead and do that now -- "fix" m3core, re-"break" (slow > down) sysutils, and then at whatever time, have sysutils use the new > function. > > I had noticed cygwin builds seeming to take way way longer than I > remember, like >12 hours instead of <1hour. I didn't track down if > this is the cause. > > - Jay > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:18:29 +1100 > > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > I really hate the idea that thread.quake exists. > > > > Screw sysutils working against old m3core versions. sysutils doing > > thread-related scheduling is a big hack, and should be killed now > > before it infects others. I don't want to see thread-dependent code > > outside of m3core. We really need to come to consensus on this > before > > you do more damage to the core thread libraries. > > > > I feel strongly about this! > > > > -- Tony > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Mon Jan 12 08:29:56 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 8:29:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112072956.A51FF10D5FCF@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 08:29:56 Modified files: cm3/m3-libs/sysutils/src/POSIX/: m3makefile Log message: use a relative path instead of the ROOT variable that all the scripts define From jkrell at elego.de Mon Jan 12 08:45:00 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 8:45:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112074500.5B02410D5FD0@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 08:45:00 Modified files: cm3/m3-libs/sysutils/src/POSIX/: m3makefile Added files: cm3/m3-libs/sysutils/src/POSIX/: Sysutils_DoesWaitPidYield.i3 Sysutils_Uwaitpid.c Sysutils_Uwaitpid.i3 Log message: checkin the generated/duplicated code, at least temporarily From jkrell at elego.de Mon Jan 12 08:55:09 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 8:55:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112075509.793CF10D5FD0@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 08:55:09 Modified files: cm3/m3-libs/m3core/src/: thread.quake cm3/m3-libs/m3core/src/unix/Common/: m3makefile Added files: cm3/m3-libs/m3core/src/unix/Common/: Uwaitpid.c Uwaitpid.i3 Removed files: cm3/m3-libs/m3core/src/: Uwaitpid.quake Log message: checkin generated code From hosking at cs.purdue.edu Mon Jan 12 09:13:38 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 19:13:38 +1100 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: <66E87543-8486-4377-9405-2912E14CD96E@cs.purdue.edu> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <66E87543-8486-4377-9405-2912E14CD96E@cs.purdue.edu> Message-ID: <4FC3FD8A-6992-4B4B-97AB-E68F8CA26B4C@cs.purdue.edu> What clients of waitpid actually care about the status bits? On 12 Jan 2009, at 18:07, Tony Hosking wrote: > PS What is the name ThreadPScheduler supposed to connote? > > On 12 Jan 2009, at 17:44, Jay wrote: > >> I basically agree here. >> I view thread.quake as temporary. >> Once m3core (that you bootstrap from) has >> SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. >> Or some other fix involving sysutils not knowing this (it sounds >> like you an easy one that I missed). >> >> And then the code that is generated when building m3core can be the >> exact checked in code, was my intention. >> >> I guess what I could/should have done is just put in >> SchedulerPosix.DoesWaitYield, wait some amount of time, and then >> move sysutils over it, not fix sysutils asap. >> >> I can go ahead and do that now -- "fix" m3core, re-"break" (slow >> down) sysutils, and then at whatever time, have sysutils use the >> new function. >> >> I had noticed cygwin builds seeming to take way way longer than I >> remember, like >12 hours instead of <1hour. I didn't track down if >> this is the cause. >> >> - Jay >> >> > From: hosking at cs.purdue.edu >> > To: jkrell at elego.de >> > Date: Mon, 12 Jan 2009 11:18:29 +1100 >> > CC: m3devel at elegosoft.com; m3commit at elegosoft.com >> > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 >> > >> > I really hate the idea that thread.quake exists. >> > >> > Screw sysutils working against old m3core versions. sysutils doing >> > thread-related scheduling is a big hack, and should be killed now >> > before it infects others. I don't want to see thread-dependent code >> > outside of m3core. We really need to come to consensus on this >> before >> > you do more damage to the core thread libraries. >> > >> > I feel strongly about this! >> > >> > -- Tony >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 09:30:58 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 08:30:58 +0000 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: <4FC3FD8A-6992-4B4B-97AB-E68F8CA26B4C@cs.purdue.edu> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <66E87543-8486-4377-9405-2912E14CD96E@cs.purdue.edu> <4FC3FD8A-6992-4B4B-97AB-E68F8CA26B4C@cs.purdue.edu> Message-ID: Asking me? I don't know. What sysutils does, sort of does. Right? You know -- there is the exit code or the exit signal. It seems to be using roughly (exit signal << 8) | exit code. I tried to "just" read the code (~ two weeks) but I might have read it wrong and I don't remember what I found, only that I meant to retain semantics, except for the efficiency of the wait. I don't think that explains the repacking though. I have to read it again (again, again). That's what m3core was hiding, the exit signal? I'll check. - Jay From: hosking at cs.purdue.eduTo: hosking at cs.purdue.eduDate: Mon, 12 Jan 2009 19:13:38 +1100CC: m3devel at elegosoft.com; m3commit at elegosoft.com; jay.krell at cornell.eduSubject: Re: [M3commit] [M3devel] CVS Update: cm3What clients of waitpid actually care about the status bits? On 12 Jan 2009, at 18:07, Tony Hosking wrote: PS What is the name ThreadPScheduler supposed to connote? On 12 Jan 2009, at 17:44, Jay wrote: I basically agree here.I view thread.quake as temporary.Once m3core (that you bootstrap from) has SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. Or some other fix involving sysutils not knowing this (it sounds like you an easy one that I missed). And then the code that is generated when building m3core can be the exact checked in code, was my intention. I guess what I could/should have done is just put in SchedulerPosix.DoesWaitYield, wait some amount of time, and then move sysutils over it, not fix sysutils asap. I can go ahead and do that now -- "fix" m3core, re-"break" (slow down) sysutils, and then at whatever time, have sysutils use the new function. I had noticed cygwin builds seeming to take way way longer than I remember, like >12 hours instead of <1hour. I didn't track down if this is the cause. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:18:29 +1100> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > I really hate the idea that thread.quake exists.> > Screw sysutils working against old m3core versions. sysutils doing > thread-related scheduling is a big hack, and should be killed now > before it infects others. I don't want to see thread-dependent code > outside of m3core. We really need to come to consensus on this before > you do more damage to the core thread libraries.> > I feel strongly about this!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 09:51:55 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 19:51:55 +1100 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <66E87543-8486-4377-9405-2912E14CD96E@cs.purdue.edu> <4FC3FD8A-6992-4B4B-97AB-E68F8CA26B4C@cs.purdue.edu> Message-ID: Well, I find the repacking somewhat dubious, but without knowing what the clients of Process.Wait and System.Wait expect, perhaps we should leave it that way for now. Certainly, client code that has endian- ness assumptions built in regarding the status value is clearly broken and should be fixed at source, rather than relying on some weird underlying repacking hack. I will retain the current packings. As I understand it, the current contortions are to provide an implementation of SchedulerPosix for Win32 threads platforms like Cygwin that are otherwise POSIX. Correct? On 12 Jan 2009, at 19:30, Jay wrote: > Asking me? I don't know. > What sysutils does, sort of does. Right? > You know -- there is the exit code or the exit signal. > It seems to be using roughly (exit signal << 8) | exit code. > > I tried to "just" read the code (~ two weeks) but I might have read > it wrong and I don't remember what I found, only that I meant to > retain semantics, except for the efficiency of the wait. > > I don't think that explains the repacking though. > I have to read it again (again, again). > > That's what m3core was hiding, the exit signal? > I'll check. > > - Jay > > > From: hosking at cs.purdue.edu > To: hosking at cs.purdue.edu > Date: Mon, 12 Jan 2009 19:13:38 +1100 > CC: m3devel at elegosoft.com; m3commit at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3commit] [M3devel] CVS Update: cm3 > > What clients of waitpid actually care about the status bits? > > > On 12 Jan 2009, at 18:07, Tony Hosking wrote: > > PS What is the name ThreadPScheduler supposed to connote? > > On 12 Jan 2009, at 17:44, Jay wrote: > > I basically agree here. > I view thread.quake as temporary. > Once m3core (that you bootstrap from) has > SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. > Or some other fix involving sysutils not knowing this (it sounds > like you an easy one that I missed). > > And then the code that is generated when building m3core can be the > exact checked in code, was my intention. > > I guess what I could/should have done is just put in > SchedulerPosix.DoesWaitYield, wait some amount of time, and then > move sysutils over it, not fix sysutils asap. > > I can go ahead and do that now -- "fix" m3core, re-"break" (slow > down) sysutils, and then at whatever time, have sysutils use the new > function. > > I had noticed cygwin builds seeming to take way way longer than I > remember, like >12 hours instead of <1hour. I didn't track down if > this is the cause. > > - Jay > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:18:29 +1100 > > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > I really hate the idea that thread.quake exists. > > > > Screw sysutils working against old m3core versions. sysutils doing > > thread-related scheduling is a big hack, and should be killed now > > before it infects others. I don't want to see thread-dependent code > > outside of m3core. We really need to come to consensus on this > before > > you do more damage to the core thread libraries. > > > > I feel strongly about this! > > > > -- Tony > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 10:06:12 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 09:06:12 +0000 Subject: [M3commit] [M3devel] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <66E87543-8486-4377-9405-2912E14CD96E@cs.purdue.edu> <4FC3FD8A-6992-4B4B-97AB-E68F8CA26B4C@cs.purdue.edu> Message-ID: Right, the point was to provide a correct seeming SchedulerPosix.i3 on Cygwin, using Win32 threads. It, and NT386 (same code -- ThreadWin32.m3), had a dummy one before. I probably put that dummy in myself without thinking about it. I can't say that I really tested the implementation or measure anything before/after. (in fact, I can say I did not). But it definitely looks better (functionality, not structure). Maybe time to test Cygwin pthreads again? - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 19:51:55 +1100CC: m3devel at elegosoft.com; m3commit at elegosoft.comSubject: Re: [M3commit] [M3devel] CVS Update: cm3 Well, I find the repacking somewhat dubious, but without knowing what the clients of Process.Wait and System.Wait expect, perhaps we should leave it that way for now. Certainly, client code that has endian-ness assumptions built in regarding the status value is clearly broken and should be fixed at source, rather than relying on some weird underlying repacking hack. I will retain the current packings. As I understand it, the current contortions are to provide an implementation of SchedulerPosix for Win32 threads platforms like Cygwin that are otherwise POSIX. Correct? On 12 Jan 2009, at 19:30, Jay wrote: Asking me? I don't know.What sysutils does, sort of does. Right?You know -- there is the exit code or the exit signal.It seems to be using roughly (exit signal << 8) | exit code. I tried to "just" read the code (~ two weeks) but I might have read it wrong and I don't remember what I found, only that I meant to retain semantics, except for the efficiency of the wait. I don't think that explains the repacking though.I have to read it again (again, again). That's what m3core was hiding, the exit signal?I'll check. - Jay From: hosking at cs.purdue.eduTo: hosking at cs.purdue.eduDate: Mon, 12 Jan 2009 19:13:38 +1100CC: m3devel at elegosoft.com; m3commit at elegosoft.com; jay.krell at cornell.eduSubject: Re: [M3commit] [M3devel] CVS Update: cm3What clients of waitpid actually care about the status bits? On 12 Jan 2009, at 18:07, Tony Hosking wrote: PS What is the name ThreadPScheduler supposed to connote? On 12 Jan 2009, at 17:44, Jay wrote: I basically agree here.I view thread.quake as temporary.Once m3core (that you bootstrap from) has SchedulerPosix.DoesWaitPidYield, sysutils can use it itself. Or some other fix involving sysutils not knowing this (it sounds like you an easy one that I missed). And then the code that is generated when building m3core can be the exact checked in code, was my intention. I guess what I could/should have done is just put in SchedulerPosix.DoesWaitYield, wait some amount of time, and then move sysutils over it, not fix sysutils asap. I can go ahead and do that now -- "fix" m3core, re-"break" (slow down) sysutils, and then at whatever time, have sysutils use the new function. I had noticed cygwin builds seeming to take way way longer than I remember, like >12 hours instead of <1hour. I didn't track down if this is the cause. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:18:29 +1100> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > I really hate the idea that thread.quake exists.> > Screw sysutils working against old m3core versions. sysutils doing > thread-related scheduling is a big hack, and should be killed now > before it infects others. I don't want to see thread-dependent code > outside of m3core. We really need to come to consensus on this before > you do more damage to the core thread libraries.> > I feel strongly about this!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at elego.de Mon Jan 12 10:20:33 2009 From: hosking at elego.de (Antony Hosking) Date: Mon, 12 Jan 2009 10:20:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112092033.2748010D5FD1@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 09/01/12 10:20:33 Modified files: cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 ThreadPWait.m3 cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 m3makefile cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile Log message: Try to clean up mess with Process.Wait and System.Wait based on waitpid. Packing is now returned to Process.Wait and System.Wait where it used to be. Not sure if this re-packing is needed by clients, but should verify. From jay.krell at cornell.edu Mon Jan 12 11:11:17 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 10:11:17 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20090112092033.2748010D5FD1@birch.elegosoft.com> References: <20090112092033.2748010D5FD1@birch.elegosoft.com> Message-ID: > relies on particular endian-ness of the status > word they return. Really, those clients should > be using proper bit-shifts and bit-masks to extract > the right values rather than some endian- dependent RECORD layout defined in Uexec Wasn't Uwaitpid.c a good portable way to do exactly that? I guess it can be written in Modula-3 though, if the headers are cloned as they are. Aren't {I386,AMD64}_DARWIN broken here? Besides all "my" ports, which don't define those types. Yeah yeah, all I have to do is switch on endian and I can introduce them.. I'll see about Cygwin pthreads. - Jay> Date: Mon, 12 Jan 2009 10:20:33 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 09/01/12 10:20:33> > Modified files:> cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > ThreadPWait.m3 > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > m3makefile > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > Log message:> Try to clean up mess with Process.Wait and System.Wait based on waitpid.> > Packing is now returned to Process.Wait and System.Wait where it used to be.> > Not sure if this re-packing is needed by clients, but should verify.> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 11:28:10 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 10:28:10 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20090112092033.2748010D5FD1@birch.elegosoft.com> References: <20090112092033.2748010D5FD1@birch.elegosoft.com> Message-ID: Eek, was this really the way to go? It really seemed better before to me. Before it was automatically portable without declaring the packed return type or NOHANG. - Jay From: jay.krell at cornell.eduTo: hosking at elego.de; m3commit at elegosoft.comSubject: RE: [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 10:11:17 +0000 > relies on particular endian-ness of the status > word they return. Really, those clients should > be using proper bit-shifts and bit-masks to extract > the right values rather than some endian- dependent RECORD layout defined in Uexec Wasn't Uwaitpid.c a good portable way to do exactly that? I guess it can be written in Modula-3 though, if the headers are cloned as they are. Aren't {I386,AMD64}_DARWIN broken here? Besides all "my" ports, which don't define those types. Yeah yeah, all I have to do is switch on endian and I can introduce them.. I'll see about Cygwin pthreads. - Jay> Date: Mon, 12 Jan 2009 10:20:33 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 09/01/12 10:20:33> > Modified files:> cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > ThreadPWait.m3 > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > m3makefile > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > Log message:> Try to clean up mess with Process.Wait and System.Wait based on waitpid.> > Packing is now returned to Process.Wait and System.Wait where it used to be.> > Not sure if this re-packing is needed by clients, but should verify.> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Mon Jan 12 11:41:36 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 11:41:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112104136.707C210D5FCF@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 11:41:36 Modified files: cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 Log message: remove unused type to fix warning From hosking at cs.purdue.edu Mon Jan 12 12:25:25 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 22:25:25 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20090112092033.2748010D5FD1@birch.elegosoft.com> Message-ID: <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> On 12 Jan 2009, at 21:11, Jay wrote: > > relies on particular endian-ness of the status > > word they return. Really, those clients should > > be using proper bit-shifts and bit-masks to extract > > the right values rather than some endian- dependent RECORD layout > defined in Uexec > > Wasn't Uwaitpid.c a good portable way to do exactly that? I didn't look too closely at that. I wanted something that retained the simplicity of calling waitpid as: PROCEDURE waitpid(pid: int; VAR status: int; options: int): int; > I guess it can be written in Modula-3 though, if the headers are > cloned as they are. > Aren't {I386,AMD64}_DARWIN broken here? I don't think so -- Uexec is still there. > Besides all "my" ports, which don't define those types. > Yeah yeah, all I have to do is switch on endian and I can introduce > them.. But really, clients of waitpid/SchedulerPosix.WaitProcess should be prepared to shift the status return value correctly! After all, the interface doc for Process.Wait indicates that the return value is the status word. > I'll see about Cygwin pthreads. Yes, it would be a more coherent solution. > > > - Jay > > > Date: Mon, 12 Jan 2009 10:20:33 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 09/01/12 10:20:33 > > > > Modified files: > > cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > > ThreadPWait.m3 > > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > > m3makefile > > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > > > Log message: > > Try to clean up mess with Process.Wait and System.Wait based on > waitpid. > > > > Packing is now returned to Process.Wait and System.Wait where it > used to be. > > > > Not sure if this re-packing is needed by clients, but should verify. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 12:26:01 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 22:26:01 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20090112092033.2748010D5FD1@birch.elegosoft.com> Message-ID: <3F2E7A20-E9AE-4D3D-8262-032F356E0253@cs.purdue.edu> Eek, what? On 12 Jan 2009, at 21:28, Jay wrote: > Eek, was this really the way to go? > It really seemed better before to me. > Before it was automatically portable without declaring the packed > return type or NOHANG. > > - Jay > > > > From: jay.krell at cornell.edu > To: hosking at elego.de; m3commit at elegosoft.com > Subject: RE: [M3commit] CVS Update: cm3 > Date: Mon, 12 Jan 2009 10:11:17 +0000 > > > relies on particular endian-ness of the status > > word they return. Really, those clients should > > be using proper bit-shifts and bit-masks to extract > > the right values rather than some endian- dependent RECORD layout > defined in Uexec > > Wasn't Uwaitpid.c a good portable way to do exactly that? > I guess it can be written in Modula-3 though, if the headers are > cloned as they are. > Aren't {I386,AMD64}_DARWIN broken here? > Besides all "my" ports, which don't define those types. > Yeah yeah, all I have to do is switch on endian and I can introduce > them.. > > I'll see about Cygwin pthreads. > > - Jay > > > Date: Mon, 12 Jan 2009 10:20:33 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 09/01/12 10:20:33 > > > > Modified files: > > cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > > ThreadPWait.m3 > > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > > m3makefile > > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > > > Log message: > > Try to clean up mess with Process.Wait and System.Wait based on > waitpid. > > > > Packing is now returned to Process.Wait and System.Wait where it > used to be. > > > > Not sure if this re-packing is needed by clients, but should verify. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Mon Jan 12 12:28:31 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 12:28:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112112831.5F3C810D5E8B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 12:28:31 Modified files: cm3/m3-libs/m3core/src/unix/big-endian/: m3makefile cm3/m3-libs/m3core/src/unix/little-endian/: m3makefile cm3/m3-libs/m3core/src/unix/Common/: m3makefile Added files: cm3/m3-libs/m3core/src/unix/big-endian/: Uexec.i3 cm3/m3-libs/m3core/src/unix/little-endian/: Uexec.i3 Log message: clone more headers to account for non portable waitpid reintroduction; what was wrong with what was here? Aren't several ports wrong e.g. {I386,AMD64}_DARWIN, PPC_LINUX? I guess the point is to stop anyone from using this data at all, so as to not need to return it one way or the other? From hosking at cs.purdue.edu Mon Jan 12 12:38:46 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 22:38:46 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20090112112831.5F3C810D5E8B@birch.elegosoft.com> References: <20090112112831.5F3C810D5E8B@birch.elegosoft.com> Message-ID: <64BB1AFE-D740-44B8-A576-DDE0125EAB24@cs.purdue.edu> I'm not sure what you mean by the ports being wrong. Can you explain more? On 12 Jan 2009, at 12:28, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/01/12 12:28:31 > > Modified files: > cm3/m3-libs/m3core/src/unix/big-endian/: m3makefile > cm3/m3-libs/m3core/src/unix/little-endian/: m3makefile > cm3/m3-libs/m3core/src/unix/Common/: m3makefile > Added files: > cm3/m3-libs/m3core/src/unix/big-endian/: Uexec.i3 > cm3/m3-libs/m3core/src/unix/little-endian/: Uexec.i3 > > Log message: > clone more headers to account for non portable waitpid > reintroduction; what was wrong with what was here? Aren't several > ports wrong e.g. {I386,AMD64}_DARWIN, PPC_LINUX? I guess the point > is to stop anyone from using this data at all, so as to not need to > return it one way or the other? From hosking at cs.purdue.edu Mon Jan 12 12:41:56 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 22:41:56 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20090112112831.5F3C810D5E8B@birch.elegosoft.com> References: <20090112112831.5F3C810D5E8B@birch.elegosoft.com> Message-ID: <9ADACB4E-1D6A-4FDB-9A63-90BFEBAAB169@cs.purdue.edu> PS I would love to avoid cloning the headers. waitpid would be invocable without any wrapper -- it's up to the client code to interpret the status word properly as needs. On 12 Jan 2009, at 12:28, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/01/12 12:28:31 > > Modified files: > cm3/m3-libs/m3core/src/unix/big-endian/: m3makefile > cm3/m3-libs/m3core/src/unix/little-endian/: m3makefile > cm3/m3-libs/m3core/src/unix/Common/: m3makefile > Added files: > cm3/m3-libs/m3core/src/unix/big-endian/: Uexec.i3 > cm3/m3-libs/m3core/src/unix/little-endian/: Uexec.i3 > > Log message: > clone more headers to account for non portable waitpid > reintroduction; what was wrong with what was here? Aren't several > ports wrong e.g. {I386,AMD64}_DARWIN, PPC_LINUX? I guess the point > is to stop anyone from using this data at all, so as to not need to > return it one way or the other? From hosking at cs.purdue.edu Mon Jan 12 12:42:06 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 22:42:06 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20090112112831.5F3C810D5E8B@birch.elegosoft.com> References: <20090112112831.5F3C810D5E8B@birch.elegosoft.com> Message-ID: PS I would love to avoid cloning the headers. waitpid would be invocable without any wrapper -- it's up to the client code to interpret the status word properly as needs. On 12 Jan 2009, at 12:28, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/01/12 12:28:31 > > Modified files: > cm3/m3-libs/m3core/src/unix/big-endian/: m3makefile > cm3/m3-libs/m3core/src/unix/little-endian/: m3makefile > cm3/m3-libs/m3core/src/unix/Common/: m3makefile > Added files: > cm3/m3-libs/m3core/src/unix/big-endian/: Uexec.i3 > cm3/m3-libs/m3core/src/unix/little-endian/: Uexec.i3 > > Log message: > clone more headers to account for non portable waitpid > reintroduction; what was wrong with what was here? Aren't several > ports wrong e.g. {I386,AMD64}_DARWIN, PPC_LINUX? I guess the point > is to stop anyone from using this data at all, so as to not need to > return it one way or the other? From jay.krell at cornell.edu Mon Jan 12 12:49:32 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 11:49:32 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20090112112831.5F3C810D5E8B@birch.elegosoft.com> Message-ID: [all tangent] This indirectly answers one of my questions perhaps, as to the level of avoiding cloning headers. You have no problem with this level of header cloning: Uexec.i3 <*external*> PROCEDURE waitpid(pid:Utypes.pid_t, status:UNTRACED REF int, int options):int; You know -- 1) the need to define pid_t correctly. 2) The assumption that it is trafficing in int, and not e.g. short or long? "portable enough"? I think maybe so. And even this can be "checked" on native builds, but always used "directly". There is an argument that even something "like this" would benefit from being wrapped in C where we have very tight control over the Modula-3<->C transition. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 22:42:06 +1100> CC: m3commit at elegosoft.com> Subject: Re: [M3commit] CVS Update: cm3> > PS I would love to avoid cloning the headers. waitpid would be > invocable without any wrapper -- it's up to the client code to > interpret the status word properly as needs.> > > On 12 Jan 2009, at 12:28, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 09/01/12 12:28:31> >> > Modified files:> > cm3/m3-libs/m3core/src/unix/big-endian/: m3makefile> > cm3/m3-libs/m3core/src/unix/little-endian/: m3makefile> > cm3/m3-libs/m3core/src/unix/Common/: m3makefile> > Added files:> > cm3/m3-libs/m3core/src/unix/big-endian/: Uexec.i3> > cm3/m3-libs/m3core/src/unix/little-endian/: Uexec.i3> >> > Log message:> > clone more headers to account for non portable waitpid > > reintroduction; what was wrong with what was here? Aren't several > > ports wrong e.g. {I386,AMD64}_DARWIN, PPC_LINUX? I guess the point > > is to stop anyone from using this data at all, so as to not need to > > return it one way or the other?> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 12:53:50 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 11:53:50 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <9ADACB4E-1D6A-4FDB-9A63-90BFEBAAB169@cs.purdue.edu> References: <20090112112831.5F3C810D5E8B@birch.elegosoft.com> <9ADACB4E-1D6A-4FDB-9A63-90BFEBAAB169@cs.purdue.edu> Message-ID: uh oh.I sense a possible big vocabulary difference. There are, indeed, two ways of cloning headers. One way is with super tight fidelity.Declaring the types in Modula-3 to match exactly what it is in the .h files..h files that you don't write yourself, that vary from system to system,and may be full of #ifdefs and hard to read (but sure, preprocess them).This is what I don't like.It is tedious, error prone, dangerous.This is historically what was done. The alternative is, well, also cloning headers.You write your own.But you don't put any #ifdefs in them.You make them easy to read.They are the same for Solaris, Linux, little endian, big endian (no bit fields), etc. The ones you write yourself, you write in both Modula-3 and C.You have your Modula-3 code call your C code, and then your C calls "the OS", viaits headers, that you no longer have to read and clone. This is what I have been doing. In fact, maybe the ones you write yourself you write in xml or some otherconstrained language/schema, and write a tool to spit out Modula .i3 and C .h files. We are on the same page, right? Bad to clone /usr/include. Ok to clone stuff you write yourself. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 22:41:56 +1100> CC: m3commit at elegosoft.com> Subject: Re: [M3commit] CVS Update: cm3> > PS I would love to avoid cloning the headers. waitpid would be > invocable without any wrapper -- it's up to the client code to > interpret the status word properly as needs.> > > On 12 Jan 2009, at 12:28, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 09/01/12 12:28:31> >> > Modified files:> > cm3/m3-libs/m3core/src/unix/big-endian/: m3makefile> > cm3/m3-libs/m3core/src/unix/little-endian/: m3makefile> > cm3/m3-libs/m3core/src/unix/Common/: m3makefile> > Added files:> > cm3/m3-libs/m3core/src/unix/big-endian/: Uexec.i3> > cm3/m3-libs/m3core/src/unix/little-endian/: Uexec.i3> >> > Log message:> > clone more headers to account for non portable waitpid > > reintroduction; what was wrong with what was here? Aren't several > > ports wrong e.g. {I386,AMD64}_DARWIN, PPC_LINUX? I guess the point > > is to stop anyone from using this data at all, so as to not need to > > return it one way or the other?> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 12:55:39 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 11:55:39 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <64BB1AFE-D740-44B8-A576-DDE0125EAB24@cs.purdue.edu> References: <20090112112831.5F3C810D5E8B@birch.elegosoft.com> <64BB1AFE-D740-44B8-A576-DDE0125EAB24@cs.purdue.edu> Message-ID: I believe: linux-libc6 defines the little endian types. PPC_LINUX is wrong. darwin-generic defines the big endian types. I386_DARWIN and AMD64_DARWIN are wrong. All the platforms I have been hammering on don't define any of the types. My Uwaitpid.c was "automatically" correct for any platform. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 22:38:46 +1100> CC: m3commit at elegosoft.com> Subject: Re: [M3commit] CVS Update: cm3> > I'm not sure what you mean by the ports being wrong. Can you explain > more?> > On 12 Jan 2009, at 12:28, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 09/01/12 12:28:31> >> > Modified files:> > cm3/m3-libs/m3core/src/unix/big-endian/: m3makefile> > cm3/m3-libs/m3core/src/unix/little-endian/: m3makefile> > cm3/m3-libs/m3core/src/unix/Common/: m3makefile> > Added files:> > cm3/m3-libs/m3core/src/unix/big-endian/: Uexec.i3> > cm3/m3-libs/m3core/src/unix/little-endian/: Uexec.i3> >> > Log message:> > clone more headers to account for non portable waitpid > > reintroduction; what was wrong with what was here? Aren't several > > ports wrong e.g. {I386,AMD64}_DARWIN, PPC_LINUX? I guess the point > > is to stop anyone from using this data at all, so as to not need to > > return it one way or the other?> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 12:58:34 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 11:58:34 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <3F2E7A20-E9AE-4D3D-8262-032F356E0253@cs.purdue.edu> References: <20090112092033.2748010D5FD1@birch.elegosoft.com> <3F2E7A20-E9AE-4D3D-8262-032F356E0253@cs.purdue.edu> Message-ID: Eek using the packed types in Uexec.i3 instead of my portable Uwaitpid.i3, Uwaitpid.c that unpacked everything into a whole number of bytes (no bit fields or shifting for the caller to wory about), and formed the value that I believe the loopholes were historically getting. A big part of the change. - Jay CC: hosking at elego.de; m3commit at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 22:26:01 +1100 Eek, what? On 12 Jan 2009, at 21:28, Jay wrote: Eek, was this really the way to go?It really seemed better before to me.Before it was automatically portable without declaring the packed return type or NOHANG. - Jay From: jay.krell at cornell.eduTo: hosking at elego.de; m3commit at elegosoft.comSubject: RE: [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 10:11:17 +0000 > relies on particular endian-ness of the status > word they return. Really, those clients should > be using proper bit-shifts and bit-masks to extract > the right values rather than some endian- dependent RECORD layout defined in Uexec Wasn't Uwaitpid.c a good portable way to do exactly that? I guess it can be written in Modula-3 though, if the headers are cloned as they are. Aren't {I386,AMD64}_DARWIN broken here? Besides all "my" ports, which don't define those types. Yeah yeah, all I have to do is switch on endian and I can introduce them.. I'll see about Cygwin pthreads. - Jay> Date: Mon, 12 Jan 2009 10:20:33 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 09/01/12 10:20:33> > Modified files:> cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > ThreadPWait.m3 > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > m3makefile > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > Log message:> Try to clean up mess with Process.Wait and System.Wait based on waitpid.> > Packing is now returned to Process.Wait and System.Wait where it used to be.> > Not sure if this re-packing is needed by clients, but should verify.> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 13:08:29 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 12:08:29 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> References: <20090112092033.2748010D5FD1@birch.elegosoft.com> <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> Message-ID: Hm. So I guess the point then is to return one "reasonable" integer, and "reasonable" is actually defined as (coredump << 15) | (termsig << 8) | exitcode That's the point of the repacking? and coredump and termsig are usually 0. Anyway, I don't think even this 7/1/8/16 split is specified by Posix. Right? Uwaitpid.c was a good portable method I think. It was based on the example code in online Posix docs (which you originally pointed me to). - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 22:25:25 +1100CC: m3commit at elegosoft.comSubject: Re: [M3commit] CVS Update: cm3 On 12 Jan 2009, at 21:11, Jay wrote: > relies on particular endian-ness of the status > word they return. Really, those clients should > be using proper bit-shifts and bit-masks to extract > the right values rather than some endian- dependent RECORD layout defined in Uexec Wasn't Uwaitpid.c a good portable way to do exactly that? I didn't look too closely at that. I wanted something that retained the simplicity of calling waitpid as: PROCEDURE waitpid(pid: int; VAR status: int; options: int): int; I guess it can be written in Modula-3 though, if the headers are cloned as they are. Aren't {I386,AMD64}_DARWIN broken here? I don't think so -- Uexec is still there. Besides all "my" ports, which don't define those types. Yeah yeah, all I have to do is switch on endian and I can introduce them.. But really, clients of waitpid/SchedulerPosix.WaitProcess should be prepared to shift the status return value correctly! After all, the interface doc for Process.Wait indicates that the return value is the status word. I'll see about Cygwin pthreads. Yes, it would be a more coherent solution. - Jay> Date: Mon, 12 Jan 2009 10:20:33 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 09/01/12 10:20:33> > Modified files:> cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > ThreadPWait.m3 > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > m3makefile > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > Log message:> Try to clean up mess with Process.Wait and System.Wait based on waitpid.> > Packing is now returned to Process.Wait and System.Wait where it used to be.> > Not sure if this re-packing is needed by clients, but should verify.> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Mon Jan 12 13:26:56 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 13:26:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112122656.AE89510D5FD1@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 13:26:56 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Log message: fix cygwin From jkrell at elego.de Mon Jan 12 14:25:27 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 14:25:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112132528.0CA6310D4E24@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 14:25:27 Modified files: cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 Log message: Convert errno case to 'if ladder' so we can use auto-ported C variables instead of port-requiring constants From jkrell at elego.de Mon Jan 12 14:44:25 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 14:44:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112134425.CEA0C10D5F24@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 14:44:25 Modified files: cm3/m3-libs/m3core/src/unix/Common/: m3makefile cm3/m3-libs/m3core/src/unix/linux-common/: m3makefile cm3/m3-libs/m3core/src/unix/linux-sparc/: m3makefile cm3/m3-libs/m3core/src/unix/openbsd-common/: m3makefile Added files: cm3/m3-libs/m3core/src/unix/Common/: Uerror.c Uerror.i3 UerrorX.h Removed files: cm3/m3-libs/m3core/src/unix/linux-common/: Uerror.i3 cm3/m3-libs/m3core/src/unix/linux-sparc/: Uerror.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Uerror.i3 Log message: move to portable rendition of Uerror for now exclude Cygwin From jkrell at elego.de Mon Jan 12 14:46:18 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 14:46:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112134618.2D79510D5F24@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 14:46:18 Modified files: cm3/m3-libs/m3core/src/unix/freebsd-common/: m3makefile Removed files: cm3/m3-libs/m3core/src/unix/freebsd-common/: Uerror.i3 Log message: this one too From jkrell at elego.de Mon Jan 12 15:09:08 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 15:09:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112140908.77D4E10D5F28@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 15:09:08 Modified files: cm3/m3-libs/m3core/src/C/PPC_LINUX/: Csetjmp.i3 Log message: remove unused import From hosking at cs.purdue.edu Mon Jan 12 01:18:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 11:18:29 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> Message-ID: I really hate the idea that thread.quake exists. Screw sysutils working against old m3core versions. sysutils doing thread-related scheduling is a big hack, and should be killed now before it infects others. I don't want to see thread-dependent code outside of m3core. We really need to come to consensus on this before you do more damage to the core thread libraries. I feel strongly about this! -- Tony From jkrell at elego.de Mon Jan 12 15:49:07 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 15:49:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112144907.B25CC10D5F28@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 15:49:07 Modified files: cm3/m3-comm/tcp/src/POSIX/: TCP.m3 Log message: convert another case on errno to an 'if ladder' so that CONST can be VAR for auto-porting From hosking at cs.purdue.edu Mon Jan 12 21:23:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 13 Jan 2009 07:23:29 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20090112092033.2748010D5FD1@birch.elegosoft.com> <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> Message-ID: I guess I'd like to get rid of the re-packing and fix the clients instead. On 12 Jan 2009, at 23:08, Jay wrote: > Hm. So I guess the point then is to return one "reasonable" integer, > and > "reasonable" is actually defined as > > (coredump << 15) | (termsig << 8) | exitcode > > That's the point of the repacking? > and coredump and termsig are usually 0. > > Anyway, I don't think even this 7/1/8/16 split is specified by > Posix. Right? > Uwaitpid.c was a good portable method I think. > It was based on the example code in online Posix docs (which you > originally pointed me to). > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 22:25:25 +1100 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > On 12 Jan 2009, at 21:11, Jay wrote: > > > relies on particular endian-ness of the status > > word they return. Really, those clients should > > be using proper bit-shifts and bit-masks to extract > > the right values rather than some endian- dependent RECORD layout > defined in Uexec > > Wasn't Uwaitpid.c a good portable way to do exactly that? > > I didn't look too closely at that. I wanted something that retained > the simplicity of calling waitpid as: > > PROCEDURE waitpid(pid: int; VAR status: int; options: int): int; > > I guess it can be written in Modula-3 though, if the headers are > cloned as they are. > Aren't {I386,AMD64}_DARWIN broken here? > > I don't think so -- Uexec is still there. > > Besides all "my" ports, which don't define those types. > Yeah yeah, all I have to do is switch on endian and I can introduce > them.. > > But really, clients of waitpid/SchedulerPosix.WaitProcess should be > prepared to shift the status return value correctly! After all, the > interface doc for Process.Wait indicates that the return value is > the status word. > > I'll see about Cygwin pthreads. > > Yes, it would be a more coherent solution. > > > > - Jay > > > Date: Mon, 12 Jan 2009 10:20:33 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 09/01/12 10:20:33 > > > > Modified files: > > cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > > ThreadPWait.m3 > > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > > m3makefile > > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > > > Log message: > > Try to clean up mess with Process.Wait and System.Wait based on > waitpid. > > > > Packing is now returned to Process.Wait and System.Wait where it > used to be. > > > > Not sure if this re-packing is needed by clients, but should verify. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 21:34:38 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 13 Jan 2009 07:34:38 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20090112092033.2748010D5FD1@birch.elegosoft.com> <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> Message-ID: <54C1E71A-CCCD-4E09-9426-A0F300402858@cs.purdue.edu> I guess I'd like to get rid of the re-packing and fix the clients instead. On 12 Jan 2009, at 23:08, Jay wrote: > Hm. So I guess the point then is to return one "reasonable" integer, > and > "reasonable" is actually defined as > > (coredump << 15) | (termsig << 8) | exitcode > > That's the point of the repacking? > and coredump and termsig are usually 0. > > Anyway, I don't think even this 7/1/8/16 split is specified by > Posix. Right? > Uwaitpid.c was a good portable method I think. > It was based on the example code in online Posix docs (which you > originally pointed me to). > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 22:25:25 +1100 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > On 12 Jan 2009, at 21:11, Jay wrote: > > > relies on particular endian-ness of the status > > word they return. Really, those clients should > > be using proper bit-shifts and bit-masks to extract > > the right values rather than some endian- dependent RECORD layout > defined in Uexec > > Wasn't Uwaitpid.c a good portable way to do exactly that? > > I didn't look too closely at that. I wanted something that retained > the simplicity of calling waitpid as: > > PROCEDURE waitpid(pid: int; VAR status: int; options: int): int; > > I guess it can be written in Modula-3 though, if the headers are > cloned as they are. > Aren't {I386,AMD64}_DARWIN broken here? > > I don't think so -- Uexec is still there. > > Besides all "my" ports, which don't define those types. > Yeah yeah, all I have to do is switch on endian and I can introduce > them.. > > But really, clients of waitpid/SchedulerPosix.WaitProcess should be > prepared to shift the status return value correctly! After all, the > interface doc for Process.Wait indicates that the return value is > the status word. > > I'll see about Cygwin pthreads. > > Yes, it would be a more coherent solution. > > > > - Jay > > > Date: Mon, 12 Jan 2009 10:20:33 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 09/01/12 10:20:33 > > > > Modified files: > > cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > > ThreadPWait.m3 > > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > > m3makefile > > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > > > Log message: > > Try to clean up mess with Process.Wait and System.Wait based on > waitpid. > > > > Packing is now returned to Process.Wait and System.Wait where it > used to be. > > > > Not sure if this re-packing is needed by clients, but should verify. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Mon Jan 12 23:42:28 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 12 Jan 2009 23:42:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112224228.13F7110D5EBC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/12 23:42:28 Modified files: cm3/m3-sys/cminstall/src/config/: NT386.common Log message: Ship and statically link to Uerror.obj IF it exists, it will exist after I finish investigating cygwin/pthreads. Data cannot be dynamically linked on Win32 without more work. The really portable solution is to use functions, but that is not source compatible and I'm reluctant, but maybe.. From hosking at elego.de Tue Jan 13 00:46:03 2009 From: hosking at elego.de (Antony Hosking) Date: Tue, 13 Jan 2009 0:46:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090112234604.07A6110D5DAA@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 09/01/13 00:46:03 Modified files: cm3/m3-libs/m3core/src/thread/: m3makefile cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 cm3/m3-libs/m3core/src/thread/WIN32/: m3makefile Added files: cm3/m3-libs/m3core/src/thread/WIN32/: SchedulerPosix.m3 ThreadInternal.i3 Removed files: cm3/m3-libs/m3core/src/thread/: ThreadInternal.i3 ThreadPScheduler.m3 ThreadPWait.m3 Log message: Restore the coherence of the thread packages (keeping code for different thread implementations together, and avoiding smearing across implementations). The only weird hybrid (which should in probably anyway use PTHREAD instead of WIN32) is CygWin. Keep the mess created by this hybrid in the WIN32 implementation where it belongs rather than complicating all the other pure pthread-based implementations. From jay.krell at cornell.edu Tue Jan 13 06:50:43 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 13 Jan 2009 05:50:43 +0000 Subject: [M3commit] waitpit In-Reply-To: <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> References: <20090112092033.2748010D5FD1@birch.elegosoft.com> <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> Message-ID: I think "what I was missing" here is the option of changing the Process.Wait or SchedulerPosix.WaitProcess interface to return the status bits. I don't think this is how it was before, (which I think was implied). Maybe I misread it, between returning the pid/success vs. the status word? I had added the new interface SchedulerPosix.DoesWaitPidYield, but left others asis. Now, true, I'm arguing both sides, since I did make Uerror.i3 incompatible with some clients. Exposing more information like that seems a good solution, leaving the next level down to waitpid(0) or waitpid(nohang). I think user threads are missing some code now, since ThreadPWait (but not ThreadPScheduler) was used by them. But I admit, I didn't build them either, so whether they worked or not, and whether I kept them working or not, don't know. They are never build by default. I think the problem with the encoded exit status it is just a bit "wierd", and hardly anyone would want to use it asis. The repacked value makes more sense? Slightly? Hm..how about this...? interface Uexec; <*external Uexec_WIFEXITED> PROCEDURE WIFEXITED(int status):BOOLEAN; etc. the various other macros/functions in Posix, well, at least two or three of them, the ones that access the relevant fields. Uexec.c typedef size_t BOOLEAN; /* ? safe at least, to return a full word's worth of bits */ #define TRUE 1 #define FALSE 1 BOOLEAN Uexec_WIFEEXITED(int status) { return WIFEEXITED(status) ? TRUE : FALSE; } That fits one of the molds well imho. I like what I had in Uwaitpid, but it is hard to argue for it vs. this. They are very similar. This has the advantage of only returning what is asked for. Uwaitpid had the advantage of probably being faster -- less storage efficient, but fewer function calls / roundtrips and such, since WIFEEXITED is likely a macro and Modula-3 loses the inlining. Surely not a big deal either way. Both options are very portable. Then, the rejiggering/repacking of the bits can be done portably, without regard to endiannness and without regard to the bitfield layout of the int; the bitfields can go away, leaving just the int to be unpacked by these macros-wrapped-in-functions. (I believe it is portable defined as an int but I'll check). Ok? - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3commit at elegosoft.comSubject: RE: [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 12:08:29 +0000 Hm. So I guess the point then is to return one "reasonable" integer, and"reasonable" is actually defined as (coredump << 15) | (termsig << 8) | exitcode That's the point of the repacking?and coredump and termsig are usually 0. Anyway, I don't think even this 7/1/8/16 split is specified by Posix. Right?Uwaitpid.c was a good portable method I think.It was based on the example code in online Posix docs (which you originally pointed me to). - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 22:25:25 +1100CC: m3commit at elegosoft.comSubject: Re: [M3commit] CVS Update: cm3 On 12 Jan 2009, at 21:11, Jay wrote: > relies on particular endian-ness of the status > word they return. Really, those clients should > be using proper bit-shifts and bit-masks to extract > the right values rather than some endian- dependent RECORD layout defined in Uexec Wasn't Uwaitpid.c a good portable way to do exactly that? I didn't look too closely at that. I wanted something that retained the simplicity of calling waitpid as: PROCEDURE waitpid(pid: int; VAR status: int; options: int): int; I guess it can be written in Modula-3 though, if the headers are cloned as they are. Aren't {I386,AMD64}_DARWIN broken here? I don't think so -- Uexec is still there. Besides all "my" ports, which don't define those types. Yeah yeah, all I have to do is switch on endian and I can introduce them.. But really, clients of waitpid/SchedulerPosix.WaitProcess should be prepared to shift the status return value correctly! After all, the interface doc for Process.Wait indicates that the return value is the status word. I'll see about Cygwin pthreads. Yes, it would be a more coherent solution. - Jay> Date: Mon, 12 Jan 2009 10:20:33 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 09/01/12 10:20:33> > Modified files:> cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > ThreadPWait.m3 > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > m3makefile > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > Log message:> Try to clean up mess with Process.Wait and System.Wait based on waitpid.> > Packing is now returned to Process.Wait and System.Wait where it used to be.> > Not sure if this re-packing is needed by clients, but should verify.> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at elego.de Tue Jan 13 08:03:37 2009 From: hosking at elego.de (Antony Hosking) Date: Tue, 13 Jan 2009 8:03:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113070337.ACE1E10D5D11@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 09/01/13 08:03:37 Modified files: cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosix.m3 Log message: Repair ThreadPosix.m3 as well. Forgot to do this earlier. From hosking at elego.de Tue Jan 13 08:07:56 2009 From: hosking at elego.de (Antony Hosking) Date: Tue, 13 Jan 2009 8:07:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113070756.93F3C10D5D11@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 09/01/13 08:07:56 Modified files: cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosix.m3 Log message: Fix syntax error and restore Delay constant. What about just calling Yield instead of Delay to get better performance at the expense of niceness w.r.to other processes? From jkrell at elego.de Tue Jan 13 12:06:25 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 12:06:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113110625.72EB710D5F41@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 12:06:25 Modified files: cm3/m3-libs/m3core/src/unix/ultrix-3-1.SEQUENT/: m3makefile cm3/m3-libs/m3core/src/unix/ultrix-3-1.SUN3/: m3makefile cm3/m3-libs/m3core/src/unix/ultrix-3-1.SUN386/: m3makefile cm3/m3-libs/m3core/src/unix/ultrix-3-1.UMAX/: m3makefile cm3/m3-libs/m3core/src/unix/ultrix-3-1.VAX/: m3makefile cm3/m3-libs/m3core/src/unix/sunos-4-x/: m3makefile cm3/m3-libs/m3core/src/unix/sysv-4.0/: m3makefile cm3/m3-libs/m3core/src/unix/ultrix-3-1.AP3000/: m3makefile cm3/m3-libs/m3core/src/unix/ultrix-3-1.ARM/: m3makefile cm3/m3-libs/m3core/src/unix/ultrix-3-1.DS3100/: m3makefile cm3/m3-libs/m3core/src/unix/ultrix-3-1.NEXT/: m3makefile cm3/m3-libs/m3core/src/unix/linux-libc6/: m3makefile cm3/m3-libs/m3core/src/unix/little-endian/: m3makefile cm3/m3-libs/m3core/src/unix/netbsd2-i386/: m3makefile cm3/m3-libs/m3core/src/unix/os2/: m3makefile cm3/m3-libs/m3core/src/unix/osf-1.generic/: m3makefile cm3/m3-libs/m3core/src/unix/solaris-2-x/: m3makefile cm3/m3-libs/m3core/src/unix/aix-3-2/: m3makefile cm3/m3-libs/m3core/src/unix/aix-ps2-1-2/: m3makefile cm3/m3-libs/m3core/src/unix/big-endian/: m3makefile cm3/m3-libs/m3core/src/unix/darwin-generic/: m3makefile cm3/m3-libs/m3core/src/unix/freebsd-1/: m3makefile cm3/m3-libs/m3core/src/unix/freebsd-2/: m3makefile cm3/m3-libs/m3core/src/unix/freebsd-3/: m3makefile cm3/m3-libs/m3core/src/unix/freebsd-4/: m3makefile cm3/m3-libs/m3core/src/unix/hpux-7-0/: m3makefile cm3/m3-libs/m3core/src/unix/ibm-4-3/: m3makefile cm3/m3-libs/m3core/src/unix/irix-5.2/: m3makefile cm3/m3-libs/m3core/src/unix/linux/: m3makefile cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 Removed files: cm3/m3-libs/m3core/src/unix/ultrix-3-1.SEQUENT/: Uexec.i3 cm3/m3-libs/m3core/src/unix/ultrix-3-1.SUN3/: Uexec.i3 cm3/m3-libs/m3core/src/unix/ultrix-3-1.SUN386/: Uexec.i3 cm3/m3-libs/m3core/src/unix/ultrix-3-1.UMAX/: Uexec.i3 cm3/m3-libs/m3core/src/unix/ultrix-3-1.VAX/: Uexec.i3 cm3/m3-libs/m3core/src/unix/sunos-4-x/: Uexec.i3 cm3/m3-libs/m3core/src/unix/sysv-4.0/: Uexec.i3 cm3/m3-libs/m3core/src/unix/ultrix-3-1.AP3000/: Uexec.i3 cm3/m3-libs/m3core/src/unix/ultrix-3-1.ARM/: Uexec.i3 cm3/m3-libs/m3core/src/unix/ultrix-3-1.DS3100/: Uexec.i3 cm3/m3-libs/m3core/src/unix/ultrix-3-1.NEXT/: Uexec.i3 cm3/m3-libs/m3core/src/unix/linux-libc6/: Uexec.i3 cm3/m3-libs/m3core/src/unix/little-endian/: Uexec.i3 cm3/m3-libs/m3core/src/unix/netbsd2-i386/: Uexec.i3 cm3/m3-libs/m3core/src/unix/os2/: Uexec.i3 cm3/m3-libs/m3core/src/unix/osf-1.generic/: Uexec.i3 cm3/m3-libs/m3core/src/unix/solaris-2-x/: Uexec.i3 cm3/m3-libs/m3core/src/unix/aix-3-2/: Uexec.i3 cm3/m3-libs/m3core/src/unix/aix-ps2-1-2/: Uexec.i3 cm3/m3-libs/m3core/src/unix/big-endian/: Uexec.i3 cm3/m3-libs/m3core/src/unix/darwin-generic/: Uexec.i3 cm3/m3-libs/m3core/src/unix/freebsd-1/: Uexec.i3 cm3/m3-libs/m3core/src/unix/freebsd-2/: Uexec.i3 cm3/m3-libs/m3core/src/unix/freebsd-3/: Uexec.i3 cm3/m3-libs/m3core/src/unix/freebsd-4/: Uexec.i3 cm3/m3-libs/m3core/src/unix/hpux-7-0/: Uexec.i3 cm3/m3-libs/m3core/src/unix/ibm-4-3/: Uexec.i3 cm3/m3-libs/m3core/src/unix/irix-5.2/: Uexec.i3 cm3/m3-libs/m3core/src/unix/linux/: Uexec.i3 Log message: make it portable From jkrell at elego.de Tue Jan 13 12:09:39 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 12:09:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113110939.1EEE010D5DA1@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 12:09:39 Removed files: cm3/m3-libs/m3core/src/unix/Common/: Uwaitpid.i3 Uwaitpid.c Log message: and delete these too From jkrell at elego.de Tue Jan 13 12:59:29 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 12:59:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113115929.1B8B410D5F41@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 12:59:29 Modified files: cm3/m3-libs/m3core/src/unix/Common/: m3makefile Log message: forgot to commit this (cvs commit isn't commiting anything I have to manually list files; granted, cvs diff would have shown me) From jkrell at elego.de Tue Jan 13 13:01:30 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 13:01:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113120135.1F0BD10D5F5B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 13:01:30 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Uexec.i3 Added files: cm3/m3-libs/m3core/src/unix/Common/: Uexec.c Log message: and these From jkrell at elego.de Tue Jan 13 13:22:44 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 13:22:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113122244.8FAEB714573@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 13:22:44 Modified files: cm3/m3-libs/m3core/src/win32/: WinNT.i3 Log message: fix warning on large numbers by using unsigned From jkrell at elego.de Tue Jan 13 13:28:49 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 13:28:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113122849.4C70B10D4EAA@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 13:28:49 Removed files: cm3/m3-libs/sysutils/src/POSIX/: Sysutils_DoesWaitPidYield.i3 Sysutils_Uwaitpid.c Sysutils_Uwaitpid.i3 Log message: and delete these From jkrell at elego.de Tue Jan 13 13:30:33 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 13:30:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113123036.AD5F610D5F41@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 13:30:33 Modified files: cm3/m3-sys/cminstall/src/config/: NT386.common Log message: fix copy/paste error, no effect as long as cygwin using win32 threads From jkrell at elego.de Tue Jan 13 14:47:16 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 14:47:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113134716.7367910D5FCD@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 14:47:16 Modified files: cm3/m3-libs/m3core/src/Csupport/libgcc/: libgcc.c Log message: Quash warning on Darwin about libgcc.o having no symbols, by introducing an arbitrary symbol. From jkrell at elego.de Tue Jan 13 15:20:19 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 15:20:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113142019.7A93010D5FD0@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 15:20:19 Modified files: cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 Log message: both my change and Tony's change are 'difficult' to bootstrap; cut the dependency from sysutils to newer m3core, somewhat sleazily; this should be changed as indicated once newer m3core is well established, or maybe, again, by copying code From jkrell at elego.de Tue Jan 13 15:24:05 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 15:24:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113142405.CC98710D5FD0@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 15:24:05 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Log message: fix for Darwin (10.4) From jkrell at elego.de Tue Jan 13 15:24:59 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 15:24:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113142459.7953810D5FD0@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 15:24:59 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Usignal.i3 Log message: fix line endings From jkrell at elego.de Tue Jan 13 15:33:28 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 15:33:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113143328.E9B7D10D5359@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 15:33:28 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 ThreadPThreadC.c ThreadPThreadC.i3 cm3/m3-libs/m3core/src/unix/Common/: Usignal.i3 m3makefile Removed files: cm3/m3-libs/m3core/src/unix/Common/: Usem.i3 Log message: Darwin tools didn't like these variables, something about common variables and shared/dynamic libs. Possibly merely initializing them would fix this, however there was also the nagging problem of the incorrect type declarations, which arguably could be fixed by just removing them and declaring the variables to be ints. Anyway, the solution here is /very/ portable, mechanical, and a little contorted. Uses of sem_* and sigsuspend are moved into small C wrappers. The global variables they operate on are implied at the Modula-3 level. From jkrell at elego.de Tue Jan 13 15:39:13 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 13 Jan 2009 15:39:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090113143913.0DC1910D5359@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/13 15:39:13 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: PPC_DARWIN Log message: share a bunch of code From jay.krell at cornell.edu Wed Jan 14 00:59:30 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 13 Jan 2009 23:59:30 +0000 Subject: [M3commit] waitpit In-Reply-To: <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> References: <20090112092033.2748010D5FD1@birch.elegosoft.com> <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> Message-ID: > I think "what I was missing" here is the option of changing the Process.Wait or > SchedulerPosix.WaitProcess interface to return the status bits. I don't think this > is how it was before, (which I think was implied). It looks like I added SchedulerPosix.WaitProcess only in 2008, while fixing the inefficient waitpid in libm3, so it wasn't some long standing interface, and changing it very reasonable. Had I only noticed sysutils at the time, I /might/ have thought to define it the way you did. (Still the bootstrap issue, neither WaitProcess signature is in older m3core.) - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3commit at elegosoft.comSubject: RE: waitpitDate: Tue, 13 Jan 2009 05:50:43 +0000 I think "what I was missing" here is the option of changing the Process.Wait or SchedulerPosix.WaitProcess interface to return the status bits. I don't think this is how it was before, (which I think was implied).Maybe I misread it, between returning the pid/success vs. the status word?I had added the new interface SchedulerPosix.DoesWaitPidYield, but left others asis.Now, true, I'm arguing both sides, since I did make Uerror.i3 incompatible with some clients.Exposing more information like that seems a good solution, leaving the next level down to waitpid(0) or waitpid(nohang).I think user threads are missing some code now, since ThreadPWait (but not ThreadPScheduler) was used by them. But I admit, I didn't build them either, so whether they worked or not, and whether I kept them working or not, don't know. They are never build by default. I think the problem with the encoded exit status it is just a bit "wierd", and hardly anyone would want to use it asis.The repacked value makes more sense? Slightly?Hm..how about this...? interface Uexec; <*external Uexec_WIFEXITED> PROCEDURE WIFEXITED(int status):BOOLEAN;etc. the various other macros/functions in Posix, well, at least two or three of them, theones that access the relevant fields. Uexec.c typedef size_t BOOLEAN; /* ? safe at least, to return a full word's worth of bits */ #define TRUE 1 #define FALSE 1 BOOLEAN Uexec_WIFEEXITED(int status) { return WIFEEXITED(status) ? TRUE : FALSE; } That fits one of the molds well imho.I like what I had in Uwaitpid, but it is hard to argue for it vs. this.They are very similar.This has the advantage of only returning what is asked for.Uwaitpid had the advantage of probably being faster -- less storage efficient, but fewer function calls / roundtrips and such, since WIFEEXITED is likely a macro and Modula-3 loses the inlining. Surely not a big deal either way. Both options are very portable. Then, the rejiggering/repacking of the bits can be done portably, without regard to endiannness and without regard to the bitfield layout of the int; the bitfields can go away, leaving just the int to be unpacked by these macros-wrapped-in-functions. (I believe it is portable defined as an int but I'll check). Ok? - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3commit at elegosoft.comSubject: RE: [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 12:08:29 +0000 Hm. So I guess the point then is to return one "reasonable" integer, and"reasonable" is actually defined as (coredump << 15) | (termsig << 8) | exitcode That's the point of the repacking?and coredump and termsig are usually 0. Anyway, I don't think even this 7/1/8/16 split is specified by Posix. Right?Uwaitpid.c was a good portable method I think.It was based on the example code in online Posix docs (which you originally pointed me to). - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 22:25:25 +1100CC: m3commit at elegosoft.comSubject: Re: [M3commit] CVS Update: cm3 On 12 Jan 2009, at 21:11, Jay wrote: > relies on particular endian-ness of the status > word they return. Really, those clients should > be using proper bit-shifts and bit-masks to extract > the right values rather than some endian- dependent RECORD layout defined in Uexec Wasn't Uwaitpid.c a good portable way to do exactly that? I didn't look too closely at that. I wanted something that retained the simplicity of calling waitpid as: PROCEDURE waitpid(pid: int; VAR status: int; options: int): int; I guess it can be written in Modula-3 though, if the headers are cloned as they are. Aren't {I386,AMD64}_DARWIN broken here? I don't think so -- Uexec is still there. Besides all "my" ports, which don't define those types. Yeah yeah, all I have to do is switch on endian and I can introduce them.. But really, clients of waitpid/SchedulerPosix.WaitProcess should be prepared to shift the status return value correctly! After all, the interface doc for Process.Wait indicates that the return value is the status word. I'll see about Cygwin pthreads. Yes, it would be a more coherent solution. - Jay> Date: Mon, 12 Jan 2009 10:20:33 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 09/01/12 10:20:33> > Modified files:> cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > ThreadPWait.m3 > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > m3makefile > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > Log message:> Try to clean up mess with Process.Wait and System.Wait based on waitpid.> > Packing is now returned to Process.Wait and System.Wait where it used to be.> > Not sure if this re-packing is needed by clients, but should verify.> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 14 01:25:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 14 Jan 2009 11:25:07 +1100 Subject: [M3commit] waitpit In-Reply-To: References: <20090112092033.2748010D5FD1@birch.elegosoft.com> <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> Message-ID: <164AB63E-E3CA-4E08-B15B-9F78F2B648B9@cs.purdue.edu> Yeah, that's right. I think we should still ensure that clients of Process.Wait and System.Wait don't do anything more than check the non- zero status value that they return. I suspect the packing was there to ensure that current clients were able to do that reliably (are there systems that encode non-zero successful exit status for processes?). Hmm. On 14 Jan 2009, at 10:59, Jay wrote: > > I think "what I was missing" here is the option of changing the > Process.Wait or > > SchedulerPosix.WaitProcess interface to return the status bits. > I don't think this > > is how it was before, (which I think was implied). > > It looks like I added SchedulerPosix.WaitProcess only in 2008, while > fixing the inefficient waitpid in libm3, > so it wasn't some long standing interface, and changing it very > reasonable. > Had I only noticed sysutils at the time, I /might/ have thought to > define it the way you did. > (Still the bootstrap issue, neither WaitProcess signature is in > older m3core.) > > - Jay > > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3commit at elegosoft.com > Subject: RE: waitpit > Date: Tue, 13 Jan 2009 05:50:43 +0000 > > I think "what I was missing" here is the option of changing the > Process.Wait or SchedulerPosix.WaitProcess interface to return the > status bits. I don't think this is how it was before, (which I think > was implied). > Maybe I misread it, between returning the pid/success vs. the status > word? > I had added the new interface SchedulerPosix.DoesWaitPidYield, but > left others asis. > Now, true, I'm arguing both sides, since I did make Uerror.i3 > incompatible with some clients. > Exposing more information like that seems a good solution, leaving > the next level down to waitpid(0) or waitpid(nohang). > I think user threads are missing some code now, since ThreadPWait > (but not ThreadPScheduler) was used by them. But I admit, I didn't > build them either, so whether they worked or not, and whether I kept > them working or not, don't know. They are never build by default. > > I think the problem with the encoded exit status it is just a bit > "wierd", and hardly anyone would want to use it asis. > The repacked value makes more sense? Slightly? > Hm..how about this...? > > > interface Uexec; > > <*external Uexec_WIFEXITED> PROCEDURE WIFEXITED(int status):BOOLEAN; > etc. the various other macros/functions in Posix, well, at least two > or three of them, the > ones that access the relevant fields. > > Uexec.c > typedef size_t BOOLEAN; /* ? safe at least, to return a full > word's worth of bits */ > #define TRUE 1 > #define FALSE 1 > > BOOLEAN Uexec_WIFEEXITED(int status) > { > return WIFEEXITED(status) ? TRUE : FALSE; > } > > That fits one of the molds well imho. > I like what I had in Uwaitpid, but it is hard to argue for it vs. > this. > They are very similar. > This has the advantage of only returning what is asked for. > Uwaitpid had the advantage of probably being faster -- less storage > efficient, but fewer function calls / roundtrips and such, since > WIFEEXITED is likely a macro and Modula-3 loses the inlining. Surely > not a big deal either way. Both options are very portable. > > Then, the rejiggering/repacking of the bits can be done portably, > without regard to endiannness and without regard to the bitfield > layout of the int; the bitfields can go away, leaving just the int > to be unpacked by these macros-wrapped-in-functions. (I believe it > is portable defined as an int but I'll check). > > Ok? > > - Jay > > > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3commit at elegosoft.com > Subject: RE: [M3commit] CVS Update: cm3 > Date: Mon, 12 Jan 2009 12:08:29 +0000 > > Hm. So I guess the point then is to return one "reasonable" integer, > and > "reasonable" is actually defined as > > (coredump << 15) | (termsig << 8) | exitcode > > That's the point of the repacking? > and coredump and termsig are usually 0. > > Anyway, I don't think even this 7/1/8/16 split is specified by > Posix. Right? > Uwaitpid.c was a good portable method I think. > It was based on the example code in online Posix docs (which you > originally pointed me to). > > - Jay > > > > > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 22:25:25 +1100 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > > > On 12 Jan 2009, at 21:11, Jay wrote: > > > relies on particular endian-ness of the status > > word they return. Really, those clients should > > be using proper bit-shifts and bit-masks to extract > > the right values rather than some endian- dependent RECORD layout > defined in Uexec > > Wasn't Uwaitpid.c a good portable way to do exactly that? > > I didn't look too closely at that. I wanted something that retained > the simplicity of calling waitpid as: > > PROCEDURE waitpid(pid: int; VAR status: int; options: int): int; > > I guess it can be written in Modula-3 though, if the headers are > cloned as they are. > Aren't {I386,AMD64}_DARWIN broken here? > > I don't think so -- Uexec is still there. > > Besides all "my" ports, which don't define those types. > Yeah yeah, all I have to do is switch on endian and I can introduce > them.. > > But really, clients of waitpid/SchedulerPosix.WaitProcess should be > prepared to shift the status return value correctly! After all, the > interface doc for Process.Wait indicates that the return value is > the status word. > > I'll see about Cygwin pthreads. > > Yes, it would be a more coherent solution. > > > > - Jay > > > Date: Mon, 12 Jan 2009 10:20:33 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 09/01/12 10:20:33 > > > > Modified files: > > cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > > ThreadPWait.m3 > > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > > m3makefile > > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > > > Log message: > > Try to clean up mess with Process.Wait and System.Wait based on > waitpid. > > > > Packing is now returned to Process.Wait and System.Wait where it > used to be. > > > > Not sure if this re-packing is needed by clients, but should verify. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 14 00:45:23 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 14 Jan 2009 10:45:23 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20090113142019.7A93010D5FD0@birch.elegosoft.com> References: <20090113142019.7A93010D5FD0@birch.elegosoft.com> Message-ID: <034D3CBF-C0D2-46F6-9F82-1DA6737D1A7B@cs.purdue.edu> I don't see what's difficult to bootstrap here. Why do you need to build against old m3core? On 13 Jan 2009, at 15:20, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 09/01/13 15:20:19 > > Modified files: > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 > > Log message: > both my change and Tony's change are 'difficult' to bootstrap; cut > the dependency from sysutils to newer m3core, somewhat sleazily; > this should be changed as indicated once newer m3core is well > established, or maybe, again, by copying code From jay.krell at cornell.edu Wed Jan 14 03:42:42 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 14 Jan 2009 02:42:42 +0000 Subject: [M3commit] waitpid In-Reply-To: <164AB63E-E3CA-4E08-B15B-9F78F2B648B9@cs.purdue.edu> References: <20090112092033.2748010D5FD1@birch.elegosoft.com> <72636540-8AD6-433B-ABFE-1F7BDACD8D8C@cs.purdue.edu> <164AB63E-E3CA-4E08-B15B-9F78F2B648B9@cs.purdue.edu> Message-ID: > (are there systems that encode non-zero successful exit status for processes?). Hmm. I don't know, but I read that Posix says something like "zero is zero". Like, if child process calls exit(0) or _exit(0), then the full int status will be 0 (even if only 8 bits of exit's parameter are preserved). I thought I read long ago that VMS inverted the meaning, but then C development libraries had to reinvert it for source compatibility. Maybe I'll know better when I bring Modula-3 on VMS back. :) Whatever I was reading gave EXIT_SUCCESS and EXIT_FAILURE as the only portable values...but certainly there is plenty of hardcoded exit(0), thus the theoretically compat hacks. Nevertheless, a "rich" exit code has its uses. Like "number of files copies" or such various common conditions. But maybe we don't care. > I suspect the packing was there to ensure that current clients were able to do that reliably I don't follow. Do you mean, like, guarding against "zero is not zero", such as, like, the filler being "random"? I'll try poke around. In the meantime, see Uexec.RepackStatus that I put in? And definitely look at what I did to ThreadPThread. Perhaps too contorted. Perhaps declare ackSem and mask as arbibrary int and the relevant functions taking ADDRESS, and see if initializing the variables with { 0 } will fix the problem I had on Darwin. Or, if not, I can put in accessor functions for the globals, leaving them static. That'll surely work, didn't think of it till just now. ps: The Darwin PPC 10.4 dylibs don't have make/get/set/swapcontext either. I think I checked both System.dylib and libc.dylib. A "hybrid" where some platforms use setjmp/long and some use context is probably ok. A larger issue here..another thread... - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Wed, 14 Jan 2009 11:25:07 +1100CC: m3commit at elegosoft.comSubject: Re: [M3commit] waitpit Yeah, that's right. I think we should still ensure that clients of Process.Wait and System.Wait don't do anything more than check the non-zero status value that they return. I suspect the packing was there to ensure that current clients were able to do that reliably (are there systems that encode non-zero successful exit status for processes?). Hmm. On 14 Jan 2009, at 10:59, Jay wrote: > I think "what I was missing" here is the option of changing the Process.Wait or > SchedulerPosix.WaitProcess interface to return the status bits. I don't think this > is how it was before, (which I think was implied). It looks like I added SchedulerPosix.WaitProcess only in 2008, while fixing the inefficient waitpid in libm3,so it wasn't some long standing interface, and changing it very reasonable.Had I only noticed sysutils at the time, I /might/ have thought to define it the way you did.(Still the bootstrap issue, neither WaitProcess signature is in older m3core.) - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3commit at elegosoft.comSubject: RE: waitpitDate: Tue, 13 Jan 2009 05:50:43 +0000I think "what I was missing" here is the option of changing the Process.Wait or SchedulerPosix.WaitProcess interface to return the status bits. I don't think this is how it was before, (which I think was implied).Maybe I misread it, between returning the pid/success vs. the status word?I had added the new interface SchedulerPosix.DoesWaitPidYield, but left others asis.Now, true, I'm arguing both sides, since I did make Uerror.i3 incompatible with some clients.Exposing more information like that seems a good solution, leaving the next level down to waitpid(0) or waitpid(nohang).I think user threads are missing some code now, since ThreadPWait (but not ThreadPScheduler) was used by them. But I admit, I didn't build them either, so whether they worked or not, and whether I kept them working or not, don't know. They are never build by default. I think the problem with the encoded exit status it is just a bit "wierd", and hardly anyone would want to use it asis.The repacked value makes more sense? Slightly?Hm..how about this...? interface Uexec; <*external Uexec_WIFEXITED> PROCEDURE WIFEXITED(int status):BOOLEAN;etc. the various other macros/functions in Posix, well, at least two or three of them, theones that access the relevant fields. Uexec.c typedef size_t BOOLEAN; /* ? safe at least, to return a full word's worth of bits */ #define TRUE 1 #define FALSE 1 BOOLEAN Uexec_WIFEEXITED(int status) { return WIFEEXITED(status) ? TRUE : FALSE; } That fits one of the molds well imho.I like what I had in Uwaitpid, but it is hard to argue for it vs. this.They are very similar.This has the advantage of only returning what is asked for.Uwaitpid had the advantage of probably being faster -- less storage efficient, but fewer function calls / roundtrips and such, since WIFEEXITED is likely a macro and Modula-3 loses the inlining. Surely not a big deal either way. Both options are very portable. Then, the rejiggering/repacking of the bits can be done portably, without regard to endiannness and without regard to the bitfield layout of the int; the bitfields can go away, leaving just the int to be unpacked by these macros-wrapped-in-functions. (I believe it is portable defined as an int but I'll check). Ok? - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3commit at elegosoft.comSubject: RE: [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 12:08:29 +0000Hm. So I guess the point then is to return one "reasonable" integer, and"reasonable" is actually defined as (coredump << 15) | (termsig << 8) | exitcode That's the point of the repacking?and coredump and termsig are usually 0. Anyway, I don't think even this 7/1/8/16 split is specified by Posix. Right?Uwaitpid.c was a good portable method I think.It was based on the example code in online Posix docs (which you originally pointed me to). - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 22:25:25 +1100CC: m3commit at elegosoft.comSubject: Re: [M3commit] CVS Update: cm3 On 12 Jan 2009, at 21:11, Jay wrote: > relies on particular endian-ness of the status > word they return. Really, those clients should > be using proper bit-shifts and bit-masks to extract > the right values rather than some endian- dependent RECORD layout defined in Uexec Wasn't Uwaitpid.c a good portable way to do exactly that? I didn't look too closely at that. I wanted something that retained the simplicity of calling waitpid as: PROCEDURE waitpid(pid: int; VAR status: int; options: int): int; I guess it can be written in Modula-3 though, if the headers are cloned as they are. Aren't {I386,AMD64}_DARWIN broken here? I don't think so -- Uexec is still there. Besides all "my" ports, which don't define those types. Yeah yeah, all I have to do is switch on endian and I can introduce them.. But really, clients of waitpid/SchedulerPosix.WaitProcess should be prepared to shift the status return value correctly! After all, the interface doc for Process.Wait indicates that the return value is the status word. I'll see about Cygwin pthreads. Yes, it would be a more coherent solution. - Jay> Date: Mon, 12 Jan 2009 10:20:33 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 09/01/12 10:20:33> > Modified files:> cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3 > ThreadPWait.m3 > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3 > m3makefile > cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile > > Log message:> Try to clean up mess with Process.Wait and System.Wait based on waitpid.> > Packing is now returned to Process.Wait and System.Wait where it used to be.> > Not sure if this re-packing is needed by clients, but should verify.> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jan 14 03:48:48 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 14 Jan 2009 02:48:48 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <034D3CBF-C0D2-46F6-9F82-1DA6737D1A7B@cs.purdue.edu> References: <20090113142019.7A93010D5FD0@birch.elegosoft.com> <034D3CBF-C0D2-46F6-9F82-1DA6737D1A7B@cs.purdue.edu> Message-ID: I didn't check for PPC_DARWIN has Tinderbox outputs, so I was bootstrapping from the latest release -- 5.5. If I was desparate I could bootstrap cross. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Wed, 14 Jan 2009 10:45:23 +1100> CC: m3commit at elegosoft.com> Subject: Re: [M3commit] CVS Update: cm3> > I don't see what's difficult to bootstrap here. Why do you need to > build against old m3core?> > On 13 Jan 2009, at 15:20, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 09/01/13 15:20:19> >> > Modified files:> > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3> >> > Log message:> > both my change and Tony's change are 'difficult' to bootstrap; cut > > the dependency from sysutils to newer m3core, somewhat sleazily; > > this should be changed as indicated once newer m3core is well > > established, or maybe, again, by copying code> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 14 05:34:43 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 14 Jan 2009 15:34:43 +1100 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20090113142019.7A93010D5FD0@birch.elegosoft.com> <034D3CBF-C0D2-46F6-9F82-1DA6737D1A7B@cs.purdue.edu> Message-ID: There used to PPC_DARWIN Tinderbox, but my machines at home are packed up in my basement... You should be able to use the bootstrap files from ftp://ftp.cs.purdue.edu/m3/PPC_DARWIN . I have AMD64_DARWIN there too. On 14 Jan 2009, at 13:48, Jay wrote: > I didn't check for PPC_DARWIN has Tinderbox outputs, so I was > bootstrapping from the latest release -- 5.5. > If I was desparate I could bootstrap cross. > > - Jay > > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Wed, 14 Jan 2009 10:45:23 +1100 > > CC: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > I don't see what's difficult to bootstrap here. Why do you need to > > build against old m3core? > > > > On 13 Jan 2009, at 15:20, Jay Krell wrote: > > > > > CVSROOT: /usr/cvs > > > Changes by: jkrell at birch. 09/01/13 15:20:19 > > > > > > Modified files: > > > cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 > > > > > > Log message: > > > both my change and Tony's change are 'difficult' to bootstrap; cut > > > the dependency from sysutils to newer m3core, somewhat sleazily; > > > this should be changed as indicated once newer m3core is well > > > established, or maybe, again, by copying code > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Wed Jan 14 10:34:21 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jan 2009 10:34:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090114093421.6DE5A10D5EC8@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/14 10:34:20 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Uexec.c Unix.i3 Ustat.i3 m3makefile Added files: cm3/m3-libs/m3core/src/unix/Common/: Uconstants.c Removed files: cm3/m3-libs/m3core/src/unix/Common/: Uerror.c Log message: Move all constants-implemented-as-variables to one file dedicated to them -- Uconstants.c. This way we don't have to keep picking up nickels and dimes on platforms that need to statically link to them (cygwin), and we keep functions and data separate. Not all of the constants in this file are yet active, but they are ok to be there ahead of time. More will migrate here soon. We should perhaps rely on Posix mandating some of the values, or perhaps that some of the values happen to be identical on all platforms, and then make them consts, or we can just play it very safe and err toward making them variables. As well we will look into removing their uses behind C wrappers. From jkrell at elego.de Wed Jan 14 10:36:24 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 14 Jan 2009 10:36:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090114093625.1A75D10D5EC8@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/14 10:36:24 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Uconstants.c Log message: add more #includes so it compiles From jkrell at elego.de Mon Jan 19 06:14:26 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 6:14:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119051426.3D5A2714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 06:14:26 Added files: cm3/scripts/: config.c Log message: something like autoconf; sniffs a bunch about a system, though not yet for example the pthread initializers or the exact layout of struct tm From jkrell at elego.de Mon Jan 19 06:34:40 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 6:34:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119053442.3656E10D5F16@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 06:34:40 Modified files: cm3/scripts/: config.c Log message: some cleanup and improvements From jkrell at elego.de Mon Jan 19 10:43:40 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 10:43:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119094340.2D0CB714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 10:43:40 Modified files: cm3/scripts/: config.c Log message: demonstrate start of 'fully dynamic struct reconstitution', at least for structs composed of particular types; this could be developed into a more complete struct declaration cloner, but I don't think we'll need it From jkrell at elego.de Mon Jan 19 11:03:19 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 11:03:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119100319.D1009714573@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 11:03:19 Modified files: cm3/scripts/: config.c Log message: output struct linger, though again, probably will just use more C wrappers instead From jkrell at elego.de Mon Jan 19 11:19:12 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 11:19:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119101912.850EF714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 11:19:12 Modified files: cm3/scripts/: config.c Log message: support CC and CFLAGS environment variables, not clear if we should still try -lpthread and -Werror, or if we should split the 'possible' array between binary name and flags, and then probe only whichever is not an environment variable; really should support command line switches too but none of this likely matters much From jkrell at elego.de Mon Jan 19 12:11:28 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 12:11:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119111128.61BBA10D5F2E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 12:11:28 Modified files: cm3/m3-comm/tcp/src/POSIX/: IP.m3 Log message: let Unetdb.TRY_AGAIN, NO_RECOVERY, NO_ADDRESS be constant variables initialized in C instead of constants, for easier portability; alternatively, move this lone use to C From jkrell at elego.de Mon Jan 19 12:16:10 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 12:16:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119111610.827C4714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 12:16:10 Modified files: cm3/m3-comm/tcp/src/POSIX/: TCP.m3 Log message: convert a few tabs to spaces From jkrell at elego.de Mon Jan 19 14:05:50 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 14:05:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119130550.E9B272200076@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 14:05:50 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: ProcessCygwin.m3 Log message: fix newlines From jkrell at elego.de Mon Jan 19 14:09:15 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 14:09:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119130917.67F06744003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 14:09:15 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: FSPosix.m3 FilePosix.m3 SocketPosix.m3 Log message: allow for more constants to be constant variables initialized in C to reduce header cloning From jkrell at elego.de Mon Jan 19 14:09:39 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 14:09:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119130940.64A5810D4C64@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 14:09:39 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3 Log message: allow for more constants to be constant variables initialized in C to reduce header cloning From jkrell at elego.de Mon Jan 19 14:31:32 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 14:31:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119133133.3C1CF10D5ECA@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 14:31:32 Modified files: cm3/m3-libs/m3core/src/C/NT386/: Csetjmp.i3 Log message: fix newlines From jkrell at elego.de Mon Jan 19 14:32:45 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 14:32:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119133246.059EC72575C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 14:32:45 Modified files: cm3/m3-libs/m3core/src/C/NT386/: Csetjmp.i3 Log message: Don't trash the stack on Cygwin when using pthreads; the usual suspect, how did I miss it..? From jkrell at elego.de Mon Jan 19 14:40:43 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 14:40:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119134043.977C610D5ECA@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 14:40:43 Modified files: cm3/m3-libs/m3core/src/thread/WIN32/: m3makefile Log message: fix NT386; maybe more surgery here once Cygwin uses pthreads From jkrell at elego.de Mon Jan 19 14:47:15 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 14:47:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119134715.2B80410D5F14@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 14:47:15 Modified files: cm3/scripts/python/: pylib.py Log message: verbosity tweaks From jkrell at elego.de Mon Jan 19 15:59:04 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 15:59:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119145904.4816F10D5F14@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 15:59:04 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Uconstants.c Log message: Prepare to move a bunch of constants to constant variables. Content can be added here ahead of the use, assuming there are no global namespace clashes. Also mechanize some of the tedium here. From jkrell at elego.de Mon Jan 19 16:03:29 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 16:03:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119150329.D00582200008@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 16:03:29 Removed files: cm3/m3-libs/m3core/src/unix/Common/: Uerror.i3.cpp Uutsname.i3.cpp cm3/m3-libs/m3core/src/unix/cygwin/: Unix.i3.cpp Utypes.i3.cpp 1.cmd cm3/m3-libs/m3core/src/unix/openbsd-common/: 1.cpp 1.sh Log message: delete files that used to be used to help clone headers but which are no longer used since other better tactics have been adopted From jkrell at elego.de Mon Jan 19 16:05:21 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 16:05:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119150521.6ED3D10D5F14@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 16:05:21 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Uexec.i3 Unix.i3 UnixC.c Ustat.i3 Log message: Fix newlines. From jkrell at elego.de Mon Jan 19 16:57:22 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 16:57:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119155722.BD24710D5F30@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 16:57:22 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile cm3/m3-libs/m3core/src/unix/Common/: Uconstants.c Uexec.c Unetdb.i3 Unix.i3 Upthread.i3 Uresource.i3 Usignal.i3 Usocket.i3 Ustat.i3 Utime.i3 Utypes.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 m3makefile cm3/m3-libs/m3core/src/unix/freebsd-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 cm3/m3-sys/cminstall/src/config/: NT386.common Removed files: cm3/m3-libs/m3core/src/unix/cygwin/: 1.c Uerror.i3 Usignal.i3 Usignal.i3.c Ustat.i3 cm3/m3-libs/m3core/src/unix/linux-sparc/: Usignal.i3 Usocket.i3 m3makefile Log message: add Cygwin Upthread support, to be used very soon move a lot of constants out of cloned headers and into constant variables in C Upthread.i3 remove commented out pthread_mutexattr_t, pthread_condattr_t for now, we always pass NULL destructor_t is always the same start_routine_t is always the same move PTHREAD_MUTEX_INITIALIZER, PTHREAD_COND_INITIALIZER to be constant variables in C Unix.i3 move constants to constant C variables: O_RDONLY O_RDWR O_CREAT O_EXCL O_TRUNC O_NONBLOCK Usignal.i3: move constants to constant C variables: SIGINT SIGKILL Usocket.i3: move constants to constant C variables: SOCK_STREAM SOCK_DGRAM SO_REUSEADDR SO_KEEPALIVE SO_LINGER SOL_SOCKET AF_INET MSG_PEEK Utypes.i3: clock_t is never used; remove it Uresource.i3: move constant RUSAGE_SELF to constant C variable Unetdb.i3 move constants to constant C variables: TRY_AGAIN NO_RECOVERY NO_ADDRESS as part of this then, we can delete linux-sparc and some cygwin files, leaving only Usysdep.i3 in openbsd-common, cygwin, linux-common, freebsd-common From jkrell at elego.de Mon Jan 19 17:01:33 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 17:01:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119160134.05AE910D5F74@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 17:01:33 Modified files: cm3/m3-libs/m3core/src/unix/Common/: m3makefile Log message: forgot this From jkrell at elego.de Mon Jan 19 17:04:03 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 17:04:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119160403.4037D10D5F74@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 17:04:03 Modified files: cm3/m3-libs/m3core/src/runtime/: m3makefile cm3/m3-libs/m3core/src/runtime/common/: m3makefile cm3/m3-libs/m3core/src/thread/: m3makefile cm3/m3-libs/m3core/src/thread/WIN32/: m3makefile Removed files: cm3/m3-libs/m3core/src/thread/WIN32/: SchedulerPosix.m3 Log message: Switch NT386GNU (aka I386_CYGWIN) to use pthreads. From jkrell at elego.de Mon Jan 19 17:11:30 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 17:11:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119161130.826B710D5F74@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 17:11:30 Modified files: cm3/m3-libs/m3core/src/thread/WIN32/: ThreadWin32.m3 Log message: go back to version 26 now that Cygwin uses pthreads From jkrell at elego.de Mon Jan 19 17:12:59 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 17:12:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119161259.6223310D5F74@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 17:12:59 Modified files: cm3/m3-libs/m3core/src/thread/WIN32/: m3makefile ThreadWin32.m3 Removed files: cm3/m3-libs/m3core/src/thread/WIN32/: ThreadInternal.i3 Log message: finish cleanup now that cygwin uses pthreads -- remove dummy SchedulerPosix implementation From jkrell at elego.de Mon Jan 19 17:20:10 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 17:20:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119162010.6BEC110D5F74@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 17:20:10 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Utime.i3 Log message: fix -- was missing int import (had copied changes across source trees..) From jkrell at elego.de Mon Jan 19 17:37:09 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 17:37:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119163709.583C510D5F74@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 17:37:09 Added files: cm3/m3-libs/m3core/src/runtime/POSIX/: RTProcessPosixC.c RTProcessPosixC.i3 Log message: prepare to remove Uresource.i3; once confirmed this is the only user From jkrell at elego.de Mon Jan 19 17:38:38 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 17:38:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119163838.26B0A714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 17:38:38 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Utime.i3 Log message: oops From jkrell at elego.de Mon Jan 19 23:37:09 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 23:37:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119223710.01AD7714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 23:37:09 Modified files: cm3/scripts/python/: make-dist.py Log message: make-dist needs to copy Uerror.obj to bootstrap cygwin distribution; take hand.obj while at it (lib/*.obj) From jkrell at elego.de Mon Jan 19 23:57:53 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 19 Jan 2009 23:57:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090119225753.92E8B10D5F31@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/19 23:57:53 Modified files: cm3/scripts/python/: make-dist.py Log message: pylib.py doesn't filter packages when they are a function parameter, only if they are on the command line; this should fix filtering out of serial on cygwin in make-dist From jay.krell at cornell.edu Tue Jan 20 06:40:07 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 20 Jan 2009 05:40:07 +0000 Subject: [M3commit] FW: [M3devel] move to version 5.7.1? In-Reply-To: <4974CB61.1E75.00D7.1@scires.com> References: <4974CB61.1E75.00D7.1@scires.com> Message-ID: [was truncated] ---------------------------------------- > From: jay.krell at cornell.edu > To: rcoleburn at scires.com; m3devel at elegosoft.com > Subject: RE: [M3devel] move to version 5.7.1? > Date: Tue, 20 Jan 2009 02:28:07 +0000 > > > I meant, can we update the version stamp in the compiler. > Nothing about releases or what not. > But I'll take some of the bait. :) > > > My archives are already pretty easy to use, but need a short readme. > > > HP-UX is not yet supported, but will be fairly soon, maybe this week. > 64bit first, this week, then 32bit, by end of next week? > (HP-UX also runs on IA64 btw, but I couldn't get my hardware to boot > my OS, maybe too old OS, maybe need to fiddle with EFI console settings. > I will be doing IA64_LINUX before long. IA64_FREEBSD also wouldn't boot > for me.) > > > Where is the line between "free Microsoft tools" and "free Python"? > > > Python is NOT needed to build cm3, just as bash is not needed. > > > There are VERY handy scripts for doing so, in both languages. > They are just slightly elaborate ways to cd around and run cm3. > > > I know, I know..they are each line crossing, everything I have to > install is a line. If it was just "free Python" and no need for "free Microsoft", > that would be similar as just "free Microsoft". And "free Microsoft" > is higher quality and more trusted than "free Python", and, clearly, > simply more necessary, unless you use Cygwin. > > > Cmd is an awful language for nearly any purpose. > Please don't ask me to support any cmd files. > > > Maybe I will rewrite the automation in JScript. > It is a half decent language and works plenty well for command line automation. > It is been "in the OS" for many years, probably at least since Windows 2000, and > with any install of Internet Explorer. > > > But really..you know..all the Python I write...is somewhat of an indictment > of either Modula-3 or myself -- I don't "like" Modula-3 enough to write much > of anything in it.. That is..these "scripts" perhaps should be written in Modula-3. > > > Or maybe actually in Quake? > Quake is kind of limited though. > Maybe with the updates though that Olaf made? > I'll think about it. > > > The system is "easier" to build from a "current" system than from an "older" system. > upgrade.sh and upgrade.py work with either. > If your system is already current, you can just build in dependency order. > If your system is not current, you first build "just the compiler", in dependency > order, but skipping and m3core, libm3. Or you possibly hack them slightly. > (Btw Tony there are few other instances of LONGINT in m3core than the one, but not many.) > > > Most of this confusion is probably only for people that build the system. > As well, maybe it could be reduced by just having an "output root" > like I've said, but I know that'd be disruptive. > > > The archives I upload are not bad. > You just extract them, set $PATH, install Python, get/install a > C compiler and linker and runtime (either Cygwin or Microsoft) and go. > > > I think they are better than the cminstall-based ones. > > > I am not likely to get around to much additional polish. > > > > - Jay > > > > ________________________________ >> Date: Mon, 19 Jan 2009 18:50:40 -0500 >> From: rcoleburn at scires.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] move to version 5.7.1? >> >> >> >> >> >> >> >> Jay et al: >> >> >> >> I have not updated any of my cm3 code base since I released my last application to my customer in late 3Q2008. >> >> >> >> Based on all the activity, I don't think I want to do an update until we've decided to make a new release. This decision should be based primarily on stability of the code base across platforms. >> >> >> >> I can backup my cm3 tree, update to latest code, and run tests on Windows XP using my current apps if that would be helpful. Let me know. Also, I may be able to do some tests on HP-UX if that platform is supported. In addition, I also now have access to a Solaris box. >> >> >> >> One of the things I want to do for the next release is to provide detailed documentation on how to install cm3 on Windows using just the tools that comes with Windows or that are available free from Microsoft. I've already got a good start on this, but will want to get input on the exact order of package builds and which have to be repeated when. >> >> >> >> My idea is that we should have a minimal install archive for Windows (NT386) available from which the "customer" (end-user) can build all of the supported packages in the correct order, including rebuilding the base/core cm3 to prove his system is fully functional. On Windows, the build would be handled via .CMD files and not require python or anything else not supplied with Windows or free from Microsoft. >> >> >> >> I also want "us" to give explicit, documented, definitions of the terms "build", "ship", "clean", "spotless", etc. etc. that are used in various scripts et al and make these consistent. We also need to have good documentation on all the pragmas, environment variables, options, and command line switches that CM3 and CM3IDE recognize. I believe a number of these currently exist that are not well-known or properly documented. >> >> >> >> IMO, this next release needs to be as professional as possible and provide end users (customers) with the best possible experience in terms of ease of installation and use. >> >> >> >> I'll help as much as I can. >> >> >> >> Regards, >> >> Randy Coleburn >> >>>>> Jay 1/19/2009 5:39 PM>>> >> >> Should we move to move version 5.7.1? >> >> To mark the new year, and NT386GNU defaulting to pthreads (I'm thinking I should go back and make it a command line option, it's very very easy). >> >> Just edit two lines in sysinfo.sh and everything keeps working, right? >> >> - Jay From jkrell at elego.de Tue Jan 20 12:57:25 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 12:57:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120115725.81A1910D5DA0@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 12:57:25 Modified files: cm3/m3-libs/m3core/src/runtime/POSIX/: RTProcessPosix.m3 m3makefile cm3/m3-libs/m3core/src/unix/Common/: Uconstants.c m3makefile cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 Added files: cm3/m3-libs/m3core/src/unix/Common/: Utermio.i3 Removed files: cm3/m3-libs/m3core/src/unix/Common/: Uresource.i3 Log message: Remove only Uresource.i3 client, and then Uresource.i3 itself. Add Utermio.i3 so Cygwin can use Posix serial, which does at least compile. There's some chance this would work for other platforms too, at the cost of defining Usysdep.struct_termios and Usysdep.speed_t. For now it is #if __CYGWIN__ in Uconstant.c though. From jkrell at elego.de Tue Jan 20 12:58:15 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 12:58:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120115815.A338610D5DA0@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 12:58:15 Modified files: cm3/m3-comm/serial/src/: m3makefile cm3/m3-comm/serial/src/POSIX/: SerialPort.m3 Log message: Switch some "CONST" to "VAR" to be compatible with constants implemented as constant variables in C. Switch Cygwin to use Posix implementation. It at least compiles and links. From jkrell at elego.de Tue Jan 20 12:59:27 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 12:59:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120115927.3824710D5DA0@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 12:59:27 Modified files: cm3/scripts/python/: pylib.py Log message: The HAVE_SERIAL filtering was still not working..remove the block on Cygwin in favor of..Cygwin has termios.h, maybe it works. From jkrell at elego.de Tue Jan 20 13:37:30 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 13:37:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120123730.E01CF10D5DA0@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 13:37:30 Modified files: cm3/m3-libs/m3core/src/time/POSIX/: DatePosix.m3 m3makefile cm3/m3-libs/m3core/src/unix/solaris-2-x/: Utime.i3 Log message: Switch the "clock" parameters in ctime_r, localtime_r, gmtime_r from long_star requiring an unsafe ADR to READONLY. VAR would also be reasonable, but they are const in C so READONLY slightly better. Might as well switch the output parameter to VAR instead of "star"? (Would be nice to change this code such as to avoid declaring sysdep struct tm..) Switch Cygwin from DateLinux to DatePosix. Note that DateLinux is dead, it is only used by Linux 1.x. DateBsd is the overwhelmingly used one, except Cygwin and Solaris. It corresponds to having gmtoff and zone at the end of struct tm. DatePosix vs. DateLinux uses the "_r" functions instead of a lock. (Where do they store the zone string, in BSD versions?) From jkrell at elego.de Tue Jan 20 14:06:07 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 14:06:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120130608.20EFA2200095@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 14:06:07 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Uconstants.c cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/freebsd-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 Log message: Crack the Modula-3 renaming code: MSETUID <=> S_ISUID MSETGID <=> S_ISGID MSTICKY <=> S_ISVTX Now that I figured that out, make them portable too, and give Cygwin its values (not sure they do anything there; the ISVTX feature is a bit in executable headers, not the file system, and setuid/setgid don't exist as far as I know, but Interix apparently offers it somehow). (See also how Unix.MROWNER == Ustat.S_IREAD == S_IRUSR, if I got those right..) From jkrell at elego.de Tue Jan 20 14:34:57 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 14:34:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120133458.1356910D5C54@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 14:34:57 Modified files: cm3/scripts/: config.c Log message: collect information about mode_t, struct timeval, let use -DCC when building it, and it will use that, cover up annoying gcc warning about -lpthread when only compiling From jkrell at elego.de Tue Jan 20 14:48:50 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 14:48:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120134850.788E310D5C54@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 14:48:50 Modified files: cm3/scripts/: config.c Log message: fix From jkrell at elego.de Tue Jan 20 15:24:18 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 15:24:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120142418.966A710D5C54@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 15:24:18 Modified files: cm3/m3-libs/m3core/src/Csupport/: m3makefile cm3/m3-libs/m3core/src/float/: m3makefile cm3/m3-libs/m3core/src/runtime/: m3makefile cm3/m3-libs/m3core/src/runtime/common/: m3makefile cm3/m3-libs/m3core/src/unix/: m3makefile cm3/m3-libs/m3core/src/unix/Common/: m3makefile Added files: cm3/m3-libs/m3core/src/unix/hpux-common/: Usysdep.i3 m3makefile Log message: Some PA32_HPUX and PA64_HPUX support, work in progress. From jkrell at elego.de Tue Jan 20 20:11:58 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 20:11:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120191158.A9158714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 20:11:58 Modified files: cm3/scripts/python/: pylib.py Log message: root around more for windows.h so I don't have to switch environment From jkrell at elego.de Tue Jan 20 20:17:46 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 20:17:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120191746.D053810D4EAA@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 20:17:46 Modified files: cm3/scripts/: config.c Log message: socklent_t, sigsuspend, always add a particular prefix From jkrell at elego.de Tue Jan 20 20:27:50 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 20:27:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120192750.919D410D4EAA@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 20:27:50 Removed files: cm3/scripts/: config.c Log message: make directory (cvs crashing again for multifile commit From jkrell at elego.de Tue Jan 20 20:28:00 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 20:28:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120192800.A9E0A10D4EAA@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 20:28:00 Added files: cm3/scripts/config/: config.c Log message: make directory (cvs crashing again for multifile commit) From jkrell at elego.de Tue Jan 20 20:42:09 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 20:42:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120194209.8672F714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 20:42:09 Added files: cm3/scripts/config/: mode.c sigsuspend.c time.c Log message: experiment with smaller programs From jkrell at elego.de Tue Jan 20 21:21:55 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 21:21:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120202155.ACE7010D4EAA@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 21:21:55 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile cm3/m3-libs/m3core/src/unix/Common/: m3makefile Added files: cm3/m3-libs/m3core/src/unix/Common/: Uutmp.i3 Removed files: cm3/m3-libs/m3core/src/unix/Uutmp1/: m3makefile Uutmp.i3 Log message: move Uutmp1 to Common From jkrell at elego.de Tue Jan 20 22:04:15 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 22:04:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120210415.333EE714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 22:04:15 Modified files: cm3/scripts/config/: config.c Log message: need to check that which is in common also, not just determine what is sysdep From jkrell at elego.de Tue Jan 20 22:08:36 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 22:08:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120210836.E0491714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 22:08:36 Modified files: cm3/scripts/config/: config.c Log message: should check function signatures too -- ultimately this should probably be output by cm3 rather than tediously maintain parallel content From jkrell at elego.de Tue Jan 20 22:12:03 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 22:12:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120211203.C0BF1714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 22:12:03 Modified files: cm3/scripts/config/: config.c Log message: fix gcc -Wall warnings -- portable and warning-free is difficult From rodney at elego.de Tue Jan 20 22:34:52 2009 From: rodney at elego.de (Rodney M. Bates) Date: Tue, 20 Jan 2009 22:34:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120213452.1CFB8714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: rodney at birch. 09/01/20 22:34:52 Modified files: cm3/m3-sys/m3gdb/gdb/gdb/: m3-util.c Log message: Fix two bugs in accessing open array dope. From jkrell at elego.de Tue Jan 20 22:35:49 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 22:35:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120213549.5A6EB714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 22:35:49 Modified files: cm3/m3-libs/libm3/src/random/: m3makefile Log message: PA32_HPUX, PA64_HPUX From jkrell at elego.de Tue Jan 20 22:37:26 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 22:37:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120213726.7D9F3714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 22:37:26 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: m3makefile SocketPosix.m3 Log message: reduce dependency of libm3 on list of supported platforms -- fewer errors when building new runtime with old compiler; elimination will come later, OSConfigPosix.m3 is the other file that needs work, and fixing it will also make it more optimal, it doesn't need to carry all the strings From jkrell at elego.de Tue Jan 20 22:40:44 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 22:40:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120214044.7D324714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 22:40:44 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: m3makefile Log message: fix incrementality -- don't recompile and relink for every run, only if the file changes From jkrell at elego.de Tue Jan 20 22:57:18 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 22:57:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120215718.60101714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 22:57:18 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: OSConfigPosix.m3 SocketPosix.m3 m3makefile Log message: Elminate the other dependency by libm3 on the list of supported platforms, and namespacify the previous one. m3core still depends on the list. From jkrell at elego.de Tue Jan 20 23:28:20 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 23:28:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120222820.D9AD710D4EAA@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 23:28:20 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Log message: fix get_altzone for Solaris From jkrell at elego.de Tue Jan 20 23:36:46 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 23:36:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120223646.12E0110D5D54@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 23:36:46 Modified files: cm3/scripts/config/: config.c Log message: fix for Solaris From jkrell at elego.de Tue Jan 20 23:47:40 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 23:47:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120224740.6303C10D5F2F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 23:47:40 Added files: cm3/m3-libs/m3core/src/unix/solaris-common/: Usysdep.i3 m3makefile Log message: add first try at Solaris Usysdep, should be double checked (config.c doesn't report MAX_FDSET for example); only checked on 32bit and 64bit SPARC, not x86/AMD64 From jkrell at elego.de Tue Jan 20 23:52:50 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 23:52:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120225250.7B1E0714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 23:52:50 Modified files: cm3/m3-libs/m3core/src/unix/solaris-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/hpux-common/: Usysdep.i3 Log message: fixup imports From jkrell at elego.de Tue Jan 20 23:53:11 2009 From: jkrell at elego.de (Jay Krell) Date: Tue, 20 Jan 2009 23:53:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090120225311.36DD3714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/20 23:53:11 Modified files: cm3/m3-libs/m3core/src/unix/hpux-common/: Usysdep.i3 Log message: fixup imports From jkrell at elego.de Wed Jan 21 16:25:14 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jan 2009 16:25:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090121152514.748DE72575B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/21 16:25:13 Modified files: cm3/m3-libs/m3core/src/runtime/AMD64_DARWIN/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/FreeBSD4/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/I386_DARWIN/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/LINUXLIBC6/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/NT386GNU/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/PPC_DARWIN/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/SOLgnu/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/SOLsun/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/common/: RTMachine.i3 cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 ThreadPThreadC.c ThreadPThreadC.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/freebsd-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/hpux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/solaris-common/: Usysdep.i3 Log message: slightly easier porting wrt SIG_SUSPEND From jkrell at elego.de Wed Jan 21 16:30:44 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jan 2009 16:30:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090121153046.49F5110D5F31@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/21 16:30:44 Modified files: cm3/m3-libs/m3core/src/runtime/FreeBSD4/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/LINUXLIBC6/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/SOLgnu/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/SOLsun/: RTMachine.i3 cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTMachine.i3 Log message: fix warnings by removing IMPORT of Usignal From jkrell at elego.de Wed Jan 21 16:32:59 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jan 2009 16:32:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090121153300.3A56110D5F7B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/21 16:32:59 Modified files: cm3/m3-libs/libm3/src/os/POSIX/: m3makefile Log message: remove a few spaces that make a critical difference -- PPC_LINUX was broken From jkrell at elego.de Wed Jan 21 16:57:55 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jan 2009 16:57:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090121155755.B9DFB10D6394@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/21 16:57:55 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Uconstants.c Log message: missing #includes -- at least Linux and FreeBSD broken From jkrell at elego.de Wed Jan 21 17:13:35 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 21 Jan 2009 17:13:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090121161336.02FFA10D5DA3@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/21 17:13:35 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Uconstants.c Uerror.i3 UtimeC.c Log message: fixes for Solaris: remove const to fix warning, raise Uerror.Max to 151, missing sys/filio.h #include (put it under #ifdef __sun) From jkrell at elego.de Thu Jan 22 01:58:29 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jan 2009 1:58:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090122005829.86FF4744001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/22 01:58:29 Modified files: cm3/scripts/: sysinfo.sh Log message: upgrade version from 5.7.0 to 5.7.1 From jay.krell at cornell.edu Thu Jan 22 02:00:37 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 22 Jan 2009 01:00:37 +0000 Subject: [M3commit] m3commit test.. Message-ID: I'm not seeing m3commit mail any longer. - Jay From jay.krell at cornell.edu Thu Jan 22 02:01:48 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 22 Jan 2009 01:01:48 +0000 Subject: [M3commit] m3commit not working? Message-ID: I'm not seeing m3commit mail. - Jay From jkrell at elego.de Thu Jan 22 02:09:36 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jan 2009 2:09:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090122010950.7ED17714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/22 02:09:36 Modified files: cm3/scripts/python/: pylib.py Log message: test m3commit; seems maybe working now From jay.krell at cornell.edu Thu Jan 22 02:30:07 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 22 Jan 2009 01:30:07 +0000 Subject: [M3commit] [M3devel] m3commit not working? (now working) In-Reply-To: References: Message-ID: sorry, nevermind, I see it now. A few were skipped though, like upping the version from 5.7.0 to 5.7.1, fixes for Solaris, Linux, FreeBSD though I think only in inactive files or less active platforms, not sure (i.e. Uconstants.c errors not active, UtimeC.c was only a warning, though it was also broken on Solaris a few days wrt altzone). They are in the archives on the web page. e.g.: http://mail.elegosoft.com/pipermail/m3commit/2009-January/002618.html http://mail.elegosoft.com/pipermail/m3commit/2009-January/002618.html http://mail.elegosoft.com/pipermail/m3commit/2009-January/002617.html http://mail.elegosoft.com/pipermail/m3commit/2009-January/002616.html - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3commit at elegosoft.com; m3devel at elegosoft.com > Date: Thu, 22 Jan 2009 01:01:48 +0000 > Subject: [M3devel] m3commit not working? > > > I'm not seeing m3commit mail. > > - Jay From jay.krell at cornell.edu Thu Jan 22 02:36:14 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 22 Jan 2009 01:36:14 +0000 Subject: [M3commit] [M3devel] m3commit not working? (now working) In-Reply-To: References: Message-ID: er, I see mail I send directly, but I think still not checkins. sorry for confusion... - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3commit at elegosoft.com; m3devel at elegosoft.com > Subject: RE: [M3devel] m3commit not working? (now working) > Date: Thu, 22 Jan 2009 01:30:07 +0000 > > > sorry, nevermind, I see it now. A few were skipped though, like upping the version from 5.7.0 to 5.7.1, fixes for Solaris, Linux, FreeBSD though I think only in inactive files or less active platforms, not sure (i.e. Uconstants.c errors not active, UtimeC.c was only a warning, though it was also broken on Solaris a few days wrt altzone). They are in the archives on the web page. > > e.g.: > http://mail.elegosoft.com/pipermail/m3commit/2009-January/002618.html > http://mail.elegosoft.com/pipermail/m3commit/2009-January/002618.html > http://mail.elegosoft.com/pipermail/m3commit/2009-January/002617.html > http://mail.elegosoft.com/pipermail/m3commit/2009-January/002616.html > > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3commit at elegosoft.com; m3devel at elegosoft.com >> Date: Thu, 22 Jan 2009 01:01:48 +0000 >> Subject: [M3devel] m3commit not working? >> >> >> I'm not seeing m3commit mail. >> >> - Jay From jkrell at elego.de Thu Jan 22 03:01:41 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jan 2009 3:01:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090122020141.3119810D5A74@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/22 03:01:41 Modified files: cm3/scripts/python/: pylib.py Log message: test m3commit From jkrell at elego.de Thu Jan 22 15:21:10 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jan 2009 15:21:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090122142110.45A5010D49FC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/22 15:21:10 Modified files: cm3/scripts/config/: config.c Log message: print some maxpath stuff, print about fd_set, fix for platforms that do have sockaddr_in.len From jkrell at elego.de Thu Jan 22 15:23:24 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jan 2009 15:23:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090122142324.B206810D49FC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/22 15:23:24 Added files: cm3/m3-libs/m3core/src/unix/darwin-common/: Usysdep.i3 m3makefile Log message: initial Darwin version, based only on 32bit PowerPC From jkrell at elego.de Thu Jan 22 16:20:58 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 22 Jan 2009 16:20:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090122152058.5EFE1714180@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/22 16:20:58 Modified files: cm3/scripts/: lzma.sh Log message: gzcat is much more portably gzip than zcat is (Darwin, Solaris) From jkrell at elego.de Sun Jan 25 17:36:15 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 25 Jan 2009 17:36:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090125163615.DABA3904003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/25 17:36:15 Modified files: cm3/m3-sys/windowsResources/src/: winRes.tmpl Log message: Surely there is no need to run cvtres manually. Not doing so works with a few toolsets I have tried. The linker accepts .res files and it is normal to give them to it. The invocation here is incompatible with very old toolsets (Visual C++ 2.0) and a minor porting nuisance due to the use of /machine:x86. The only savings I can imagine is if some resources are used "like a library" and linked into multiple binaries, that invocations of cvtres can be reduced, from once per link to just once. From jkrell at elego.de Sun Jan 25 17:57:41 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 25 Jan 2009 17:57:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090125165741.91110904003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/25 17:57:41 Modified files: cm3/scripts/python/: pylib.py Log message: m3commit test From jkrell at elego.de Sun Jan 25 19:30:27 2009 From: jkrell at elego.de (Jay Krell) Date: Sun, 25 Jan 2009 19:30:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090125183028.1799810D6357@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/25 19:30:27 Modified files: cm3/m3-tools/uniq/src/: Main.m3 Log message: Fix the problem where the Modula-3 implementation of uniq.exe causes building gcc to hang if it is first in %PATH%. The problem is that building gcc invokes uniq with a file path on the command line, rather than feeding it stdin. Modula-3 uniq.exe only was expecting stdin and hangs reading from it and getting nothing. From jkrell at elego.de Mon Jan 26 10:57:32 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jan 2009 10:57:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090126095732.B29E610D63BB@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/26 10:57:32 Modified files: cm3/m3-sys/windowsResources/src/: winRes.tmpl Log message: go ahead and remove the unnecessary stuff, rather than just comment it out From jkrell at elego.de Mon Jan 26 13:36:15 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jan 2009 13:36:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090126123615.73B1B10D6491@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/26 13:36:15 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RT0.i3 Log message: fix comment to refer to correct interface, since the interface doesn't actually exist (the fiel does, but it isn't built) From jkrell at elego.de Mon Jan 26 13:38:12 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jan 2009 13:38:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090126123812.C7F4B10D63BC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/26 13:38:12 Modified files: cm3/m3-libs/m3core/src/runtime/FreeBSD/: m3makefile Removed files: cm3/m3-libs/m3core/src/runtime/FreeBSD/: DEFS.h RTStackASM.s Log message: remove unused files, esp. in obsolete target From jkrell at elego.de Mon Jan 26 13:39:20 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jan 2009 13:39:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090126123920.05B9910D63BC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/26 13:39:20 Removed files: cm3/m3-libs/m3core/src/runtime/FreeBSD2/: DEFS.h RTStackASM.s Log message: remove unused files, esp. in obsolete targets From jkrell at elego.de Mon Jan 26 13:41:29 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jan 2009 13:41:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090126124129.0A04B10D63BC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/26 13:41:29 Removed files: cm3/m3-libs/m3core/src/runtime/FreeBSD3/: RTStackASM.s Log message: remove unused file, esp. from obsolete targets From jkrell at elego.de Mon Jan 26 13:42:51 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jan 2009 13:42:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090126124251.C4F8A10D63BC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/26 13:42:51 Removed files: cm3/m3-libs/m3core/src/runtime/FreeBSD4/: RTStackASM.s Log message: remove unused file From jkrell at elego.de Mon Jan 26 13:43:47 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jan 2009 13:43:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090126124347.3E19A10D63BC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/26 13:43:47 Removed files: cm3/m3-libs/m3core/src/runtime/LINUXLIBC6/: RTStackASM.s Log message: remove unused file From jkrell at elego.de Mon Jan 26 13:44:56 2009 From: jkrell at elego.de (Jay Krell) Date: Mon, 26 Jan 2009 13:44:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090126124456.E46CA10D63BC@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/26 13:44:56 Removed files: cm3/m3-libs/m3core/src/runtime/LINUX/: RTStackASM.s Log message: remove unused file, in obsolete Linux 1.x a.out target From jkrell at elego.de Wed Jan 28 00:28:42 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 0:28:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090127232842.99F2310D63C2@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 00:28:42 Removed files: cm3/m3-libs/m3core/src/runtime/I386_DARWIN/: RTStackASM.s _fpsetjmp.s Log message: delete unused files From jkrell at elego.de Wed Jan 28 00:29:48 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 0:29:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090127232948.7195910D63C2@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 00:29:48 Removed files: cm3/m3-libs/m3core/src/runtime/LINUXELF/: RTStackASM.s Log message: remove unused file, in obsolete target From jkrell at elego.de Wed Jan 28 00:30:59 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 0:30:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090127233102.782A7744006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 00:30:59 Modified files: cm3/m3-libs/m3core/src/runtime/OS2/: m3makefile Removed files: cm3/m3-libs/m3core/src/runtime/OS2/: RTStackASM.s Log message: remove unused file From jkrell at elego.de Wed Jan 28 00:32:34 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 0:32:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090127233234.B08F9F04006@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 00:32:34 Modified files: cm3/m3-libs/m3core/src/runtime/NetBSD2_i386/: m3makefile Log message: remove remnants of unused file From jkrell at elego.de Wed Jan 28 00:36:57 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 0:36:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090127233657.3532210D63C5@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 00:36:57 Removed files: cm3/m3-libs/m3core/src/runtime/SOLsun/: RTStackASM.s.sav RTStackASM.s Log message: remove unused files From jkrell at elego.de Wed Jan 28 00:37:51 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 0:37:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090127233751.9414710D63C5@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 00:37:51 Removed files: cm3/m3-libs/m3core/src/runtime/SOLgnu/: RTStackASM.s Log message: remove unused file From jkrell at elego.de Wed Jan 28 16:23:53 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 16:23:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090128152353.9BDDF714575@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 16:23:53 Modified files: cm3/m3-libs/m3core/src/runtime/IBMR2/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/LINUXLIBC6/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/SOLgnu/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/SOLsun/: RTThread.m3 Log message: gratuitous formating difference From jkrell at elego.de Wed Jan 28 16:47:15 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 16:47:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090128154716.3138F1704004@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 16:47:15 Modified files: cm3/m3-libs/m3core/src/runtime/FreeBSD4/: RTSignal.m3 Log message: eliminate gratuitous platform specific diff -- change local variable 'dummy' to 'old From jkrell at elego.de Wed Jan 28 16:49:46 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 16:49:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090128154952.A2A8F220001A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 16:49:46 Modified files: cm3/m3-libs/m3core/src/runtime/ALPHA_OSF/: RTThread.m3 Log message: eliminate gratuitous formating difference, missed this before From jkrell at elego.de Wed Jan 28 16:52:56 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 16:52:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090128155256.C58E8220001A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 16:52:56 Modified files: cm3/m3-libs/m3core/src/runtime/ALPHA_OSF/: RTSignal.m3 cm3/m3-libs/m3core/src/runtime/AMD64_DARWIN/: RTSignal.m3 cm3/m3-libs/m3core/src/runtime/FreeBSD4/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/I386_DARWIN/: RTSignal.m3 cm3/m3-libs/m3core/src/runtime/LINUXLIBC6/: RTSignal.m3 cm3/m3-libs/m3core/src/runtime/NetBSD2_i386/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/PPC_DARWIN/: RTSignal.m3 cm3/m3-libs/m3core/src/runtime/SOLgnu/: RTSignal.m3 cm3/m3-libs/m3core/src/runtime/SOLsun/: RTSignal.m3 Log message: eliminate gratuitous whitespace diff between platforms before: <*ASSERT i = 0*> after: <* ASSERT i = 0 *> From jkrell at elego.de Wed Jan 28 17:21:19 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 17:21:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090128162119.7294D10D5ECB@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 17:21:19 Modified files: cm3/m3-libs/m3core/src/runtime/AMD64_DARWIN/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/I386_DARWIN/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/LINUXLIBC6/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/PPC_DARWIN/: RTThread.m3 Log message: eliminate more gratuitous platform specific diffs These platforms were doing FROM Usignal IMPORT sigaction, sigprocmask, etc. whereas other platforms just IMPORT Usignal; and then reference qualified Usignal.sigaction, etc. From jkrell at elego.de Wed Jan 28 18:44:42 2009 From: jkrell at elego.de (Jay Krell) Date: Wed, 28 Jan 2009 18:44:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090128174442.D2AD210D63A2@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/28 18:44:42 Modified files: cm3/m3-libs/m3core/src/runtime/ALPHA_OSF/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/AMD64_DARWIN/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/FreeBSD4/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/I386_DARWIN/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/LINUXLIBC6/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/NetBSD2_i386/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/PPC_DARWIN/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/SOLgnu/: RTThread.m3 cm3/m3-libs/m3core/src/runtime/SOLsun/: RTThread.m3 Log message: eliminate more gratuitous platform differences Some platforms uses + to combine mprotect protections, some used Word.Or. Use + because it is terser, assuming these are all independent flags. Some platforms used WITH i = foo; ASSERT(i = 0); Some used VAR i := foo; ASSERT(i = 0); Use VAR, in order to elminate indentation. some platforms said IF (page_size = 0) and some said IF page_size = 0. Use the second shorter form. This code kinda looks like it has a race condition, but probably not, since it is the code that is involved in creating threads, there cannot be multiple threads until after it runs. Platforms still vary as to what protections they use on the last stack page. From jkrell at elego.de Thu Jan 29 08:43:23 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 29 Jan 2009 8:43:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090129074323.C5F4010D6493@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/29 08:43:23 Modified files: cm3/m3-libs/m3core/src/unix/darwin-common/: Usysdep.i3 Log message: add missing semicolons; this code is not yet active From jkrell at elego.de Thu Jan 29 18:07:09 2009 From: jkrell at elego.de (Jay Krell) Date: Thu, 29 Jan 2009 18:07:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090129170709.CBB9110D5F23@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/29 18:07:09 Modified files: cm3/scripts/config/: config.c Log message: Cygwin's setjmp.h reports the wrong size for jmp_buf; detect and report that. From jkrell at elego.de Fri Jan 30 04:25:37 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 30 Jan 2009 4:25:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090130032538.030B410D5DAA@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/30 04:25:37 Added files: cm3/m3-libs/m3core/src/context/: context.c context.h tcontext.c Log message: highly non-portable working version of set/get/make/swapcontext for NT386; should assist in providing e.g. Cygwin, OpenBSD/x86, and perhaps non-x86, though again, it is highly system specific, and inline assembly syntax is very different between Visual C++ and gcc From jkrell at elego.de Fri Jan 30 16:26:42 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 30 Jan 2009 16:26:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090130152642.30B8F71457D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/30 16:26:42 Modified files: cm3/m3-libs/m3core/src/context/: context.c context.h tcontext.c Log message: fix newlines From jkrell at elego.de Fri Jan 30 16:28:35 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 30 Jan 2009 16:28:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090130152835.E94DC10D5A8D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/30 16:28:35 Modified files: cm3/m3-libs/m3core/src/context/: context.c context.h Log message: use pushad/popad, and keep registers as all size_t, only change the type of esp for convenience via a local; note that real NT386/Cygwin usermode threads should use Win32 fibers, this is just a prototype that maybe could be applied to OpenBSD/x86 and proof of concept of how difficult/possible the context APIs are to implement -- very difficult actually, just that x86 is familiar From jkrell at elego.de Fri Jan 30 16:35:57 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 30 Jan 2009 16:35:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090130153557.C9A0771457E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/30 16:35:57 Modified files: cm3/m3-libs/m3core/src/unix/linux-64/: m3makefile Removed files: cm3/m3-libs/m3core/src/unix/linux-64/: Uucontext.i3 Log message: should fix AMD64_LINUX and SPARC64_LINUX -- no need for Uucontext.i3 here, just use the common one From jkrell at elego.de Fri Jan 30 20:06:51 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 30 Jan 2009 20:06:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090130190651.EDAF2744002@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/30 20:06:51 Modified files: cm3/m3-libs/m3core/src/context/: tcontext.c Added files: cm3/m3-libs/m3core/src/context/winfiber/: context.c context.h cm3/m3-libs/m3core/src/context/x86msvc/: context.c context.h readme.txt Removed files: cm3/m3-libs/m3core/src/context/: context.c context.h Log message: A more realistic implementation of *context portable to all Windows platforms by using fibers. Move previous to "x86msvc". From jkrell at elego.de Fri Jan 30 23:16:58 2009 From: jkrell at elego.de (Jay Krell) Date: Fri, 30 Jan 2009 23:16:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090130221658.B4A8B744002@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/30 23:16:58 Added files: cm3/m3-libs/m3core/src/context/x86/: Makefile context.c context.h contextasm.s Log message: works on OpenBSD/x86, neat From jkrell at elego.de Sat Jan 31 00:10:47 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jan 2009 0:10:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090130231047.2354410D63AB@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/31 00:10:47 Modified files: cm3/m3-libs/m3core/src/context/x86/: Makefile context.c contextasm.s Log message: adapt to Cygwin -- which uses coff, so symbols with underscores, and different validity/meaning of .type and .size; and its make doesn't understand $> From jkrell at elego.de Sat Jan 31 00:14:13 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jan 2009 0:14:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090130231413.2086710D63AB@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/31 00:14:13 Modified files: cm3/m3-libs/m3core/src/context/x86/: Makefile contextasm.s Log message: finish adapting to Cygwin and quash make clean output From jkrell at elego.de Sat Jan 31 05:25:43 2009 From: jkrell at elego.de (Jay Krell) Date: Sat, 31 Jan 2009 5:25:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20090131042543.ED60710D5F16@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 09/01/31 05:25:43 Modified files: cm3/m3-libs/m3core/src/context/: tcontext.c cm3/m3-libs/m3core/src/context/x86/: Makefile Log message: preemptive version works on OpenBSD/x86