From hendrik at topoi.pooq.com Thu Jan 1 11:25:35 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 1 Jan 2009 05:25:35 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <495B4846.1E75.00D7.1@scires.com> References: <20081231105208.9CF4710D5DDE@birch.elegosoft.com> <495B4846.1E75.00D7.1@scires.com> Message-ID: <20090101102535.GB20605@topoi.pooq.com> On Wed, Dec 31, 2008 at 10:28:37AM -0500, Randy Coleburn wrote: > > On another note, All this CYGWIN stuff may be a nice way for die-hard > Unix fans to run Modula-3 on Windows, and I have no objection to > providing it, as long as it does not compromise the native Windows > implementation. It is useful to have a way to take Modula 3 programs from Unix to Windows with minimal change. That said, Modula-3 is a system programming language, and it should be possible to program in a system-dependent way. Do we need two Windows platforms, one native and one to run on a Unix-compatibility layer? And while we're at it, do we need two Unix platforms, one native and one that runs via Wine? > My main concern is the native implementation of > Modula-3 on Windows. My preference would be to keep the NT386 > implementation's dependencies on other stuff to a bare minimum, i.e., > don't introduce anything that would require someone to have to acquire > something besides what comes in the standard Windows OS in order to > make Modula-3 run. As it is now, we already have to get a C compiler > and linker. Fortunately, Microsoft has made the Visual Studio Express > editions a free download, so this is not too bad. Except that the free download won't work on old versions of Windows. This is the main reason why I have been unable in the past to use Modula 3 on Windows. At the moment, though, an overriding reason is that I have no Windows machines available. > I don't want to have to install CYGWIN either in order to make the > native implementation work on Windows. I also still prefer the > CMINSTALL, CMD, or BAT files for install as opposed to having to get > Python or something else. Just my 2 cents. > > Finally, I would go a step further and suggest that the Modula-3 > implementation on every platform should strive to require minimal > dependencies on anything not provided standard with that platform's > operating system. > > Call me an idealist, but it just galls me that I have to have a C > compiler/linker to build Modula-3. Modula-3 is a systems programming > language. It should stand on its own. It is not hard to write a linker in Modula-3. > From a purely economical > viewpoint, why should I have to buy something I don't want (C language > development environment) in order to have the privilege of using what > I do want (Modula-3 language development environment). What's hard is making it compatible with existing proprietary linkers and loaders that are poorly documented and subject to change without notice. > > Regards, > Randy -- hendrik From hendrik at topoi.pooq.com Thu Jan 1 15:20:48 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 1 Jan 2009 09:20:48 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <495B6B87.1E75.00D7.1@scires.com> References: <20081231105208.9CF4710D5DDE@birch.elegosoft.com> <495B4846.1E75.00D7.1@scires.com> <20090101102535.GB20605@topoi.pooq.com> <495B6B87.1E75.00D7.1@scires.com> Message-ID: <20090101142047.GA21146@topoi.pooq.com> On Wed, Dec 31, 2008 at 12:59:03PM -0500, Randy Coleburn wrote: > Hendrik: > > I agree it is useful for those accustomed to Unix to be able to work > in the Cygwin environment on Windows. I have no issue with supporting > this. Yes. But it's not what's really needed for most users of Windows machines. I was using another Unix on Windows system, M-SYS. There's a conceptual gap between M-SYS and Windows (that's the whole point, isn't it?) that brings on headaches. Windows programming should be done in Windows. > I assert that it is also very useful for non-Unix, Windows folks to be > able to work with Modula-3 in Windows without needing to know anything > about Unix, or using any Unix tools to make Modula-3 work. (BTW, I > work in both the Unix and Windows worlds, but primarily in the Windows > world lately.) Yes. Exactly. > > So yes, I suppose we do need both the native Windows and > Unix-compatibility implementations for Modula-3 on Windows. However, > I think it important to support Modula-3 natively on all platforms > rather than *requiring* a compatibility-implementation. Yes. > Thus, I would > always vote for having a native implementation first, then add a > compatibility one later, if desired. So, from my vantage point (and > others may disagree), the native Windows implementation of Modula-3 is > the number one priority on the Windows platform. Cygwin is a > "nice-to-have" for the Unix crowd, but not essential. I was trying to use Modula-3 on Windows in the days that it required a nongratis Microsoft linker, and some nongratis Microsoft linkers were reported not to be compatible. No one could guarantee that any currently available commercial linker was compatible with Modula-3. I wasn't prepared to pay for a system that had significant risk of being useless. > I don't know much about Wine, so won't comment on it. It's the Windows API implemented according to spec. And hacked up so that it is actually somewhat compatible with Windows. It could be useful to test any Windows versions of Modula-3 to see if they run under Wine. In the past quite a few programmers have discovered it's easier to debug Windows programs under Wine than under Windows, because the underlying OS doesn't crash. I don't know whether this is still the case. > > As for taking your Modula-3 programs that run on one platform, and > building and running them on other platforms, I think this is one of > the best features of Modula-3. And this is what I really wanted. > I routinely do this. Indeed, I've > tried very hard to make it possible for all my programs to be both > buildable and runable on both Unix and Windows platforms without the > need for source code modification. I've also tried to make them > interoperable across platforms, e.g. clients on one platform type, > servers on another, etc. Network Objects and Pickles have been my > friends here. > > As for the free Visual Studio stuff not working on old versions of > Windows, well yes that is a problem for those old platforms, but then, > they are old and Microsoft has dropped support for them long ago and > continuing to support them both from a hardware and software > standpoint is going to get more problematic as time goes on. It's > like my 13-year old car--the last time I had it repaired the shop had > to put out a nationwide search for the parts. I too have a 13-year-old car. The dealer used to maintain it. I switched to my local general mechanic when the dealer could no longer find replacement parts. For some reason the local mechanic has no such problem. > At some point, I'll > have to give it up. Me, too. I've been wondering whether the effort of digging it out of the snow every week or so is worth it during the winter. > > I believe you can use some old versions of Microsoft Visual C (e.g., > v6) for these old platforms, but those were not free. I recall having > to buy Microsoft C v6 when I bought CMass Reactor v4.1 many years ago. > The v6 C was pretty common, so you can probably find it around > somewhere today on the used market. Indeed, I still have my v6 C > disks. > > If you or someone else wants to build a linker for Modula-3 on > Windows, that's fine with me. Until then, we are stuck with what we > have--a free download of Visual Studio. > > As for going forward, I believe we should strive to support current > and future platforms more than working to add support for old ones. > Of course, as we move forward, it would be nice to try to maintain > support for platforms as they age, but not at the expense of > supporting newer stuff. I agree, especially since we are talking now about providing a level of support for the old system that was never available in those old days. Anyone with a Windows 95 machine that ran Modula-3 can presumably still use the system he had back then, using the linker he had back then. > This reasoning is based on trying to keep the > language alive, useful, and attractive to new programmers. If we live > in the past, Modula-3 will wither away as the current crop of > enthusiasts age and pass on. I agree. I remember a long time ago tinkering with an OS/2 port of Modula 3. I had the source for the DOS version to start with. I didn't have the time or resources to do anything serious on it though, and someone else did. I wonder what we used for a linker back in those days? > All that said, let me ask this question: Would it be useful to anyone > if I tried to put together a binary distribution of Modula-3 for the > WindowsNT 4.0 (circa 1996) platform? Not for me. Not now. I no longer use Windows. The one machine I have that used to run Windows no longer runs Windows in anything but maintenance mode (though it runs Linux with no trouble at all). What might be useful to me is an ability to cross-compile a Windows executable from a Linux machine, so I could ship the result to a non-programmer Windows user. That would probably require a lot of infrastructure work, and may not be worth it. It may be easier to buy a new Windows machine if I need that. And download the free linker, which I hope still runs on XP as well as Vista. > > I still have one of those old beasts and it does still work. I think I have one in the basement, too. I got it at a garage sale, and have never had occasion to use it. It boots, but I have user or admin password for it it. I am aware of techniques to crack the password, but the machine is probably too slow to be of much use now. -- hendrik From hosking at cs.purdue.edu Thu Jan 1 02:34:09 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 1 Jan 2009 12:34:09 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20081231105208.9CF4710D5DDE@birch.elegosoft.com> <495B4846.1E75.00D7.1@scires.com> <495B901F.1E75.00D7.1@scires.com> Message-ID: <1A450527-2CB6-41CF-982F-DA49C20EA686@cs.purdue.edu> My bandwidth is limited right now so I am unable to follow the discussion closely. But, I am uneasy with some of what I am hearing and would like to have someone provide a succinct summary of the debates. I hope that Randy, Jay, and Mika can perhaps do this. From hosking at cs.purdue.edu Thu Jan 1 02:29:24 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 1 Jan 2009 12:29:24 +1100 Subject: [M3devel] variations of waitpid..? In-Reply-To: References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> Message-ID: If someone uses waitpid they get what they paid for. On 1 Jan 2009, at 06:24, Jay wrote: > > You mean, this function is easy to misuse? >> People who declare their own <*EXTERNAL*> > Like waitpid exposed from m3core? > > waitpid is already easy to misuse, on a userthread system, leading > to possible (though I think rare) deadlock. > It is easy to misuse on pthreads, lead "just" to bad performance, > and in fact I believe cm3 is doing this, via sysutils. > This at least guides you between two patterns of use, and fix the > perf of cm3/sysutils. > > On a userthread system, waitpid(pid, flags = 0) waits for the child > process, with all parent threads suspended. > Generally I doubt the child depends on parent threads progressing, > but, yeah, that could deadlock, like if a parent thread is waiting > to a file or stdin of the child, or reading a child's stdout. > > The various uses do waitpid(pid, flags = nohang) and then sleep and > try again. > > pthreads just uses waitpid(pid, flags = 0) and all threads keep > running From jay.krell at cornell.edu Thu Jan 1 02:49:28 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 1 Jan 2009 01:49:28 +0000 Subject: [M3devel] variations of waitpid..? In-Reply-To: References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> Message-ID: > If someone uses waitpid they get what they paid for. But someone is us -- m3core/libm3 (I think just m3core), sysutils, and then cm3 uses them. I guess there is a point that this "grand new interface" SchedulerPosix.DoesWaitPidYield has precious few users. (It isn't grand. It takes no parameters and just returns a boolean, hardcoded, depending on thread library.) m3core now (today) uses it internally -- no need for a public interface. Sysutils can't use it until the baseline m3core is newer, so arguably, not a user. Instead (today) sysutils uses m3core's m3makefiles to decide the value. Heck, waitpid is therefore only used internally by m3core, and sysutils. If sysutils could be (partly) merged into m3core, then m3core's waitpid need not be public. - Jay> CC: mika> From: hosking> To: jay> Subject: Re: [M3devel] variations of waitpid..?> Date: Thu, 1 Jan 2009 12:29:24 +1100> > If someone uses waitpid they get what they paid for. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 1 02:59:50 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 1 Jan 2009 01:59:50 +0000 Subject: [M3devel] FW: variations of waitpid..? In-Reply-To: References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> Message-ID: [truncated just slightly..and probably will be again given more rambling..] ps: the internal use in m3core could be easily removed, just by compiling one branch of the if or the other. I just wanted them in the same file to keep similar code closer together. So it comes down that m3core does expose Uwaitpid.waitpid and Uexec.waitpid, and as long as they are...or as long as user threads exist..imho there is some obligation of m3core to expose perhaps surprising characteristics of its thread library. You might say the entire interface is already and has always been fully exposed in Thread.i3, but I don't believe it. User threads and kernel threads have too divergent too visible artifacts, that I don't think are previously exposed in the public interface. I claim it is somewhat "surprising", or at least important to know the detail of, whether or not waitpid yields to other threads. You know, I mean..let's say I am some really clever waitpid user and I really must use it. And I am using Modula-3 threads. And my child process is reading the output of Modula-3 threads. Aren't I kind of stuck? Isn't there /some/ obligation of m3core to help just a teeny tiny bit? Or, would you argue, I am obligated, if I am using Modula-3, to use the higher level interfaces, that already know about this? Well, ok, m3core did already know about, I fixed it only a few months ago, but then even the likes of sysutils is stuck? Another example, that may or may not be well exposed, is willingness/ability to set thread stack size. Mika mentions creation thousands of threads. 32bit kernel threads are going to be more limited here. Whereas 32bit user threads might be willing to create much smaller stacks, and 64 bit anything has essentially infinite address space for infinite stacks (but still beware working set, physical memory is not infinite). (Personally I have seen precious little code that cares about stack size, just seems to somehow get along, combined with the fact that the current Modula-3 pthread code very likely leaks on some platforms attempting to deal with stack size, makes me inclined to just rip out the code..but yeah..just fix the leak...) - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: mika at async.caltech.edu; m3devel at elegosoft.comSubject: RE: [M3devel] variations of waitpid..?Date: Thu, 1 Jan 2009 01:49:28 +0000 > If someone uses waitpid they get what they paid for. But someone is us -- m3core/libm3 (I think just m3core), sysutils, and then cm3 uses them. I guess there is a point that this "grand new interface" SchedulerPosix.DoesWaitPidYield has precious few users. (It isn't grand. It takes no parameters and just returns a boolean, hardcoded, depending on thread library.) m3core now (today) uses it internally -- no need for a public interface.Sysutils can't use it until the baseline m3core is newer, so arguably, not a user. Instead (today) sysutils uses m3core's m3makefiles to decide the value. Heck, waitpid is therefore only used internally by m3core, and sysutils.If sysutils could be (partly) merged into m3core, then m3core's waitpid need not be public. - Jay> CC: mika> From: hosking> To: jay> Subject: Re: [M3devel] variations of waitpid..?> Date: Thu, 1 Jan 2009 12:29:24 +1100> > If someone uses waitpid they get what they paid for. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.illig at gmx.de Thu Jan 1 05:18:47 2009 From: roland.illig at gmx.de (Roland Illig) Date: Thu, 01 Jan 2009 05:18:47 +0100 Subject: [M3devel] Is Modula-3 available on x86_64-unknown-linux-gnu? In-Reply-To: References: <495B4A7B.6010505@gmx.de> Message-ID: <495C4427.4090106@gmx.de> Jay schrieb: > In your config file, make sure to put -m32 on the cm3cg invocation, and > perhaps -32 or --32 on the as/gas invocation. They may or may not help. Thanks for the suggestion. I tried it (SYSTEM_CC="gcc -m32", SYSTEM_ASM="as --32"), and the program builds fine now. When running it, I get the following: Program received signal SIGSEGV, Segmentation fault. 0xdc1ca000 in ?? () (gdb) where #0 0xdc1ca000 in ?? () #1 0xf75dee30 in RTThread__FlushStackCache () at RTThread.m3:65 #2 0xf75e49ce in ThreadPosix__DetermineContext (M3_AJWxb1_oldSP=0xffb59250) at ThreadPosix.m3:1101 #3 0xf75e4932 in ThreadPosix__InitTopContext (M3_A8sSUp_c=0xf73b203c, M3_AJWxb1_stackbase=0xffb5935c) at ThreadPosix.m3:1076 #4 0xf75e5fe5 in ThreadF__Init () at ThreadPosix.m3:1498 #5 0xf75cdfcd in RTLinker__InitRuntime (M3_AcxOUs_p_argc=1, M3_AJWxb1_p_argv=0xffb59424, M3_AJWxb1_p_envp=0xffb5942c, M3_AJWxb1_p_instance=0x0) at RTLinker.m3:59 #6 0x08048901 in main (argc=1, argv=0xffb59424, envp=0xffb5942c) at _m3main.mc:3 The address 0xdc1ca000 does not appear in /proc/self/maps, so I don't know where to look further. Roland From jay.krell at cornell.edu Thu Jan 1 09:51:00 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 1 Jan 2009 08:51:00 +0000 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: <20081230021646.GA8558@jack.stsp.name> References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> Message-ID: Stefan, Please try http://modula3.elegosoft.com/cm3/uploaded-archives/. There are std and min archives there now. I haven't yet run X or tests, but the system is self hosting -- it builds itself. Let us know how it goes. Thanks, - Jay > Date: Tue, 30 Dec 2008 03:16:46 +0100> From: stefan> To: jay> CC: m3devel> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > On Mon, Dec 29, 2008 at 09:33:44PM +0000, Jay Krell wrote:> > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 08/12/29 21:33:44> > Hey Jay,> > > Log message:> > enough I386_OPENBSD support to build a bootstrap package,> > that builds on the target, and results in a cm3 that> > runs and correct errors out for lack of cm3.cfg,> > Cool, I'd like to play with this, once you have a bootstrap binary.> > Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 1 09:57:45 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 1 Jan 2009 08:57:45 +0000 Subject: [M3devel] Is Modula-3 available on x86_64-unknown-linux-gnu? In-Reply-To: <495C4427.4090106@gmx.de> References: <495B4A7B.6010505@gmx.de> <495C4427.4090106@gmx.de> Message-ID: Roland, You are using user threads. I can tell from the functions on the stack. >From what I read on this list, I gather user threads are broken on Linux due to "jumpbuf scrambling". (besides the problem I reported, which isn't in very old builds) Can you please try a newer build? ie: one that uses pthreads? > SYSTEM_CC="gcc -m32", I forgot to mention that one but yeah. :) You are using a very old build, right? - Jay> Date: Thu, 1 Jan 2009 05:18:47 +0100> From: roland> To: m3devel> Subject: Re: [M3devel] Is Modula-3 available on x86_64-unknown-linux-gnu?> > Jay schrieb:> > In your config file, make sure to put -m32 on the cm3cg invocation, and> > perhaps -32 or --32 on the as/gas invocation. They may or may not help.> > Thanks for the suggestion. I tried it (SYSTEM_CC="gcc -m32",> SYSTEM_ASM="as --32"), and the program builds fine now. When running it,> I get the following:> > Program received signal SIGSEGV, Segmentation fault.> 0xdc1ca000 in ?? ()> (gdb) where> #0 0xdc1ca000 in ?? ()> #1 0xf75dee30 in RTThread__FlushStackCache () at RTThread.m3:65> #2 0xf75e49ce in ThreadPosix__DetermineContext> (M3_AJWxb1_oldSP=0xffb59250) at ThreadPosix.m3:1101> #3 0xf75e4932 in ThreadPosix__InitTopContext (M3_A8sSUp_c=0xf73b203c,> M3_AJWxb1_stackbase=0xffb5935c) at ThreadPosix.m3:1076> #4 0xf75e5fe5 in ThreadF__Init () at ThreadPosix.m3:1498> #5 0xf75cdfcd in RTLinker__InitRuntime (M3_AcxOUs_p_argc=1,> M3_AJWxb1_p_argv=0xffb59424, M3_AJWxb1_p_envp=0xffb5942c,> M3_AJWxb1_p_instance=0x0) at RTLinker.m3:59> #6 0x08048901 in main (argc=1, argv=0xffb59424, envp=0xffb5942c)> at _m3main.mc:3> > The address 0xdc1ca000 does not appear in /proc/self/maps, so I don't> know where to look further.> > Roland -------------- next part -------------- An HTML attachment was scrubbed... URL: From stsp at elego.de Thu Jan 1 12:41:39 2009 From: stsp at elego.de (Stefan Sperling) Date: Thu, 1 Jan 2009 12:41:39 +0100 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> Message-ID: <20090101114139.GC10003@jack.stsp.name> On Thu, Jan 01, 2009 at 08:51:00AM +0000, Jay wrote: > > Stefan, Please try > [1]http://modula3.elegosoft.com/cm3/uploaded-archives/. > There are std and min archives there now. > I haven't yet run X or tests, but the system is self hosting -- it > builds itself. > Let us know how it goes. Where are the bootstrap binaries? Stefan From roland.illig at gmx.de Thu Jan 1 13:19:36 2009 From: roland.illig at gmx.de (Roland Illig) Date: Thu, 01 Jan 2009 13:19:36 +0100 Subject: [M3devel] Is Modula-3 available on x86_64-unknown-linux-gnu? In-Reply-To: References: <495B4A7B.6010505@gmx.de> <495C4427.4090106@gmx.de> Message-ID: <495CB4D8.5050400@gmx.de> Jay schrieb: > Can you please try a newer build? > ie: one that uses pthreads? I first used cm3-5.4.0, which had the problems you mentioned with the user threads. Then I tried cm3-5.5.0, which always produces an internal compiler error (Segmentation Fault) in cm3cg, which unfortunately has all debugging symbols stripped: $ /home/roland/usr.local/packages/cm3-5.5.0/bin/cm3 --- building in LINUXLIBC6 --- new source -> compiling Hello.m3 Hello.m3: In function 'Hello_M3': Hello.m3:25: internal compiler error: Segmentation fault At last I tried today's daily snapshot (5.7.0-2009-01-01-03). I was confused about the installer, which isn't interactive anymore. And if I run "./cminstall --help" or "./cminstall -?", like probably every Unix user would do, I don't even get a useful error message. Most programs print a single line that looks like: usage: ./cminstall [-verbose] [-interactive] directory That message would have been very helpful. Finally I got around this usability issue, and managed to install it. Since the installation was completely non-interactive, I edited the cm3.cfg file manually. I set SYSTEM_CC="/usr/bin/gcc -m32" and SYSTEM_AS="/usr/bin/as --32", and changed all "-L/usr/lib" into "-L/usr/lib32". Then I tried to build the hello world program, and this is what I got: $ /home/roland/usr.local/packages/cm3-5.7.0.2009.01.01/bin/cm3 --- building in LINUXLIBC6 --- new source -> compiling Hello.m3 -> linking hello $ ./LINUXLIBC6/hello Hello World! Yippieeeeh. Roland From jay.krell at cornell.edu Thu Jan 1 20:45:44 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 1 Jan 2009 19:45:44 +0000 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: <20090101114139.GC10003@jack.stsp.name> References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> <20090101114139.GC10003@jack.stsp.name> Message-ID: What do you mean by "bootstrap binaries"? There are a variety of ways to get a usable system. There is http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-I386_OPENBSD-1.tar.gz extract it (tar zxf ...) cd into it (cd ...) add -lm and -lpthread to the link line make mkdir -p /usr/local/cm3/bin mv cm3 /usr/local/cm3/bin export PATH=$PATH:/usr/local/cm3/bin export CM3_ROOT=/usr/src/cm3 or whatever export CVSROOT=:ext:stefan at m3.elegosoft.com:/usr/cvs cvs -z3 checkout cm3 cd /usr/src/scripts/python ./do-cm3-front.py buildship OR get http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-I386_OPENBSD-d5.7.0.tar.lzma cd /usr/local rm -rf cm3 lzcat cm3-min-I386_OPENBSD-d5.7.0.tar.lzma | tar xf - mv cm3-min-I386_OPENBSD-d5.7.0 cm3 or get the much larger .tar.gz file and usr zcat instead of lzcat get the source cd /usr/src/scripts/python ./do-cm3-all.py realclean && ./upgrade.py && ./do-cm3-std.py buildshipd OR get http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-I386_OPENBSD-d5.7.0.tar.lzma and not much need to build anything, but a good test to see if it is working, can follow the same instructions as for "min", it will rebuild stuff you already have. OR go to some other system, and cd $CVSROOT/m3-sys/m3cc cm3 -DM3CC_TARGET=I386_OPENBSD cd $CVSROOT/scripts/python NOTE you'll either have loosen file system privileges or /slightly/ change the code. For easy of finding it, I put the output at the root of my drive/volume/namespace. I should probably change that to be in /tmp. ./boot1.py I386_OPENBSD This gives you /cm3-boot-I386_OPENBSD-1.tar.gz (and /cm3-boot-I386_OPENBSD-1, but again, I should move these to "temp"), which you ftp or rcp or scp or whatever to the I386_OPENBSD machine and pick up at the first set of steps -- that's how I get new platforms working, though sometimes you can cheat on "biarch" systems, e.g. you can bring up AMD64_LINUX via LINUXLIBC6, just on one machine, no need to copy across machines and can skip the "boot" process and build more in one step, AMD64_FREEBSD via FreeBSD4, etc..)) - Jay> Date: Thu, 1 Jan 2009 12:41:39 +0100> From: stsp at elego.de> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: I386_OPENBSD uploaded-archives> > On Thu, Jan 01, 2009 at 08:51:00AM +0000, Jay wrote:> > > > Stefan, Please try> > [1]http://modula3.elegosoft.com/cm3/uploaded-archives/.> > There are std and min archives there now.> > I haven't yet run X or tests, but the system is self hosting -- it> > builds itself.> > Let us know how it goes.> > Where are the bootstrap binaries?> > Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 1 21:04:36 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 1 Jan 2009 20:04:36 +0000 Subject: [M3devel] Is Modula-3 available on x86_64-unknown-linux-gnu? In-Reply-To: <495CB4D8.5050400@gmx.de> References: <495B4A7B.6010505@gmx.de> <495C4427.4090106@gmx.de> <495CB4D8.5050400@gmx.de> Message-ID: /usr/lib32, good point, we can/should handle that automatically. If word size 32bits and /usr/lib32 exists, use it instead of /usr/lib. Similarly for /usr/lib64. etc. When I get back I'll fiddle with m3-sys/cminstall/src/config-no-install. I never use cminstall. I suggest http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-LINUXLIBC6-d5.7.0.tar.bz2 or http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-LINUXLIBC6-d5.7.0.tar.bz2 though I guess they need a readme. They would admittedly probably have the same problem but I can fix that easily. (-m32/--32 maybe not, but /usr/lib vs. /usr/lib32 probably.) You might also try the native: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-AMD64_LINUX-d5.7.0.tar.gz or http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-AMD64_LINUX-d5.7.0.tar.gz "min" contains only the compiler and m3core and libm3. "std" contains "everything" -- everything that currently builds successfully. - Jay> Date: Thu, 1 Jan 2009 13:19:36 +0100> From: roland.illig at gmx.de> To: m3devel at elegosoft.com> Subject: Re: [M3devel] Is Modula-3 available on x86_64-unknown-linux-gnu?> > Jay schrieb:> > Can you please try a newer build?> > ie: one that uses pthreads?> > I first used cm3-5.4.0, which had the problems you mentioned with the> user threads.> > Then I tried cm3-5.5.0, which always produces an internal compiler error> (Segmentation Fault) in cm3cg, which unfortunately has all debugging> symbols stripped:> > $ /home/roland/usr.local/packages/cm3-5.5.0/bin/cm3> --- building in LINUXLIBC6 ---> > new source -> compiling Hello.m3> Hello.m3: In function 'Hello_M3':> Hello.m3:25: internal compiler error: Segmentation fault> > At last I tried today's daily snapshot (5.7.0-2009-01-01-03). I was> confused about the installer, which isn't interactive anymore. And if I> run "./cminstall --help" or "./cminstall -?", like probably every Unix> user would do, I don't even get a useful error message. Most programs> print a single line that looks like:> > usage: ./cminstall [-verbose] [-interactive] directory> > That message would have been very helpful. Finally I got around this> usability issue, and managed to install it. Since the installation was> completely non-interactive, I edited the cm3.cfg file manually. I set> SYSTEM_CC="/usr/bin/gcc -m32" and SYSTEM_AS="/usr/bin/as --32", and> changed all "-L/usr/lib" into "-L/usr/lib32". Then I tried to build the> hello world program, and this is what I got:> > $ /home/roland/usr.local/packages/cm3-5.7.0.2009.01.01/bin/cm3> --- building in LINUXLIBC6 ---> > new source -> compiling Hello.m3> -> linking hello> $ ./LINUXLIBC6/hello> Hello World!> > Yippieeeeh.> > Roland -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.illig at gmx.de Thu Jan 1 21:10:09 2009 From: roland.illig at gmx.de (Roland Illig) Date: Thu, 01 Jan 2009 21:10:09 +0100 Subject: [M3devel] Is Modula-3 available on x86_64-unknown-linux-gnu? In-Reply-To: References: <495B4A7B.6010505@gmx.de> <495C4427.4090106@gmx.de> <495CB4D8.5050400@gmx.de> Message-ID: <495D2321.1040205@gmx.de> Jay schrieb: > http://modula3.elegosoft.com/cm3/uploaded-archives/ That's nice. I didn't know about this directory before. Roland From rodney.bates at wichita.edu Thu Jan 1 20:02:17 2009 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 01 Jan 2009 13:02:17 -0600 Subject: [M3devel] TEXT & etc. In-Reply-To: <200812310822.mBV8Mf2j027994@camembert.async.caltech.edu> References: <200812310822.mBV8Mf2j027994@camembert.async.caltech.edu> Message-ID: <495D1339.2070703@wichita.edu> I started working on a more elaborate package of performance improvements to TEXT operations. They are algorithm-only (no changes to declarations or invariants of data structure), thus no effect on pickles, stubs, etc., as is your change. I am flattening concatenations only when the result has finite bounded length, keeping Text.Cat O(1), although with considerably larger constant factor. I am also doing two-level rebalancing of trees, also O(1). Without knowing depths (which would require either an O(log N) algorithm to compute then or caching them, requiring data structure changes), I am using lengths as a crude estimate of depth. Meanwhile I am recoding get_chars/get_wide_chars to recurse on only the shorter side and iterate on the other. This, in combination with better balance, should cut down greatly on stack depth and execution time. I am also avoiding cases where a number of other operations in the current implementation unnecessarily convert concatenations containing only 8-bit representations to 16, which requires a character-by-character loop to expand them. I also have found a couple of bugs. Hopefully, these will help. Mika Nystrom wrote: > Hello everyone, > > I mentioned a week or two ago that I had run into horrific performance > issues with CM3's TEXTs. It wasn't my intention to start a debate > about Unicode and Mahjong characters, just to point out that there's > a serious performance problem with CM3 in this area. I run into > performance problems with CM3 from time to time because I am trying > to maintain a fairly large amount of software written in Modula-3 > and it appears to me that the SRC/PM3 compilers often pay better > attention to performance issues than the newer CM3 compiler. > Generally speaking I think Modula-3 needs to avoid getting into the > Java situation: Java is squeezed between "fast enough" Python and > "much more efficient" C++... Modula-3 I see as the only hope for > getting the performance of C++ with the safety of Java. The problems > I have seen with CM3 are in the following areas: > > 1. Thread mutex acquisition involving kernel calls (pthreads > implementation) > > 2. ISTYPE and TYPECASE (appear much faster on PM3, don't know why, > could just be a profiling issue). In any case TYPECASE is very slow > because of having to search the type tree. This could be improved > but I can't work on it because I always run into some kind of fatal > problem trying to bootstrap the compiler. > > 3. The TEXT issue. I mentioned performance problems before. It turns > out that it was showing up in another area. I upgraded my PowerBook > a while back (to OS X 10.4) and of course everything stopped working, > including at least half my Modula-3 programs. I thought it was a > versioning problem with C libraries I was importing, but it turned out > that in at least one case I was running out of stack space because of > the calls to get_char on concatenated TEXTs. (Not very long ones, > at that.) > > To get to the point. What follows is my new version of TextCat.m3, > which I believe works, but I can't really say because I'm perennially > incapable of bootstrapping CM3. The basic idea is that you can > have *one* TextCat.T, at the "root" of your TEXT. It will flatten > anything else. > > I don't see a simple way of modifying the CM3 TEXT implementation to > do much better than this. Of course throwing out TextCat.T completely > is an option. > > An advantage of what I've done is that I haven't changed any interfaces > at all. So I don't get problems with version stamps, etc. > > Mika > > From martinbishop at bellsouth.net Fri Jan 2 04:53:29 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Thu, 01 Jan 2009 21:53:29 -0600 Subject: [M3devel] Modula-3 auto keyword upcase Message-ID: <495D8FB9.6030800@bellsouth.net> I use the Modula-3 elisp code for Emacs to edit Modula-3 source, but it's somewhat annoying having to hit TAB to complete keywords (otherwise I have to hold shift to type them out). I have used an Oberon mode for Emacs before, that would auto upcase the keywords. If you typed 'module' and then pressed space, it would become 'MODULE', etc. I tried to modify the code from the Oberon mode and add it to the Modula-3 mode, but I had no luck. Does anyone know of any Modula-3 elisp code that does this? Or is there another editor that is capable of this? I have NEdit and jEdit, both have Modula-3 highlighting support, but neither help in actually editing Modula-3 code. From jay.krell at cornell.edu Fri Jan 2 08:02:34 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 2 Jan 2009 07:02:34 +0000 Subject: [M3devel] meaning of unsafe? Message-ID: Recent quote, that I haven't further investigated, made me realize some of my ignorance. I know that "unsafe" includes: taking address of local explicit free dealing with any untraced ref? Not sure. Questions are: is unsafe well statically enforced? and/or is safe well statically enforced? That is, should I remove unsafe "everywhere", as long as it compiles ok, it must be safe, and better, so leave it that way? And if it fails, put it back? Or do I need to think about it myself? I think for modules it might be brainless as stated -- put it in only where the compiler makes, and nowhere extra, since extra is a loss not a bonus. But for interfaces.. I think, again, ideal to remove it where you can, but that the compiler can't enforce it? At least where there is "external"? Maybe I should just reread that quote, and thing about it. Safe can code call unsafe code, but should not be able to do so with parameters that, indirectly, make the safe code unsafe. For example, I cannot safe call "free" in unsafe code on behalf of safe code, unless I am darn sure the data isn't referenced -- unless I am the garbage collector. Any pointer give to unsafe code by safe code must not be stored "long term" -- ie: in the heap or globals, because it could be a stack pointer. Unless, well, duh..ok, any VAR parameter or UNTRACED REF passed to unsafe code, what I just said, but traced refs can be held onto -- they are by definition not stack pointers. I guess, you know..programming C code that interacts with Modula-3 code..you realize the incompleteness of the C type system. Modula-3 has, let's say, var, traced ref, and untraced ref. C just has pointers. The compiler doesn't know any better, the programmer has to. If you imagine a Modula-3 to C header compiler..which I would like..you know, it outputs C headers that map FROM Modula-3 interfaces (instead of the usual hand translations in either direction), it would likely lose a lot of information and only be for special purpose use, unless, unlikely, not likely valuable, this problem was solved. Which..oh, this is interesting..I can see, to solve this, you'd need an "API" for storing pointers perhaps. Something perhaps to make sure the pointer is allowed to be stored like such. Not sure. But I suspect this "API" is related to the "checks" that the Modula-3 compiler generates...I really need to understand those... Generally this is easy, because generally things are "synchronous" -- generally the C code doesn't hold on to its parameters beyond the lifetime of itself -- doesn't store it in the heap or globally for other threads to use, and generally the Modula-3 code isn't busy freeing the parameters on another thread, in fact VAR parameters cannot be freed, they are on the stack, and traced refs can only be freed..if the garbage collector can't find any references to them..and then untraced refs require "discipline" both in the Modula-3 code and the C code, but again generally, saved by "synchronicity" -- C code doesn't hold on to them, Modula-3 code doesn't free them on another thread. Those scenarios are certainly possible, just not all that common, and as soon as you "escape" to safe Modula-3 code, not a possibility..no untraced refs.. About right? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Fri Jan 2 08:27:24 2009 From: darko at darko.org (Darko) Date: Fri, 2 Jan 2009 16:27:24 +0900 Subject: [M3devel] meaning of unsafe? In-Reply-To: References: Message-ID: <12ACA122-57EC-4AA1-A250-9E22B71AC2DD@darko.org> Safety is a property of the language, not the procedures. A safe module is one that doesn't use unsafe features and means the language will guarantee that you will get no unchecked errors when you run the code. And that guarantee is dependent on the compiler and language definition being bug free. Outside that of that it is like asking if rocks feel guilty. External modules are not written in M3 so they have no possibility of safety in the M3 sense, unless they were written in a language with an equivalent definition to M3. They might be reliable or bug free, but that's not the same thing. On 02/01/2009, at 4:02 PM, Jay wrote: > Recent quote, that I haven't further investigated, made me realize > some of my ignorance. > > I know that "unsafe" includes: > taking address of local > explicit free > dealing with any untraced ref? Not sure. > > Questions are: > is unsafe well statically enforced? > and/or is safe well statically enforced? > > That is, should I remove unsafe "everywhere", as long as it compiles > ok, it must be safe, and better, so leave it that way? And if it > fails, put it back? > > Or do I need to think about it myself? > > I think for modules it might be brainless as stated -- put it in > only where the compiler makes, and nowhere extra, since extra is a > loss not a bonus. > > But for interfaces.. I think, again, ideal to remove it where you > can, but that the compiler can't enforce it? At least where there is > "external"? > Maybe I should just reread that quote, and thing about it. > > Safe can code call unsafe code, but should not be able to do so with > parameters that, indirectly, make the safe code unsafe. For example, > I cannot safe call "free" in unsafe code on behalf of safe code, > unless I am darn sure the data isn't referenced -- unless I am the > garbage collector. Any pointer give to unsafe code by safe code must > not be stored "long term" -- ie: in the heap or globals, because it > could be a stack pointer. Unless, well, duh..ok, any VAR parameter > or UNTRACED REF passed to unsafe code, what I just said, but traced > refs can be held onto -- they are by definition not stack pointers. > > I guess, you know..programming C code that interacts with Modula-3 > code..you realize the incompleteness of the C type system. Modula-3 > has, let's say, var, traced ref, and untraced ref. C just has > pointers. The compiler doesn't know any better, the programmer has to. > > If you imagine a Modula-3 to C header compiler..which I would > like..you know, it outputs C headers that map FROM Modula-3 > interfaces (instead of the usual hand translations in either > direction), it would likely lose a lot of information and only be > for special purpose use, unless, unlikely, not likely valuable, this > problem was solved. > Which..oh, this is interesting..I can see, to solve this, you'd need > an "API" for storing pointers perhaps. Something perhaps to make > sure the pointer is allowed to be stored like such. Not sure. But I > suspect this "API" is related to the "checks" that the Modula-3 > compiler generates...I really need to understand those... > > > Generally this is easy, because generally things are "synchronous" > -- generally the C code doesn't hold on to its parameters beyond the > lifetime of itself -- doesn't store it in the heap or globally for > other threads to use, and generally the Modula-3 code isn't busy > freeing the parameters on another thread, in fact VAR parameters > cannot be freed, they are on the stack, and traced refs can only be > freed..if the garbage collector can't find any references to > them..and then untraced refs require "discipline" both in the > Modula-3 code and the C code, but again generally, saved by > "synchronicity" -- C code doesn't hold on to them, Modula-3 code > doesn't free them on another thread. Those scenarios are certainly > possible, just not all that common, and as soon as you "escape" to > safe Modula-3 code, not a possibility..no untraced refs.. > > > About right? > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jan 2 09:16:18 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 2 Jan 2009 08:16:18 +0000 Subject: [M3devel] meaning of unsafe? In-Reply-To: <12ACA122-57EC-4AA1-A250-9E22B71AC2DD@darko.org> References: <12ACA122-57EC-4AA1-A250-9E22B71AC2DD@darko.org> Message-ID: The language offers optional safety, therefore safety has a meaning "among" modules and interfaces. (heck, it might be interesting to have safe/unsafe functions, or even blocks of code -- C# has safe/unsafe blocks of code, like unsafe { do stuff }) What is the meaning of an unsafe interface vs. a safe interface? I see one thing -- an unsafe module cannot import from a safe interface. I tried that. I think you or Mika summed it up -- safe code can call into unsafe code, but doing so must not violate "the usual safety" constraints". Therefore, unsafe code must be "careful", i.e. bug-free (well, not logically bug-free, but type-system bug-free -- no use of freed pointers (nor dangling stack pointers, nor invalid addresses in general), no double frees, no buffer overflows (or underflows), no integer overflows, etc., and don't call into any such code either). - Jay From: darko at darko.orgTo: jay.krell at cornell.eduDate: Fri, 2 Jan 2009 16:27:24 +0900CC: m3devel at elegosoft.comSubject: Re: [M3devel] meaning of unsafe? Safety is a property of the language, not the procedures. A safe module is one that doesn't use unsafe features and means the language will guarantee that you will get no unchecked errors when you run the code. And that guarantee is dependent on the compiler and language definition being bug free. Outside that of that it is like asking if rocks feel guilty. External modules are not written in M3 so they have no possibility of safety in the M3 sense, unless they were written in a language with an equivalent definition to M3. They might be reliable or bug free, but that's not the same thing. On 02/01/2009, at 4:02 PM, Jay wrote: Recent quote, that I haven't further investigated, made me realize some of my ignorance. I know that "unsafe" includes: taking address of local explicit free dealing with any untraced ref? Not sure. Questions are: is unsafe well statically enforced? and/or is safe well statically enforced? That is, should I remove unsafe "everywhere", as long as it compiles ok, it must be safe, and better, so leave it that way? And if it fails, put it back? Or do I need to think about it myself? I think for modules it might be brainless as stated -- put it in only where the compiler makes, and nowhere extra, since extra is a loss not a bonus. But for interfaces.. I think, again, ideal to remove it where you can, but that the compiler can't enforce it? At least where there is "external"?Maybe I should just reread that quote, and thing about it. Safe can code call unsafe code, but should not be able to do so with parameters that, indirectly, make the safe code unsafe. For example, I cannot safe call "free" in unsafe code on behalf of safe code, unless I am darn sure the data isn't referenced -- unless I am the garbage collector. Any pointer give to unsafe code by safe code must not be stored "long term" -- ie: in the heap or globals, because it could be a stack pointer. Unless, well, duh..ok, any VAR parameter or UNTRACED REF passed to unsafe code, what I just said, but traced refs can be held onto -- they are by definition not stack pointers. I guess, you know..programming C code that interacts with Modula-3 code..you realize the incompleteness of the C type system. Modula-3 has, let's say, var, traced ref, and untraced ref. C just has pointers. The compiler doesn't know any better, the programmer has to. If you imagine a Modula-3 to C header compiler..which I would like..you know, it outputs C headers that map FROM Modula-3 interfaces (instead of the usual hand translations in either direction), it would likely lose a lot of information and only be for special purpose use, unless, unlikely, not likely valuable, this problem was solved. Which..oh, this is interesting..I can see, to solve this, you'd need an "API" for storing pointers perhaps. Something perhaps to make sure the pointer is allowed to be stored like such. Not sure. But I suspect this "API" is related to the "checks" that the Modula-3 compiler generates...I really need to understand those... Generally this is easy, because generally things are "synchronous" -- generally the C code doesn't hold on to its parameters beyond the lifetime of itself -- doesn't store it in the heap or globally for other threads to use, and generally the Modula-3 code isn't busy freeing the parameters on another thread, in fact VAR parameters cannot be freed, they are on the stack, and traced refs can only be freed..if the garbage collector can't find any references to them..and then untraced refs require "discipline" both in the Modula-3 code and the C code, but again generally, saved by "synchronicity" -- C code doesn't hold on to them, Modula-3 code doesn't free them on another thread. Those scenarios are certainly possible, just not all that common, and as soon as you "escape" to safe Modula-3 code, not a possibility..no untraced refs.. About right? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Fri Jan 2 09:24:28 2009 From: darko at darko.org (Darko) Date: Fri, 2 Jan 2009 17:24:28 +0900 Subject: [M3devel] meaning of unsafe? In-Reply-To: References: <12ACA122-57EC-4AA1-A250-9E22B71AC2DD@darko.org> Message-ID: <408EB16D-82D8-47DF-A036-10AA25CC5C69@darko.org> The language def says: In unsafe interfaces and modules the definition of "assignable" for types is extended: two reference types T and U are assignable if T <: U or U <: T. The only effect of this change is to allow a value of type ADDRESS to be assigned to a variable of type UNTRACED REF T. It is an unchecked runtime error if the value does not address a variable of type T. In unsafe interfaces and modules the type constructor UNTRACED REF T is allowed for traced as well as untraced T, and the fields of untraced objects can be traced. If u is an untraced reference to a traced variable t, then the validity of the traced references in t is implementation-dependent, since the garbage collector probably will not trace them through u. On 02/01/2009, at 5:16 PM, Jay wrote: > The language offers optional safety, therefore safety has a meaning > "among" modules and interfaces. > (heck, it might be interesting to have safe/unsafe functions, or > even blocks of code -- C# has safe/unsafe blocks of code, like > unsafe { do stuff }) > > What is the meaning of an unsafe interface vs. a safe interface? > > I see one thing -- an unsafe module cannot import from a safe > interface. > I tried that. > > I think you or Mika summed it up -- safe code can call into unsafe > code, but doing so must not violate "the usual safety" constraints". > Therefore, unsafe code must be "careful", i.e. bug-free (well, not > logically bug-free, but type-system bug-free -- no use of freed > pointers (nor dangling stack pointers, nor invalid addresses in > general), no double frees, no buffer overflows (or underflows), no > integer overflows, etc., and don't call into any such code either). > > - Jay > > > > From: darko at darko.org > To: jay.krell at cornell.edu > Date: Fri, 2 Jan 2009 16:27:24 +0900 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] meaning of unsafe? > > > Safety is a property of the language, not the procedures. A safe > module is one that doesn't use unsafe features and means the > language will guarantee that you will get no unchecked errors when > you run the code. And that guarantee is dependent on the compiler > and language definition being bug free. > > Outside that of that it is like asking if rocks feel guilty. > External modules are not written in M3 so they have no possibility > of safety in the M3 sense, unless they were written in a language > with an equivalent definition to M3. They might be reliable or bug > free, but that's not the same thing. > > > On 02/01/2009, at 4:02 PM, Jay wrote: > > Recent quote, that I haven't further investigated, made me realize > some of my ignorance. > > I know that "unsafe" includes: > taking address of local > explicit free > dealing with any untraced ref? Not sure. > > Questions are: > is unsafe well statically enforced? > and/or is safe well statically enforced? > > That is, should I remove unsafe "everywhere", as long as it compiles > ok, it must be safe, and better, so leave it that way? And if it > fails, put it back? > > Or do I need to think about it myself? > > I think for modules it might be brainless as stated -- put it in > only where the compiler makes, and nowhere extra, since extra is a > loss not a bonus. > > But for interfaces.. I think, again, ideal to remove it where you > can, but that the compiler can't enforce it? At least where there is > "external"? > Maybe I should just reread that quote, and thing about it. > > Safe can code call unsafe code, but should not be able to do so with > parameters that, indirectly, make the safe code unsafe. For example, > I cannot safe call "free" in unsafe code on behalf of safe code, > unless I am darn sure the data isn't referenced -- unless I am the > garbage collector. Any pointer give to unsafe code by safe code must > not be stored "long term" -- ie: in the heap or globals, because it > could be a stack pointer. Unless, well, duh..ok, any VAR parameter > or UNTRACED REF passed to unsafe code, what I just said, but traced > refs can be held onto -- they are by definition not stack pointers. > > I guess, you know..programming C code that interacts with Modula-3 > code..you realize the incompleteness of the C type system. Modula-3 > has, let's say, var, traced ref, and untraced ref. C just has > pointers. The compiler doesn't know any better, the programmer has to. > > If you imagine a Modula-3 to C header compiler..which I would > like..you know, it outputs C headers that map FROM Modula-3 > interfaces (instead of the usual hand translations in either > direction), it would likely lose a lot of information and only be > for special purpose use, unless, unlikely, not likely valuable, this > problem was solved. > Which..oh, this is interesting..I can see, to solve this, you'd need > an "API" for storing pointers perhaps. Something perhaps to make > sure the pointer is allowed to be stored like such. Not sure. But I > suspect this "API" is related to the "checks" that the Modula-3 > compiler generates...I really need to understand those... > > > Generally this is easy, because generally things are "synchronous" > -- generally the C code doesn't hold on to its parameters beyond the > lifetime of itself -- doesn't store it in the heap or globally for > other threads to use, and generally the Modula-3 code isn't busy > freeing the parameters on another thread, in fact VAR parameters > cannot be freed, they are on the stack, and traced refs can only be > freed..if the garbage collector can't find any references to > them..and then untraced refs require "discipline" both in the > Modula-3 code and the C code, but again generally, saved by > "synchronicity" -- C code doesn't hold on to them, Modula-3 code > doesn't free them on another thread. Those scenarios are certainly > possible, just not all that common, and as soon as you "escape" to > safe Modula-3 code, not a possibility..no untraced refs.. > > > About right? > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Jan 2 11:15:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 02 Jan 2009 11:15:25 +0100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <495B901F.1E75.00D7.1@scires.com> References: <20081231105208.9CF4710D5DDE@birch.elegosoft.com> <495B4846.1E75.00D7.1@scires.com> <495B901F.1E75.00D7.1@scires.com> Message-ID: <20090102111525.16anbdkwg8ocg44k@mail.elegosoft.com> See below (still trying to catch up on M3 mails ;-) Quoting Randy Coleburn : > Jay: > > First, I do want to say thanks for all you are doing for the cause > of Modula-3. I don't think we say thanks enough for what others do > for us. THANK YOU! > > I don't want to be perceived as "complaining", rather I am trying to > voice my opinion in the hopes of influencing future direction. Of > course, since I'm not doing the work, I can only make suggestions. > > In reading your post, you state that you deoptimized the native > implementation to make it match Cygwin. Now, I'm not sure how much > effect this deoptimization has (maybe little), but it is clear that > in this case your implementation choice has favored the non-native > implementation over the native one. IMO, tradeoffs of this type are > not good. If one is trying to convince someone to use Modula-3, > why would you want to give them a "deoptimized" version just to > make it easier to support a non-native environment---indeed, one > that they may not even want/use? If we have to make a trade-off, I > say favor the native implementation always over the non-native one. > > What I'm trying to say here is that my experience as a software, > systems, and program engineer is that I've always been forced to > justify the cost/benefit of development tools for any project. Many > times I've had to go head to head with folks higher up in my own > organization or in the customer's organization whose preconceived > opinions were based on rumor and what they've heard rather than > actual factual hands-on experience. I want to pick the best tool > for the job instead of being forced to pick an inferior tool because > someone higher in the food chain demanded it based on faulty > preconceived opinion. I like Modula-3. I've found that I am more > productive using it. But, if the compiler doesn't produce efficient > code, I lose ground in arguing with the higher-ups. > > As for Python, I've never ventured to learn it, so for me, it is > something of a mystery. But you miss the point. I'm not arguing > the merits of Python, I'm just saying that anything Modula-3 > requires on top of what is provided by the standard host platform > represents a potential obstacle or barrier to ease of > use/implementation. It also sends the message that somehow Modula-3 > is not complete on its own, we have get Python just to install and > oh yes we need a C compiler and a linker and a ...? IMO, > ultimately we need a turn-key download and install routine for > Modula-3 that just works, out-of-the-box. If you give me an EXE, a > CMD, or a BAT, for the install, I can run it on Windows, but if you > give me an install routine that requires I first install something > else, e.g. Python, then that becomes a barrier to the folks who > don't know Python or already have it installed. > > Am I alone in this line of thought? If so, I'll just be quiet. No, you're not alone here. Ultimately, I think we should have something that installs very easily without any preconditions, too. But it is difficult to achieve and maintain this quality in an open source project with so few volunteers. So I am afraid that there will have to be some tradeoffs, but we should try to keep them reasonably small. Thus said, I think it is great that you are speaking up here, as great as it is that Jay is doing this great amount of work for M3. It is important that changes are reviewed and reasons are questioned for the overall quality of the project. And as long as we are polite and argue reasonably and not personally, this is only good for the project, too. Thanks to all who are contributing to the M3 delevopment, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Jan 2 11:27:24 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 02 Jan 2009 11:27:24 +0100 Subject: [M3devel] variations of waitpid..? In-Reply-To: References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> Message-ID: <20090102112724.5sr7fnp000cokcco@mail.elegosoft.com> Quoting Tony Hosking : > If someone uses waitpid they get what they paid for. It is so long ago that we wrote those sysutils routines... They have only ever be used in simple command line utilities (like cm3) without much concurrency, I think. If there is potential for deadlocks and bad performance, we should at least document that in the interfaces. I am not up-to-date wrt. the M3 system interfaces and threads implementation: is there a way for a thread to wait for the exit code of another process without blocking other threads? If so, I'll adapt the sysutils code... If not, can we introduce such an interface in m3core/libm3? Olaf > On 1 Jan 2009, at 06:24, Jay wrote: > >> >> You mean, this function is easy to misuse? >>> People who declare their own <*EXTERNAL*> >> Like waitpid exposed from m3core? >> >> waitpid is already easy to misuse, on a userthread system, leading >> to possible (though I think rare) deadlock. >> It is easy to misuse on pthreads, lead "just" to bad performance, >> and in fact I believe cm3 is doing this, via sysutils. >> This at least guides you between two patterns of use, and fix the >> perf of cm3/sysutils. >> >> On a userthread system, waitpid(pid, flags = 0) waits for the child >> process, with all parent threads suspended. >> Generally I doubt the child depends on parent threads progressing, >> but, yeah, that could deadlock, like if a parent thread is waiting >> to a file or stdin of the child, or reading a child's stdout. >> >> The various uses do waitpid(pid, flags = nohang) and then sleep and >> try again. >> >> pthreads just uses waitpid(pid, flags = 0) and all threads keep running -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Jan 2 11:32:57 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 02 Jan 2009 11:32:57 +0100 Subject: [M3devel] FW: variations of waitpid..? In-Reply-To: References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> Message-ID: <20090102113257.me6vseyaskggssoc@mail.elegosoft.com> Quoting Jay : > (Personally I have seen precious little code that cares about stack > size, just seems to somehow get along, combined with the fact that > the current Modula-3 pthread code very likely leaks on some > platforms attempting to deal with stack size, makes me inclined to > just rip out the code..but yeah..just fix the leak...) Please don't do that (remove the ability to set stack sizes). I know that for most of the programs I wrote years ago we had to adapt stack sizes for threads carefully. That was with user threads though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Jan 2 11:42:48 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 02 Jan 2009 11:42:48 +0100 Subject: [M3devel] TEXT & etc. In-Reply-To: <495D1339.2070703@wichita.edu> References: <200812310822.mBV8Mf2j027994@camembert.async.caltech.edu> <495D1339.2070703@wichita.edu> Message-ID: <20090102114248.lcnartw3eowcs4gg@mail.elegosoft.com> Quoting "Rodney M. Bates" : > I started working on a more elaborate package of performance improvements > to TEXT operations. They are algorithm-only (no changes to declarations or > invariants of data structure), thus no effect on pickles, stubs, etc., as > is your change. > > I am flattening concatenations only when the result has finite bounded > length, keeping Text.Cat O(1), although with considerably larger constant > factor. I am also doing two-level rebalancing of trees, also O(1). > Without knowing depths (which would require either an O(log N) algorithm > to compute then or caching them, requiring data structure changes), I am > using lengths as a crude estimate of depth. > > Meanwhile I am recoding get_chars/get_wide_chars to recurse on only > the shorter side and iterate on the other. This, in combination with > better balance, should cut down greatly on stack depth and execution > time. > > I am also avoiding cases where a number of other operations in the current > implementation unnecessarily convert concatenations containing only 8-bit > representations to 16, which requires a character-by-character loop > to expand them. > > I also have found a couple of bugs. All this sounds good. Have you already committed some of your work? (I'm not following m3commit closely these days.) Have you also some test cases that will validate the TEXT behaviour for concatenations etc.? Olaf > Hopefully, these will help. > > Mika Nystrom wrote: >> Hello everyone, >> >> I mentioned a week or two ago that I had run into horrific performance >> issues with CM3's TEXTs. It wasn't my intention to start a debate >> about Unicode and Mahjong characters, just to point out that there's >> a serious performance problem with CM3 in this area. I run into >> performance problems with CM3 from time to time because I am trying >> to maintain a fairly large amount of software written in Modula-3 >> and it appears to me that the SRC/PM3 compilers often pay better >> attention to performance issues than the newer CM3 compiler. >> Generally speaking I think Modula-3 needs to avoid getting into the >> Java situation: Java is squeezed between "fast enough" Python and >> "much more efficient" C++... Modula-3 I see as the only hope for >> getting the performance of C++ with the safety of Java. The problems >> I have seen with CM3 are in the following areas: >> >> 1. Thread mutex acquisition involving kernel calls (pthreads >> implementation) >> >> 2. ISTYPE and TYPECASE (appear much faster on PM3, don't know why, >> could just be a profiling issue). In any case TYPECASE is very slow >> because of having to search the type tree. This could be improved >> but I can't work on it because I always run into some kind of fatal >> problem trying to bootstrap the compiler. >> >> 3. The TEXT issue. I mentioned performance problems before. It >> turns out that it was showing up in another area. I upgraded my >> PowerBook >> a while back (to OS X 10.4) and of course everything stopped working, >> including at least half my Modula-3 programs. I thought it was a >> versioning problem with C libraries I was importing, but it >> turned out >> that in at least one case I was running out of stack space because of >> the calls to get_char on concatenated TEXTs. (Not very long ones, >> at that.) >> >> To get to the point. What follows is my new version of TextCat.m3, >> which I believe works, but I can't really say because I'm perennially >> incapable of bootstrapping CM3. The basic idea is that you can >> have *one* TextCat.T, at the "root" of your TEXT. It will flatten >> anything else. I don't see a simple way of modifying the CM3 TEXT >> implementation to do much better than this. Of course throwing out >> TextCat.T completely >> is an option. >> >> An advantage of what I've done is that I haven't changed any interfaces >> at all. So I don't get problems with version stamps, etc. >> >> Mika >> >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.bates at wichita.edu Fri Jan 2 18:29:26 2009 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 02 Jan 2009 11:29:26 -0600 Subject: [M3devel] TEXT & etc. In-Reply-To: <20090102114248.lcnartw3eowcs4gg@mail.elegosoft.com> References: <200812310822.mBV8Mf2j027994@camembert.async.caltech.edu> <495D1339.2070703@wichita.edu> <20090102114248.lcnartw3eowcs4gg@mail.elegosoft.com> Message-ID: <495E4EF6.6030406@wichita.edu> No, I have not committed anything yet. I have it temporarily coded so the the operations can be switched between the old and new versions by setting a (gasp!) global variable. I plan to write a test program that generates many (10s of thousands) of random operations on texts, does them using old and new algorithms, and compares results. I have used this testing approach on several projects in the past, with very good success. My preferred development style is to get a group of related changes complete and tested before committing anything. For one thing, that saves me from having to retest after every little change. Just since my previous post, I have already had to do some rethinking about how much and what kind of rebalancing to do. Olaf Wagner wrote: > Quoting "Rodney M. Bates" : > >> I started working on a more elaborate package of performance improvements >> to TEXT operations. They are algorithm-only (no changes to >> declarations or >> invariants of data structure), thus no effect on pickles, stubs, etc., as >> is your change. >> >> I am flattening concatenations only when the result has finite bounded >> length, keeping Text.Cat O(1), although with considerably larger constant >> factor. I am also doing two-level rebalancing of trees, also O(1). >> Without knowing depths (which would require either an O(log N) algorithm >> to compute then or caching them, requiring data structure changes), I am >> using lengths as a crude estimate of depth. >> >> Meanwhile I am recoding get_chars/get_wide_chars to recurse on only >> the shorter side and iterate on the other. This, in combination with >> better balance, should cut down greatly on stack depth and execution >> time. >> >> I am also avoiding cases where a number of other operations in the >> current >> implementation unnecessarily convert concatenations containing only 8-bit >> representations to 16, which requires a character-by-character loop >> to expand them. >> >> I also have found a couple of bugs. > > All this sounds good. Have you already committed some of your work? > (I'm not following m3commit closely these days.) > Have you also some test cases that will validate the TEXT behaviour > for concatenations etc.? > > Olaf > > From jay.krell at cornell.edu Fri Jan 2 19:18:20 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 2 Jan 2009 18:18:20 +0000 Subject: [M3devel] variations of waitpid..? In-Reply-To: <20090102112724.5sr7fnp000cokcco@mail.elegosoft.com> References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> <20090102112724.5sr7fnp000cokcco@mail.elegosoft.com> Message-ID: > is there a way for a thread to wait for the exit code> of another process without blocking other threads? If so, I'll adapt Yes, by using kernel threads (which is all that work currently, but I'll probably fix that..) If you know you are using kernel threads, you can optimize accordingly. I measured the difference when I fixed m3core/libm3 and it was significant, though I forgot the details (they should be in the m3commit or m3devel history). I didn't measure for sysutils. It seems to me that sysutils provides /roughly/ but not exactly identical abstractions as m3core/libm3. This is not "bad", it just means m3core/libm3 aren't necessarily providing the best, sufficiently general abstractions. That happens. (It is also common for folks to reimplement stuff due to not understanding what is available, or there being a real or perceived inability to change what is available.) For this reason, that I fixed m3core/libm3 months ago, does not help sysutils. That is, sysutils uses waitpid, and the waitpid uses in m3core/libm3 are "buried" in higher abstractions. m3core/waitpid itself, I think, is not where this fix belongs. But maybe. I think that would change its semantics too much, even if its semantics are problematic. Maybe. I hadn't considered this. At least the change would only be in the user threads implementation. Everyone could perhaps just pass 0, and a wrapper would change to nohang and poll/sleep loop. pthreads would not -- it'd just pass on directly through. A lower level interface is needed for sysutils, and I added one. I added SchedulerPosix.DoesWaitPidYield. It just returns true for pthreads and false for userthreads. However, I believe sysutils cannot take on new m3core/libm3 dependencies, unless the minimum version for bootstrapping is raised, to a version that includes those changes. Therefore I don't use the very abstraction provided to solve the problem, but something similar. The code is now prepared to trivially switch to it, when the time comes that the minimum m3core/libm3 is raised. Similar story as the portable waitpid C wrapper, which I think fixes errors on I386_DARWIN and AMD64_DARWIN, though that I think only matters if a process returns non-zero, was ok for returning 0. There the code is well shared, but via automated copy and rename. For waitpid, I changed the "copied abstraction" to just be an interace containing a constant, instead of a function call. Perhaps a constant in m3core would be appropriate too. However..I wonder if the user/kernel threads option should be chosable at runtime or the command line or the default changable when building executables, all using the same runtime that could support either, therefore a function call. I know, it isn't chosable as such currently, it is a feature of the m3core as-built, but maybe a nice idea. - Jay> Date: Fri, 2 Jan 2009 11:27:24 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] variations of waitpid..?> > Quoting Tony Hosking :> > > If someone uses waitpid they get what they paid for.> It is so long ago that we wrote those sysutils routines...> They have only ever be used in simple command line utilities (like cm3)> without much concurrency, I think. If there is potential for deadlocks> and bad performance, we should at least document that in the interfaces.> > I am not up-to-date wrt. the M3 system interfaces and threads> implementation: is there a way for a thread to wait for the exit code> of another process without blocking other threads? If so, I'll adapt> the sysutils code... If not, can we introduce such an interface in> m3core/libm3?> > Olaf> > > On 1 Jan 2009, at 06:24, Jay wrote:> >> >>> >> You mean, this function is easy to misuse?> >>> People who declare their own <*EXTERNAL*>> >> Like waitpid exposed from m3core?> >>> >> waitpid is already easy to misuse, on a userthread system, leading > >> to possible (though I think rare) deadlock.> >> It is easy to misuse on pthreads, lead "just" to bad performance, > >> and in fact I believe cm3 is doing this, via sysutils.> >> This at least guides you between two patterns of use, and fix the > >> perf of cm3/sysutils.> >>> >> On a userthread system, waitpid(pid, flags = 0) waits for the child > >> process, with all parent threads suspended.> >> Generally I doubt the child depends on parent threads progressing, > >> but, yeah, that could deadlock, like if a parent thread is waiting > >> to a file or stdin of the child, or reading a child's stdout.> >>> >> The various uses do waitpid(pid, flags = nohang) and then sleep and > >> try again.> >>> >> pthreads just uses waitpid(pid, flags = 0) and all threads keep running> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jan 2 19:36:33 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 2 Jan 2009 18:36:33 +0000 Subject: [M3devel] FW: variations of waitpid..? In-Reply-To: <20090102113257.me6vseyaskggssoc@mail.elegosoft.com> References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> <20090102113257.me6vseyaskggssoc@mail.elegosoft.com> Message-ID: The pthreads code appears to leak for every thread created, as a result of trying to set stack size.I'll just fix it, once confirmed. Setting stack size is basically impossible all around.Both by the user and by "the OS". By the user: If the user calls into any dynamically linked code he didn't write, he doesn'tknow what is needed, without a lot of testing, and it can change in time. If the user so much as compiles with different flags or a different compileror targeting a different platform, stack use will change. By the OS: Same thing -- the OS doesn't know how much stack any user will need. Personally I generally practise and recommend minimizing stack usageand using heap instead. However there are large tradeoffs inperf and medium tradeoffs in debuggability (debuggers do a betterjob of immediately showing the contents of character arrays, insteadof pointers, which they don't follow automatically, at least cdb/ntsd/windbg,not sure about the various gdb/dbx/visualstudio). A terrible pattern imho, is stuff like char FilePath[some large maximum like 200 or 1000]; They use up the stack fast, are usually wasteful over-allocations, and sometimes arbitrary capacity-limiting under-allocations. For paths in particular, Win32 advertises two maximums, one of which is wrong, the other of which is suspicous -- 260 and 32K. 32K isn't clearly correct due to the availability of relative opens. Even if 32K is considered correct, it is way too much to allocate "just in case". Better to determine the actual needed size and allocate that. (I think current Cygwin code does just this though -- blow up a bunch of buffers to 32K.) Imho. Oh, and the common Unix advertisement of 1024 is also perhaps wrong.You know, what happens if I am using SMB to NT, or to another system with a different max?Do paths beyond 1024 get truncated, or unavailable, or overflow buffers?They can certainly exist.I'll have to try it out sometime. In general on disk structures are all "relative" and have no limits for full paths,only usually for individual path elements. The stack is generally of relatively small capacity, and when it is exhausted,that is more difficult to detect and recover from, than heap or addressspaceexhaustion. True, even heap and addresspace can run out, by either being "only" 32bits, orvia fragmentation, and are difficult to recover from.I personally don't defend against fragmentation, and it worries me some.It's maybe not a concern in Modula-3 due to compaction, however compactionseems also bad in that it requires larger contiguous memory.Fragmentation is good. Fragmentation is bad.. - Jay> Date: Fri, 2 Jan 2009 11:32:57 +0100> From: wagner@> To: m3devel@> Subject: Re: [M3devel] FW: variations of waitpid..?> > Quoting Jay:> > > (Personally I have seen precious little code that cares about stack > > size, just seems to somehow get along, combined with the fact that > > the current Modula-3 pthread code very likely leaks on some > > platforms attempting to deal with stack size, makes me inclined to > > just rip out the code..but yeah..just fix the leak...)> > Please don't do that (remove the ability to set stack sizes). I know> that for most of the programs I wrote years ago we had to adapt stack> sizes for threads carefully. That was with user threads though.> > Olaf -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jan 2 19:44:48 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 2 Jan 2009 18:44:48 +0000 Subject: [M3devel] dynamic chose between user/kernel threads? Message-ID: Should the user/kernel thread chose be available: On the command line to a Modula-3 executable (or even an executable where main is in another language, but which static or dynamic Modula-3 libs are used)? Via a quake directive when building programs? You know, imagine you have a bunch of Modula-3 programs and some but not all use a very large number of threads and benefit from userthreads. Currently the chose is locked into m3core when it is built. I understand (and anyone who likes the idea should understand) this is not easy to achieve. Well, at the very least, it is a tedious transform of the code, not anything hard to understand, just not a small physical change. The choice also has to be communicated very early in "startup/initialization", since e.g. the garbage collector creates a thread for itself during "startup/initialization" -- letting Main's body call Scheduler.SetThreadImplementation(enum [UserThreads, KernelThreads]) would not likely work, and not be provided. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jan 2 20:15:48 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 2 Jan 2009 19:15:48 +0000 Subject: [M3devel] variations of waitpid..? In-Reply-To: <20090102112724.5sr7fnp000cokcco@mail.elegosoft.com> References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> <20090102112724.5sr7fnp000cokcco@mail.elegosoft.com> Message-ID: I didn't read that well -- the deadlock risk in sysutils is not there. The bad perf is probably. To be clear (esp. for folks that might not already know about this, I didn't know about until fairly recently), there are two options: waitpid(pid, flags = 0) move along or while (waitpid(pid, flags = nohang) != 0) sleep(some value) The second is what sysutils was doing, and works, doesn't deadlock, is deoptimized. m3core/libm3 did this for a long time as well. When I complained about perf, it was pointed out to me. The first has deadlock potential with userthreads, but is ok and faster with kernel threads. waitpid(flags = nohang = don't actually wait, just get the exit code, if there is one) is a way to quickly poll if a process has ended, and if so, get its exit code. In Win32 there are two seperate functions GetExitCodeProcess and WaitForSingleObject or WaitForMultipleObjects ("waiting" is generalized across files, processes, sockets, files, threads, semaphores, mutexes, events and more..but not critical sections..only kernel objects). These have a bug too. One particular exit code is reserved to mean "the process is still running", but that is easily avoided by using Wait first. I have seen code get confused by this though. Wait also accepts a timeout, 32bit unsigned milliseconds, including 0 and infinity, so also can be used to poll. Win32 also defines the exit code to be 32bits, whereas Posix only allows for 8 bits which can be an interop problem. Perl on Win32 truncates exit codes to 8 bits, very bad. Unhandled exceptions end up as "large" exit codes. Anyway... The problem with the polling approach, at least part of the problem, is that if the child process isn't done when waitpid is first called, but finishes before sleep(whatever value) ends, we will still sleep for the full "whatever value". You only really want to sleep until the child process is done, and no longer. Making just the first sleep shorter might be a good idea. You know, to handle processes that are short-lived, but not "zero" lived. ("zero" being the amount of time it takes for the code to proceed from fork/exec to waitpid, surely much smaller than a small sleep() but longer than no sleep). Calling just waitpid(flags = 0) could deadlock if, for example, a parent thread is writing to a child's stdin, and the child won't finish until the parent has written all that it needs to. The parent and child process, er, other threads in the parent process, need to be allowed to run concurrently, for the sake of at least some reasonable scenarios. With kernelthreads, the implementation of waitpid knows about threads and will itself, in a sense, do the poll/sleep, but not exactly that -- it won't sleep beyond the child process finishing. Hopefully this makes sense and lets more folks understand the problem. What you can do, of course, is like: if kernelthreads waitpid(flags = 0) else while (waitpid(flags = nohang) != 0) sleep and that is basically what the code looks like now. The part "if kernelthreads" I propose be "if SchedulerPosix.DoesWaitPidYield()" though a really direct "if Thread or Scheduler.KernelThreads" might be reasonable. Up to folks then to decide what that implies.. - Jay> Date: Fri, 2 Jan 2009 11:27:24 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] variations of waitpid..?> > Quoting Tony Hosking :> > > If someone uses waitpid they get what they paid for.> It is so long ago that we wrote those sysutils routines...> They have only ever be used in simple command line utilities (like cm3)> without much concurrency, I think. If there is potential for deadlocks> and bad performance, we should at least document that in the interfaces.> > I am not up-to-date wrt. the M3 system interfaces and threads> implementation: is there a way for a thread to wait for the exit code> of another process without blocking other threads? If so, I'll adapt> the sysutils code... If not, can we introduce such an interface in> m3core/libm3?> > Olaf> > > On 1 Jan 2009, at 06:24, Jay wrote:> >> >>> >> You mean, this function is easy to misuse?> >>> People who declare their own <*EXTERNAL*>> >> Like waitpid exposed from m3core?> >>> >> waitpid is already easy to misuse, on a userthread system, leading > >> to possible (though I think rare) deadlock.> >> It is easy to misuse on pthreads, lead "just" to bad performance, > >> and in fact I believe cm3 is doing this, via sysutils.> >> This at least guides you between two patterns of use, and fix the > >> perf of cm3/sysutils.> >>> >> On a userthread system, waitpid(pid, flags = 0) waits for the child > >> process, with all parent threads suspended.> >> Generally I doubt the child depends on parent threads progressing, > >> but, yeah, that could deadlock, like if a parent thread is waiting > >> to a file or stdin of the child, or reading a child's stdout.> >>> >> The various uses do waitpid(pid, flags = nohang) and then sleep and > >> try again.> >>> >> pthreads just uses waitpid(pid, flags = 0) and all threads keep running> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Fri Jan 2 21:22:45 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 2 Jan 2009 20:22:45 +0000 (GMT) Subject: [M3devel] Modula-3 auto keyword upcase In-Reply-To: <495D8FB9.6030800@bellsouth.net> Message-ID: <562083.11611.qm@web28610.mail.ukl.yahoo.com> Hi, I know there are two good options, but yo may want to try first and see what adjust better for your purposes: The m3clipse projects which currently has developed a parser that builds the AST tree and gives you highlighting capabilities of Eclipse Editors (also auto completes) You may want to try download the source and build as a Java Plugin Project, http://sourceforge.net/cvs/?group_id=183896 if doesn't work or have doubts on how to do it just write the m3clipse project list or me. The author told me that: "The simplest way is to start Eclipse (3.3), choose File->import and load the workset file" that is m3clipse.psf file The other possibility but is still more in development is the Cooledit Text Editor Modula-3 syntax work made by Pino Zollo (he agrees to put the files on elego cvs tree ): http://freshmeat.net/projects/cooledit/ You can put the two files which are attached (Syntax and modula3.syntax)? and you will get some completion features (I couldn't see if that works still as the author told me it does, but highlighting works),? and offers easy macro construction on the Editor and easy interaction with python scripts. I managed to compile the cooledit itself and then put the 2 files on the path ~/.cedit/? (or in the Unix installation path /usr/local/share/cooledit/syntax ) but I needed to add the following two lines in the Syntax file (no modula3.syntax) : file ..\*\\.(m3|i3|ig|mg)$ Modula3\sProgram include modula3.syntax Cooledit? should work in Win32 platforms as well. Also he commented me the mc program could use this two files as well. Hope this helps --- El jue, 1/1/09, Martin Bishop wrote: De: Martin Bishop Asunto: [M3devel] Modula-3 auto keyword upcase Para: m3devel at elegosoft.com Fecha: jueves, 1 enero, 2009 10:53 I use the Modula-3 elisp code for Emacs to edit Modula-3 source, but it's somewhat annoying having to hit TAB to complete keywords (otherwise I have to hold shift to type them out). I have used an Oberon mode for Emacs before, that would auto upcase the keywords. If you typed 'module' and then pressed space, it would become 'MODULE', etc. I tried to modify the code from the Oberon mode and add it to the Modula-3 mode, but I had no luck. Does anyone know of any Modula-3 elisp code that does this? Or is there another editor that is capable of this? I have NEdit and jEdit, both have Modula-3 highlighting support, but neither help in actually editing Modula-3 code. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Syntax Type: application/octet-stream Size: 4510 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: modula3.syntax Type: application/octet-stream Size: 5846 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: m3clipse.psf Type: application/octet-stream Size: 329 bytes Desc: not available URL: From rcoleburn at scires.com Fri Jan 2 22:18:40 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 02 Jan 2009 16:18:40 -0500 Subject: [M3devel] FW: variations of waitpid..? In-Reply-To: References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> Message-ID: <495E3E42.1E75.00D7.1@scires.com> Jay: Your comment about stack size rang a bell with me. I have had trouble in the past running out of stack space, most notably on HP-UX. Same program built on Windows usually did not suffer the same fate. I seem to recall the most stack space trouble was when a thread did anything with Trestle/FormsVBT etc. So, I added a command line switch to my program that let's you specify a multiplier for the stack size. During initialization, my programs read the command line switches and take appropriate action to increase the thread stack sizes before any threads are created. If you don't specify a stack size multiplier on the command line, I think I wound up using seven (7) as the default. Here is a code excerpt: IF stackMult > 1 THEN WITH default = Thread.GetDefaultStackSize(), desired = default * stackMult, increase = desired - default DO PutText("Increasing default stack size by a factor of " & Fmt.Int(stackMult) & " (" & Fmt.Int(default) & " >>> " & Fmt.Int(desired) & ").\n"); Thread.IncDefaultStackSize(increase); END; (* with *) WITH default = Thread.GetDefaultStackSize() DO PutText("Thread stacks are now " & Fmt.Int(default) & " bytes.\n"); END; (* with *) END; (* if *) Regards, Randy >>> Jay 12/31/2008 8:59 PM >>> [truncated just slightly..and probably will be again given more rambling..] ps: the internal use in m3core could be easily removed, just by compiling one branch of the if or the other. I just wanted them in the same file to keep similar code closer together. So it comes down that m3core does expose Uwaitpid.waitpid and Uexec.waitpid, and as long as they are...or as long as user threads exist..imho there is some obligation of m3core to expose perhaps surprising characteristics of its thread library. You might say the entire interface is already and has always been fully exposed in Thread.i3, but I don't believe it. User threads and kernel threads have too divergent too visible artifacts, that I don't think are previously exposed in the public interface. I claim it is somewhat "surprising", or at least important to know the detail of, whether or not waitpid yields to other threads. You know, I mean..let's say I am some really clever waitpid user and I really must use it. And I am using Modula-3 threads. And my child process is reading the output of Modula-3 threads. Aren't I kind of stuck? Isn't there /some/ obligation of m3core to help just a teeny tiny bit? Or, would you argue, I am obligated, if I am using Modula-3, to use the higher level interfaces, that already know about this? Well, ok, m3core did already know about, I fixed it only a few months ago, but then even the likes of sysutils is stuck? Another example, that may or may not be well exposed, is willingness/ability to set thread stack size. Mika mentions creation thousands of threads. 32bit kernel threads are going to be more limited here. Whereas 32bit user threads might be willing to create much smaller stacks, and 64 bit anything has essentially infinite address space for infinite stacks (but still beware working set, physical memory is not infinite). (Personally I have seen precious little code that cares about stack size, just seems to somehow get along, combined with the fact that the current Modula-3 pthread code very likely leaks on some platforms attempting to deal with stack size, makes me inclined to just rip out the code..but yeah..just fix the leak...) - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: mika at async.caltech.edu; m3devel at elegosoft.com Subject: RE: [M3devel] variations of waitpid..? Date: Thu, 1 Jan 2009 01:49:28 +0000 > If someone uses waitpid they get what they paid for. But someone is us -- m3core/libm3 (I think just m3core), sysutils, and then cm3 uses them. I guess there is a point that this "grand new interface" SchedulerPosix.DoesWaitPidYield has precious few users. (It isn't grand. It takes no parameters and just returns a boolean, hardcoded, depending on thread library.) m3core now (today) uses it internally -- no need for a public interface. Sysutils can't use it until the baseline m3core is newer, so arguably, not a user. Instead (today) sysutils uses m3core's m3makefiles to decide the value. Heck, waitpid is therefore only used internally by m3core, and sysutils. If sysutils could be (partly) merged into m3core, then m3core's waitpid need not be public. - Jay > CC: mika > From: hosking > To: jay > Subject: Re: [M3devel] variations of waitpid..? > Date: Thu, 1 Jan 2009 12:29:24 +1100 > > If someone uses waitpid they get what they paid for. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Jan 2 22:28:04 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 02 Jan 2009 16:28:04 -0500 Subject: [M3devel] Modula-3 auto keyword upcase In-Reply-To: <495D8FB9.6030800@bellsouth.net> References: <495D8FB9.6030800@bellsouth.net> Message-ID: <495E4076.1E75.00D7.1@scires.com> Martin: I use CRiSP. http://www.crisp.com/ If you want to try it, I can provide you with my Modula-3 keyword and template files. Regards, Randy >>> Martin Bishop 1/1/2009 10:53 PM >>> I use the Modula-3 elisp code for Emacs to edit Modula-3 source, but it's somewhat annoying having to hit TAB to complete keywords (otherwise I have to hold shift to type them out). I have used an Oberon mode for Emacs before, that would auto upcase the keywords. If you typed 'module' and then pressed space, it would become 'MODULE', etc. I tried to modify the code from the Oberon mode and add it to the Modula-3 mode, but I had no luck. Does anyone know of any Modula-3 elisp code that does this? Or is there another editor that is capable of this? I have NEdit and jEdit, both have Modula-3 highlighting support, but neither help in actually editing Modula-3 code. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Jan 2 22:41:37 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 02 Jan 2009 16:41:37 -0500 Subject: [M3devel] meaning of unsafe? In-Reply-To: References: Message-ID: <495E43A3.1E75.00D7.1@scires.com> Jay: Modula-3 has a very precise definition of what it means to have a safe or an UNSAFE module. See pages 59-61 (section 2.7 Unsafe Operations) of the "Green Book" (Systems Programming with Modula-3 edited by Greg Nelson). Bottom line is that if you don't use any features of the language that are deemed UNSAFE, your program can't cause unchecked runtime errors. Regards, Randy >>> Jay 1/2/2009 2:02 AM >>> Recent quote, that I haven't further investigated, made me realize some of my ignorance. I know that "unsafe" includes: taking address of local explicit free dealing with any untraced ref? Not sure. Questions are: is unsafe well statically enforced? and/or is safe well statically enforced? That is, should I remove unsafe "everywhere", as long as it compiles ok, it must be safe, and better, so leave it that way? And if it fails, put it back? Or do I need to think about it myself? I think for modules it might be brainless as stated -- put it in only where the compiler makes, and nowhere extra, since extra is a loss not a bonus. But for interfaces.. I think, again, ideal to remove it where you can, but that the compiler can't enforce it? At least where there is "external"? Maybe I should just reread that quote, and thing about it. Safe can code call unsafe code, but should not be able to do so with parameters that, indirectly, make the safe code unsafe. For example, I cannot safe call "free" in unsafe code on behalf of safe code, unless I am darn sure the data isn't referenced -- unless I am the garbage collector. Any pointer give to unsafe code by safe code must not be stored "long term" -- ie: in the heap or globals, because it could be a stack pointer. Unless, well, duh..ok, any VAR parameter or UNTRACED REF passed to unsafe code, what I just said, but traced refs can be held onto -- they are by definition not stack pointers. I guess, you know..programming C code that interacts with Modula-3 code..you realize the incompleteness of the C type system. Modula-3 has, let's say, var, traced ref, and untraced ref. C just has pointers. The compiler doesn't know any better, the programmer has to. If you imagine a Modula-3 to C header compiler..which I would like..you know, it outputs C headers that map FROM Modula-3 interfaces (instead of the usual hand translations in either direction), it would likely lose a lot of information and only be for special purpose use, unless, unlikely, not likely valuable, this problem was solved. Which..oh, this is interesting..I can see, to solve this, you'd need an "API" for storing pointers perhaps. Something perhaps to make sure the pointer is allowed to be stored like such. Not sure. But I suspect this "API" is related to the "checks" that the Modula-3 compiler generates...I really need to understand those... Generally this is easy, because generally things are "synchronous" -- generally the C code doesn't hold on to its parameters beyond the lifetime of itself -- doesn't store it in the heap or globally for other threads to use, and generally the Modula-3 code isn't busy freeing the parameters on another thread, in fact VAR parameters cannot be freed, they are on the stack, and traced refs can only be freed..if the garbage collector can't find any references to them..and then untraced refs require "discipline" both in the Modula-3 code and the C code, but again generally, saved by "synchronicity" -- C code doesn't hold on to them, Modula-3 code doesn't free them on another thread. Those scenarios are certainly possible, just not all that common, and as soon as you "escape" to safe Modula-3 code, not a possibility..no untraced refs.. About right? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jan 3 00:05:24 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 2 Jan 2009 23:05:24 +0000 Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer? Message-ID: I'd like to avoid using "long" and "ulong" anywhere. On Unix, they are always pointer sized. On Windows, they are always 32 bits. This divergence of meaning I think it renders it useless. I believe for pointer-sized integers, the right types are any of: unsigned: size_t, Word.T signed: INTEGER, ssize_t, ptrdiff_t For 32bit integers: int32_t and uint32_t, perhaps int. There is arguably some ambiguity if you consider 16bit platforms. Now, I noticed we have: INTERFACE Cstddef; size_t = Ctypes.unsigned_long; ssize_t = Ctypes.long; ptrdiff_t = Ctypes.long; I would like to change this, either to: 32bits: size_t = Ctypes.unsigned_int; ssize_t = Ctypes.int; ptrdiff_t = Ctypes.int; 64bits: size_t = Ctypes.unsigned_long_long; ssize_t = Ctypes.long_long; ptrdiff_t = Ctypes.long_long; or portable: size_t = Word.T; ssize_t = INTEGER; ptrdiff_t = INTEGER; but, my question then is, why isn't the portable version already in use? Especially for the signed types. I mean, you know, we have: 32bits/BasicCtypes: INTERFACE BasicCtypes; IMPORT Word, Long; TYPE (* the four signed integer types *) signed_char = [-16_7f-1 .. 16_7f]; short_int = [-16_7fff-1 .. 16_7fff]; int = [-16_7fffffff-1 .. 16_7fffffff]; long_int = [-16_7fffffff-1 .. 16_7fffffff]; question is, why aren't int and long_int INTEGER? 64bits/BasicCtypes: long_int = [-16_7fffffffffffffff -1 .. 16_7fffffffffffffff ]; long_long = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL]; why not INTEGER? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Jan 3 01:12:27 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 03 Jan 2009 01:12:27 +0100 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: References: Message-ID: <20090103011227.vgpfs347400088sg@mail.elegosoft.com> An option to cm3 or a quake directive to use in the m3makefiles would suffice in my opinion (and be a great improvement). Olaf Quoting Jay : > > Should the user/kernel thread chose be available: > > > On the command line to a Modula-3 executable (or even an executable > where main is in another language, but which static or dynamic > Modula-3 libs are used)? > > > Via a quake directive when building programs? > > > You know, imagine you have a bunch of Modula-3 programs and some but > not all use a very large number of threads and benefit from > userthreads. > > > Currently the chose is locked into m3core when it is built. > > > I understand (and anyone who likes the idea should understand) this > is not easy to achieve. > Well, at the very least, it is a tedious transform of the code, not > anything hard to understand, just not a small physical change. The > choice also has to be communicated very early in > "startup/initialization", since e.g. the garbage collector creates a > thread for itself during "startup/initialization" -- letting Main's > body call Scheduler.SetThreadImplementation(enum [UserThreads, > KernelThreads]) would not likely work, and not be provided. > > > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sat Jan 3 01:24:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 3 Jan 2009 11:24:34 +1100 Subject: [M3devel] FW: variations of waitpid..? In-Reply-To: References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> <20090102113257.me6vseyaskggssoc@mail.elegosoft.com> Message-ID: What OS is this leak on? I don't think it is anything in the Modula-3 wrappers to pthreads, but please confirm. On 3 Jan 2009, at 05:36, Jay wrote: > The pthreads code appears to leak for every thread created, as a > result of trying to set stack size. > I'll just fix it, once confirmed. > > Setting stack size is basically impossible all around. > Both by the user and by "the OS". > > By the user: > > If the user calls into any dynamically linked code he didn't write, > he doesn't > know what is needed, without a lot of testing, and it can change in > time. > > If the user so much as compiles with different flags or a different > compiler > or targeting a different platform, stack use will change. > > By the OS: > > Same thing -- the OS doesn't know how much stack any user will need. > > > Personally I generally practise and recommend minimizing stack usage > and using heap instead. However there are large tradeoffs in > perf and medium tradeoffs in debuggability (debuggers do a better > job of immediately showing the contents of character arrays, instead > of pointers, which they don't follow automatically, at least cdb/ > ntsd/windbg, > not sure about the various gdb/dbx/visualstudio). > > > A terrible pattern imho, is stuff like > char FilePath[some large maximum like 200 or 1000]; > > They use up the stack fast, are usually wasteful over-allocations, > and sometimes > arbitrary capacity-limiting under-allocations. For paths in > particular, > Win32 advertises two maximums, one of which is wrong, the other of > which is > suspicous -- 260 and 32K. 32K isn't clearly correct due to the > availability of > relative opens. > Even if 32K is considered correct, it is way too much to allocate > "just in case". > Better to determine the actual needed size and allocate that. > (I think current Cygwin code does just this though -- blow up a > bunch of buffers to 32K.) > Imho. > > Oh, and the common Unix advertisement of 1024 is also perhaps wrong. > You know, what happens if I am using SMB to NT, or to another system > with a different max? > Do paths beyond 1024 get truncated, or unavailable, or overflow > buffers? > They can certainly exist. > I'll have to try it out sometime. > > In general on disk structures are all "relative" and have no limits > for full paths, > only usually for individual path elements. > > The stack is generally of relatively small capacity, and when it is > exhausted, > that is more difficult to detect and recover from, than heap or > addressspace > exhaustion. > > True, even heap and addresspace can run out, by either being "only" > 32bits, or > via fragmentation, and are difficult to recover from. > I personally don't defend against fragmentation, and it worries me > some. > It's maybe not a concern in Modula-3 due to compaction, however > compaction > seems also bad in that it requires larger contiguous memory. > Fragmentation is good. Fragmentation is bad.. > > - Jay > > > > > > Date: Fri, 2 Jan 2009 11:32:57 +0100 > > From: wagner@ > > To: m3devel@ > > Subject: Re: [M3devel] FW: variations of waitpid..? > > > > Quoting Jay: > > > > > (Personally I have seen precious little code that cares about > stack > > > size, just seems to somehow get along, combined with the fact that > > > the current Modula-3 pthread code very likely leaks on some > > > platforms attempting to deal with stack size, makes me inclined to > > > just rip out the code..but yeah..just fix the leak...) > > > > Please don't do that (remove the ability to set stack sizes). I know > > that for most of the programs I wrote years ago we had to adapt > stack > > sizes for threads carefully. That was with user threads though. > > > > Olaf > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jan 3 05:44:01 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 3 Jan 2009 04:44:01 +0000 Subject: [M3devel] FW: variations of waitpid..? In-Reply-To: <495E3E42.1E75.00D7.1@scires.com> References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> <495E3E42.1E75.00D7.1@scires.com> Message-ID: Perhaps, tangentially, we should strive to reduce stack usage in Trestle? Not as an alternative, granted. - Jay Date: Fri, 2 Jan 2009 16:18:40 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] FW: variations of waitpid..? Jay: Your comment about stack size rang a bell with me. I have had trouble in the past running out of stack space, most notably on HP-UX. Same program built on Windows usually did not suffer the same fate. I seem to recall the most stack space trouble was when a thread did anything with Trestle/FormsVBT etc. So, I added a command line switch to my program that let's you specify a multiplier for the stack size. During initialization, my programs read the command line switches and take appropriate action to increase the thread stack sizes before any threads are created. If you don't specify a stack size multiplier on the command line, I think I wound up using seven (7) as the default. Here is a code excerpt: IF stackMult > 1 THEN WITH default = Thread.GetDefaultStackSize(), desired = default * stackMult, increase = desired - default DO PutText("Increasing default stack size by a factor of " & Fmt.Int(stackMult) & " (" & Fmt.Int(default) & " >>> " & Fmt.Int(desired) & ").\n"); Thread.IncDefaultStackSize(increase); END; (* with *) WITH default = Thread.GetDefaultStackSize() DO PutText("Thread stacks are now " & Fmt.Int(default) & " bytes.\n"); END; (* with *) END; (* if *) Regards, Randy >>> Jay 12/31/2008 8:59 PM >>>[truncated just slightly..and probably will be again given more rambling..] ps: the internal use in m3core could be easily removed, just by compiling one branch of the if or the other.I just wanted them in the same file to keep similar code closer together. So it comes down that m3core does expose Uwaitpid.waitpid and Uexec.waitpid, and as long as they are...or as long as user threads exist..imho there is some obligation of m3core to expose perhaps surprising characteristics of its thread library. You might say the entire interface is already and has always been fully exposed in Thread.i3, but I don't believe it. User threads and kernel threads have too divergent too visible artifacts, that I don't think are previously exposed in the public interface. I claim it is somewhat "surprising", or at least important to know the detail of, whether or not waitpid yields to other threads. You know, I mean..let's say I am some really clever waitpid user and I really must use it. And I am using Modula-3 threads. And my child process is reading the output of Modula-3 threads. Aren't I kind of stuck? Isn't there /some/ obligation of m3core to help just a teeny tiny bit? Or, would you argue, I am obligated, if I am using Modula-3, to use the higher level interfaces, that already know about this? Well, ok, m3core did already know about, I fixed it only a few months ago, but then even the likes of sysutils is stuck? Another example, that may or may not be well exposed, is willingness/ability to set thread stack size. Mika mentions creation thousands of threads. 32bit kernel threads are going to be more limited here. Whereas 32bit user threads might be willing to create much smaller stacks, and 64 bit anything has essentially infinite address space for infinite stacks (but still beware working set, physical memory is not infinite). (Personally I have seen precious little code that cares about stack size, just seems to somehow get along, combined with the fact that the current Modula-3 pthread code very likely leaks on some platforms attempting to deal with stack size, makes me inclined to just rip out the code..but yeah..just fix the leak...) - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: mika at async.caltech.edu; m3devel at elegosoft.comSubject: RE: [M3devel] variations of waitpid..?Date: Thu, 1 Jan 2009 01:49:28 +0000 > If someone uses waitpid they get what they paid for. But someone is us -- m3core/libm3 (I think just m3core), sysutils, and then cm3 uses them. I guess there is a point that this "grand new interface" SchedulerPosix.DoesWaitPidYield has precious few users. (It isn't grand. It takes no parameters and just returns a boolean, hardcoded, depending on thread library.) m3core now (today) uses it internally -- no need for a public interface.Sysutils can't use it until the baseline m3core is newer, so arguably, not a user. Instead (today) sysutils uses m3core's m3makefiles to decide the value. Heck, waitpid is therefore only used internally by m3core, and sysutils.If sysutils could be (partly) merged into m3core, then m3core's waitpid need not be public. - Jay> CC: mika> From: hosking> To: jay> Subject: Re: [M3devel] variations of waitpid..?> Date: Thu, 1 Jan 2009 12:29:24 +1100> > If someone uses waitpid they get what they paid for. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eiserlohpp at yahoo.com Sat Jan 3 07:52:26 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Fri, 2 Jan 2009 22:52:26 -0800 (PST) Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer? Message-ID: <443283.92057.qm@web56804.mail.re3.yahoo.com> Jay, Please don't make size_t 128 bits in size. In "C" a long is specified by the language spec to be an integral type big enough to hold a pointer. Longs in "C" may be bigger than a pointer, but they must be at least that size. NOTE: an int (integer) does not have that guarantee. In fact, I once programed on a platform (Amiga) that had two different compilers one used 16-bits and other 32 for their integers. You can imagine the difficulties. Windows machines, as you have been using, give an address space of 32 bits to user space. This is regardless of how much RAM it may actually have. I would expect that on a Win64 platform, pointers are 64 bits, and "long" is also 64 bits. On my AMD64_LINUX box, pointers are 64 bits, and therefore a long is 64, and a long long is 128. The system type size_t is 64 bits. If you attempt to map Cstddef.size_t to 128 bits it will not only break the syscall interfaces to the kernel, but also be a waste of space. >From that standpoint the type definitions size_t = Ctypes.unsigned_long; ..., etc. are correct. Please don't define size_t = Ctypes.unsigned_long_long; The "C" include files /usr/includes/bits/types.h /usr/includes/bits/typesizes.h play preprocessor games to ensure that the ssize_t are defined to use the "natural" word size. Other types get defined to fixed sizes (ie, _int32 must always be 32 bits) otherwise external interfaces (file formats, inodes, ..., etc) would be corrupted. For that reason explicitly sized types need to be defined. Actually, GNU/Modula-2 recently defined explictly sized types. Peter Eiserloh. Date: Fri, 2 Jan 2009 23:05:24 +0000 From: Jay Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer? To: m3devel , Tony Message-ID: Content-Type: text/plain; charset="iso-8859-1" I'd like to avoid using "long" and "ulong" anywhere. On Unix, they are always pointer sized. On Windows, they are always 32 bits. This divergence of meaning I think it renders it useless. I believe for pointer-sized integers, the right types are any of: unsigned: size_t, Word.T signed: INTEGER, ssize_t, ptrdiff_t For 32bit integers: int32_t and uint32_t, perhaps int. There is arguably some ambiguity if you consider 16bit platforms. Now, I noticed we have: INTERFACE Cstddef; size_t = Ctypes.unsigned_long; ssize_t = Ctypes.long; ptrdiff_t = Ctypes.long; I would like to change this, either to: 32bits: size_t = Ctypes.unsigned_int; ssize_t = Ctypes.int; ptrdiff_t = Ctypes.int; 64bits: size_t = Ctypes.unsigned_long_long; ssize_t = Ctypes.long_long; ptrdiff_t = Ctypes.long_long; or portable: size_t = Word.T; ssize_t = INTEGER; ptrdiff_t = INTEGER; but, my question then is, why isn't the portable version already in use? Especially for the signed types. I mean, you know, we have: 32bits/BasicCtypes: INTERFACE BasicCtypes; IMPORT Word, Long; TYPE (* the four signed integer types *) signed_char = [-16_7f-1 .. 16_7f]; short_int = [-16_7fff-1 .. 16_7fff]; int = [-16_7fffffff-1 .. 16_7fffffff]; long_int = [-16_7fffffff-1 .. 16_7fffffff]; question is, why aren't int and long_int INTEGER? 64bits/BasicCtypes: long_int = [-16_7fffffffffffffff -1 .. 16_7fffffffffffffff ]; long_long = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL]; why not INTEGER? +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Sat Jan 3 08:45:26 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 3 Jan 2009 07:45:26 +0000 Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer? In-Reply-To: <443283.92057.qm@web56804.mail.re3.yahoo.com> References: <443283.92057.qm@web56804.mail.re3.yahoo.com> Message-ID: Peter, Huh? Of course not. "long long" is always exactly 64 bits, except on systems where it doesn't exist at all. There isn't really any 128 bit integer type in widespread use, aside from multi precision arithmetic libraries and such. long on Windows is always 32bits, as I said. The pointer sized types are: size_t, ptrdiff_t, ssize_t, INTEGER, and any pointer Surely sizeof(long) == sizeof(void*) was considered for Win64, but rejected due to the wider spread source incompatibility it would have caused. Yes, I know, every other 64 bit system took a different route -- Alpha, AIX, Solaris, IRIX, Darwin -- but they all probably had far less code to deal with. I have also programmed with a 16bit int, but nobody seems to care about portability to that these days/decades/centuries. If folks here want to imagine Modula-3 is portable to such a system, with 16 bit INTEGER, I am willing to entertain discussion and maybe even code as to the ramifications..maybe.. - Jay> Date: Fri, 2 Jan 2009 22:52:26 -0800> From: eiserlohpp@> To: m3devel@> Subject: Re: [M3devel] long vs. INTEGER? ranges vs. word/integer?> > Jay,> > Please don't make size_t 128 bits in size. In "C" a> long is specified by the language spec to be an integral > type big enough to hold a pointer. Longs in "C" may be> bigger than a pointer, but they must be at least that size. > > NOTE: an int (integer) does not have that guarantee.> > In fact, I once programed on a platform (Amiga) that had> two different compilers one used 16-bits and other 32 for> their integers. You can imagine the difficulties.> > Windows machines, as you have been using, give an address> space of 32 bits to user space. This is regardless of how> much RAM it may actually have. I would expect that on a> Win64 platform, pointers are 64 bits, and "long" is also > 64 bits.> > On my AMD64_LINUX box, pointers are 64 bits, and therefore> a long is 64, and a long long is 128. The system type> size_t is 64 bits. If you attempt to map Cstddef.size_t> to 128 bits it will not only break the syscall interfaces> to the kernel, but also be a waste of space.> > From that standpoint the type definitions> size_t = Ctypes.unsigned_long;> ..., etc.> > are correct.> > Please don't define > size_t = Ctypes.unsigned_long_long;> > > The "C" include files> /usr/includes/bits/types.h> /usr/includes/bits/typesizes.h> > play preprocessor games to ensure that the ssize_t are> defined to use the "natural" word size. > > Other types get defined to fixed sizes (ie, _int32 must> always be 32 bits) otherwise external interfaces (file> formats, inodes, ..., etc) would be corrupted. For that> reason explicitly sized types need to be defined.> > Actually, GNU/Modula-2 recently defined explictly sized> types.> > > Peter Eiserloh.> > > > Date: Fri, 2 Jan 2009 23:05:24 +0000> From: Jay > Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer?> To: m3devel , Tony > Message-ID: > Content-Type: text/plain; charset="iso-8859-1"> > > I'd like to avoid using "long" and "ulong" anywhere.> On Unix, they are always pointer sized.> On Windows, they are always 32 bits.> > This divergence of meaning I think it renders it useless.> > I believe for pointer-sized integers, the right types are any of:> unsigned: size_t, Word.T> signed: INTEGER, ssize_t, ptrdiff_t> For 32bit integers: int32_t and uint32_t, perhaps int.> > There is arguably some ambiguity if you consider 16bit platforms.> > Now, I noticed we have:> INTERFACE Cstddef;> > size_t = Ctypes.unsigned_long; ssize_t = Ctypes.long; ptrdiff_t = Ctypes.long;> > I would like to change this, either to:> > 32bits:> size_t = Ctypes.unsigned_int; ssize_t = Ctypes.int; ptrdiff_t = Ctypes.int;> > 64bits:> size_t = Ctypes.unsigned_long_long; ssize_t = Ctypes.long_long; ptrdiff_t = Ctypes.long_long;> > or portable:> size_t = Word.T; ssize_t = INTEGER; ptrdiff_t = INTEGER;> but, my question then is, why isn't the portable version already in use?> Especially for the signed types.> > I mean, you know, we have:> > 32bits/BasicCtypes:> > INTERFACE BasicCtypes;> IMPORT Word, Long;> TYPE (* the four signed integer types *) signed_char = [-16_7f-1 .. 16_7f]; short_int = [-16_7fff-1 .. 16_7fff]; int = [-16_7fffffff-1 .. 16_7fffffff]; long_int = [-16_7fffffff-1 .. 16_7fffffff];> question is, why aren't int and long_int INTEGER?> > 64bits/BasicCtypes:> > long_int = [-16_7fffffffffffffff -1 .. 16_7fffffffffffffff ]; long_long = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];> > why not INTEGER?> > > > +--------------------------------------------------------+> | Peter P. Eiserloh |> +--------------------------------------------------------+> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jan 3 09:04:37 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 3 Jan 2009 08:04:37 +0000 Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer? In-Reply-To: <443283.92057.qm@web56804.mail.re3.yahoo.com> References: <443283.92057.qm@web56804.mail.re3.yahoo.com> Message-ID: Oh I should have read more closely to correct more.. > In "C" a> long is specified by the language spec to be an integral > type big enough to hold a pointer. Longs in "C" may be> bigger than a pointer, but they must be at least that size. No. This is very false.There is (are) the standards, and there is the practical reality, and neither agree with your assertion. In "C89", ANSI C prior to C9x, the integral types are: char -- of wierd/uncertain signedness unsigned char signed char short (aka short int aka signed short ? aka signed short int) unsigned short (aka unsigned short int) int (aka signed int) unsigned (aka unsigned int) long (aka long int aka signed long int) unsigned long (aka unsigned long int) limits.h #defines CHAR_BIT, the number of bits in a char (or signed char or unsigned char) CHAR_BIT must be at least 8. Practically speaking it is always exactly 8, but..perhaps not on a Cray. sizeof(char) == 1, by definition if char is more than 8 bits, then CHAR_BIT must be adjusted, not sizeof(char) sizeof(short) >= 2 sizeof(int) >= sizeof(short) sizeof(long) >= sizeof(int) sizeof(long) >= 4 There are some types size_t and ptrdiff_t that I'm not sure what the standard says. Something like, size_t can hold the index for any array. However, the standard doesn't like speak of address spaces and their sizes, so just what is the maximum index for an array, I don't know. Practically speaking, size_t and ptrdiff_t are the exact same size as a pointer. Practially speaking, all pointers are of the same size. Though that isn't clear in the standard as I understand. Practically speaking, all pointers roundtrip through any pointer type, as well as size_t or ptrdiff_t. There is no relationship between long and pointers, in the standard. Practically speaking: CHAR_BIT == 8 sizeof(short) == 2 sizeof(int) == 4 sizeof(long) == 4 in all 32bit and 64bit (and 16bit) Windows programming environments sizeof(long) == sizeof(void*) in most non-Windows programming environments C9x introduces several new types and typedefs. As I understand, many of the typedefs are in stdint.h, and many are optional. long long I presume is speced as: sizeof(long long) >= sizeof(long) sizeof(long long) >= 8 Practically speaking, sizeof(long long) == 8. stdint.h goes nuts with the obvious options. It defines things like: fast_intN_t -- signed type that is "fast" and at least N bits in size fast_uintN_t -- unsigned ditto least_intN_t -- smallest integer that is at leasrt N bits in size least_uintN_t -- unsigned ditto intN_t -- signed integer exactly N bits in size uintN_t -- usigned ditto intptr_t -- signed integer exactly the size of a pointer uintptr_t -- unsigned ditto Not every type is mandatory though, and "fast" is vague. Then, they go even further, they have #defines for the printf and scanf strings for each type..I think. At least they have a bunch of #defines to abstract printf/scanf, not sure they have every single one. Boom goes the combinatorial explosion. So, personally, I think this is overkill. I think you should have just the exact sized types, plus the pointer-sized types. Throw out the "least" and "fast" types. Printf/scanf is thornier. It does seem a real problem, with no pretty solution. When I am just printing for debugging purposes, I often just hardcode %u or %lu and cast my data. I usually don't care if I lose the upper 32 bits, if they are even there, when I am just debugging. Microsoft long ago introduced %I64u and %I64d, but everyone else use something else, I guess %llu and %lld for long long, or maybe %Lu and %Ld. "long long" and %ll and "least"/"fast" are all nice and abstract, but again, I think it is all overkill in terms of abstraction. As you said, persistance formats are a large concern. Persistance formats frequently guide in-memory representations. Furthermore, I theorize that the abstractions aren't all that useful for in-memory data either. If you want your capacity to grow as address space grows, use size_t. Otherwise, pick a "reasonable" type. uint32_t is almost always reasonably efficent and offers adequate capacity. If you aren't sure, well go with uint64_t, it is still /fairly/ efficient on current 32 bit systems, offers nearly infinite capacity, and is perfectly efficient on 64bit systems..and 32bit should be trending downward..maybe. 64bit is still memory-inefficient, so if you have large structs/arrays and certainly are comfy with fewer bits, use small. So..the decision isn't always trivial, but I still suspect using exactly sized types is plenty adequate, and that worrying about the other types is too much. gcc internally uses pairs of longs to portably represent 64 bits. And they also have "wide" integers -- the hosts widest integral type. I forget what they use them for, but I'm sure they are compatible with a 32 bit "wide" -- gcc is after all portable to a C compiler without long long, but probably not to a compiler with 16 bit int (unless maybe they use long everywhere in that situation? I don't know.) - Jay From: jay.krell at cornell.eduTo: eiserlohpp at yahoo.com; m3devel at elegosoft.comSubject: RE: [M3devel] long vs. INTEGER? ranges vs. word/integer?Date: Sat, 3 Jan 2009 07:45:26 +0000 Peter, Huh? Of course not. "long long" is always exactly 64 bits, except on systems where it doesn't exist at all. There isn't really any 128 bit integer type in widespread use, aside from multi precision arithmetic libraries and such. long on Windows is always 32bits, as I said. The pointer sized types are: size_t, ptrdiff_t, ssize_t, INTEGER, and any pointer Surely sizeof(long) == sizeof(void*) was considered for Win64, but rejected due to the wider spread source incompatibility it would have caused. Yes, I know, every other 64 bit system took a different route -- Alpha, AIX, Solaris, IRIX, Darwin -- but they all probably had far less code to deal with. I have also programmed with a 16bit int, but nobody seems to care about portability to that these days/decades/centuries. If folks here want to imagine Modula-3 is portable to such a system, with 16 bit INTEGER, I am willing to entertain discussion and maybe even code as to the ramifications..maybe.. - Jay> Date: Fri, 2 Jan 2009 22:52:26 -0800> From: eiserlohpp@> To: m3devel@> Subject: Re: [M3devel] long vs. INTEGER? ranges vs. word/integer?> > Jay,> > Please don't make size_t 128 bits in size. In "C" a> long is specified by the language spec to be an integral > type big enough to hold a pointer. Longs in "C" may be> bigger than a pointer, but they must be at least that size. > > NOTE: an int (integer) does not have that guarantee.> > In fact, I once programed on a platform (Amiga) that had> two different compilers one used 16-bits and other 32 for> their integers. You can imagine the difficulties.> > Windows machines, as you have been using, give an address> space of 32 bits to user space. This is regardless of how> much RAM it may actually have. I would expect that on a> Win64 platform, pointers are 64 bits, and "long" is also > 64 bits.> > On my AMD64_LINUX box, pointers are 64 bits, and therefore> a long is 64, and a long long is 128. The system type> size_t is 64 bits. If you attempt to map Cstddef.size_t> to 128 bits it will not only break the syscall interfaces> to the kernel, but also be a waste of space.> > From that standpoint the type definitions> size_t = Ctypes.unsigned_long;> ..., etc.> > are correct.> > Please don't define > size_t = Ctypes.unsigned_long_long;> > > The "C" include files> /usr/includes/bits/types.h> /usr/includes/bits/typesizes.h> > play preprocessor games to ensure that the ssize_t are> defined to use the "natural" word size. > > Other types get defined to fixed sizes (ie, _int32 must> always be 32 bits) otherwise external interfaces (file> formats, inodes, ..., etc) would be corrupted. For that> reason explicitly sized types need to be defined.> > Actually, GNU/Modula-2 recently defined explictly sized> types.> > > Peter Eiserloh.> > > > Date: Fri, 2 Jan 2009 23:05:24 +0000> From: Jay > Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer?> To: m3devel , Tony > Message-ID: > Content-Type: text/plain; charset="iso-8859-1"> > > I'd like to avoid using "long" and "ulong" anywhere.> On Unix, they are always pointer sized.> On Windows, they are always 32 bits.> > This divergence of meaning I think it renders it useless.> > I believe for pointer-sized integers, the right types are any of:> unsigned: size_t, Word.T> signed: INTEGER, ssize_t, ptrdiff_t> For 32bit integers: int32_t and uint32_t, perhaps int.> > There is arguably some ambiguity if you consider 16bit platforms.> > Now, I noticed we have:> INTERFACE Cstddef;> > size_t = Ctypes.unsigned_long; ssize_t = Ctypes.long; ptrdiff_t = Ctypes.long;> > I would like to change this, either to:> > 32bits:> size_t = Ctypes.unsigned_int; ssize_t = Ctypes.int; ptrdiff_t = Ctypes.int;> > 64bits:> size_t = Ctypes.unsigned_long_long; ssize_t = Ctypes.long_long; ptrdiff_t = Ctypes.long_long;> > or portable:> size_t = Word.T; ssize_t = INTEGER; ptrdiff_t = INTEGER;> but, my question then is, why isn't the portable version already in use?> Especially for the signed types.> > I mean, you know, we have:> > 32bits/BasicCtypes:> > INTERFACE BasicCtypes;> IMPORT Word, Long;> TYPE (* the four signed integer types *) signed_char = [-16_7f-1 .. 16_7f]; short_int = [-16_7fff-1 .. 16_7fff]; int = [-16_7fffffff-1 .. 16_7fffffff]; long_int = [-16_7fffffff-1 .. 16_7fffffff];> question is, why aren't int and long_int INTEGER?> > 64bits/BasicCtypes:> > long_int = [-16_7fffffffffffffff -1 .. 16_7fffffffffffffff ]; long_long = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];> > why not INTEGER?> > > > +--------------------------------------------------------+> | Peter P. Eiserloh |> +--------------------------------------------------------+> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.illig at gmx.de Sat Jan 3 10:05:58 2009 From: roland.illig at gmx.de (Roland Illig) Date: Sat, 03 Jan 2009 10:05:58 +0100 Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer? In-Reply-To: <443283.92057.qm@web56804.mail.re3.yahoo.com> References: <443283.92057.qm@web56804.mail.re3.yahoo.com> Message-ID: <495F2A76.7010508@gmx.de> Peter Eiserloh schrieb: > Jay, > > In "C" a > long is specified by the language spec to be an integral > type big enough to hold a pointer. Longs in "C" may be > bigger than a pointer, but they must be at least that size. That's wrong. There is nothing in the C99 standard that guarantees that. The only guarantee is that long is at least as large as int. If your assumption was true, there wouldn't have been the need to add intptr_t and uintptr_t to the language. Even size_t doesn't have to be as large as a pointer. It's perfectly ok to have a computer with a 64-bit address space, in which every object may be only 4 GB large. Then you would have sizeof(void *) == 8, and sizeof(size_t) == 4. Or take the old MS-DOS: sizeof(void *) == 4, sizeof(size_t) == 2. Roland From jay.krell at cornell.edu Sat Jan 3 13:02:23 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 3 Jan 2009 12:02:23 +0000 Subject: [M3devel] FW: variations of waitpid..? In-Reply-To: <495E3E42.1E75.00D7.1@scires.com> References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> <495E3E42.1E75.00D7.1@scires.com> Message-ID: Eek, it looks like Modula-3's default stack size is quite small, 3000 bytes on user threads, 4k on pthreads. Hm. - Jay From: jay.krell at cornell.eduTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] FW: variations of waitpid..?Date: Sat, 3 Jan 2009 04:44:01 +0000 Perhaps, tangentially, we should strive to reduce stack usage in Trestle?Not as an alternative, granted. - Jay Date: Fri, 2 Jan 2009 16:18:40 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] FW: variations of waitpid..? Jay: Your comment about stack size rang a bell with me. I have had trouble in the past running out of stack space, most notably on HP-UX. Same program built on Windows usually did not suffer the same fate. I seem to recall the most stack space trouble was when a thread did anything with Trestle/FormsVBT etc. So, I added a command line switch to my program that let's you specify a multiplier for the stack size. During initialization, my programs read the command line switches and take appropriate action to increase the thread stack sizes before any threads are created. If you don't specify a stack size multiplier on the command line, I think I wound up using seven (7) as the default. Here is a code excerpt: IF stackMult > 1 THEN WITH default = Thread.GetDefaultStackSize(), desired = default * stackMult, increase = desired - default DO PutText("Increasing default stack size by a factor of " & Fmt.Int(stackMult) & " (" & Fmt.Int(default) & " >>> " & Fmt.Int(desired) & ").\n"); Thread.IncDefaultStackSize(increase); END; (* with *) WITH default = Thread.GetDefaultStackSize() DO PutText("Thread stacks are now " & Fmt.Int(default) & " bytes.\n"); END; (* with *) END; (* if *) Regards, Randy >>> Jay 12/31/2008 8:59 PM >>>[truncated just slightly..and probably will be again given more rambling..] ps: the internal use in m3core could be easily removed, just by compiling one branch of the if or the other.I just wanted them in the same file to keep similar code closer together. So it comes down that m3core does expose Uwaitpid.waitpid and Uexec.waitpid, and as long as they are...or as long as user threads exist..imho there is some obligation of m3core to expose perhaps surprising characteristics of its thread library. You might say the entire interface is already and has always been fully exposed in Thread.i3, but I don't believe it. User threads and kernel threads have too divergent too visible artifacts, that I don't think are previously exposed in the public interface. I claim it is somewhat "surprising", or at least important to know the detail of, whether or not waitpid yields to other threads. You know, I mean..let's say I am some really clever waitpid user and I really must use it. And I am using Modula-3 threads. And my child process is reading the output of Modula-3 threads. Aren't I kind of stuck? Isn't there /some/ obligation of m3core to help just a teeny tiny bit? Or, would you argue, I am obligated, if I am using Modula-3, to use the higher level interfaces, that already know about this? Well, ok, m3core did already know about, I fixed it only a few months ago, but then even the likes of sysutils is stuck? Another example, that may or may not be well exposed, is willingness/ability to set thread stack size. Mika mentions creation thousands of threads. 32bit kernel threads are going to be more limited here. Whereas 32bit user threads might be willing to create much smaller stacks, and 64 bit anything has essentially infinite address space for infinite stacks (but still beware working set, physical memory is not infinite). (Personally I have seen precious little code that cares about stack size, just seems to somehow get along, combined with the fact that the current Modula-3 pthread code very likely leaks on some platforms attempting to deal with stack size, makes me inclined to just rip out the code..but yeah..just fix the leak...) - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: mika at async.caltech.edu; m3devel at elegosoft.comSubject: RE: [M3devel] variations of waitpid..?Date: Thu, 1 Jan 2009 01:49:28 +0000 > If someone uses waitpid they get what they paid for. But someone is us -- m3core/libm3 (I think just m3core), sysutils, and then cm3 uses them. I guess there is a point that this "grand new interface" SchedulerPosix.DoesWaitPidYield has precious few users. (It isn't grand. It takes no parameters and just returns a boolean, hardcoded, depending on thread library.) m3core now (today) uses it internally -- no need for a public interface.Sysutils can't use it until the baseline m3core is newer, so arguably, not a user. Instead (today) sysutils uses m3core's m3makefiles to decide the value. Heck, waitpid is therefore only used internally by m3core, and sysutils.If sysutils could be (partly) merged into m3core, then m3core's waitpid need not be public. - Jay> CC: mika> From: hosking> To: jay> Subject: Re: [M3devel] variations of waitpid..?> Date: Thu, 1 Jan 2009 12:29:24 +1100> > If someone uses waitpid they get what they paid for. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jan 3 13:14:02 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 3 Jan 2009 12:14:02 +0000 Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer? In-Reply-To: References: <443283.92057.qm@web56804.mail.re3.yahoo.com> Message-ID: Sorry, big mistakes, below: NOT sizeof(short) >= 2 NOT sizeof(long) >= 4 but rather sizeof(short) * CHAR_BIT >= 16sizeof(long) * CHAR_BIT >= 32 A conforming implementation, as I understand, could have: #define CHAR_BIT 32 sizeof(char) = sizeof(short) = sizeof(int) = sizeof(long) = 1 Though /practically/ speaking, CHAR_BIT is always 8 and what I said is true. You know..what is it..the Matlab model? Where everything is a 64 bit double with >= 32 bit mantissa, therefore everything could be a double? - Jay From: jay.krell at cornell.eduTo: eiserlohpp at yahoo.com; m3devel at elegosoft.comDate: Sat, 3 Jan 2009 08:04:37 +0000Subject: Re: [M3devel] long vs. INTEGER? ranges vs. word/integer? Oh I should have read more closely to correct more.. > In "C" a> long is specified by the language spec to be an integral > type big enough to hold a pointer. Longs in "C" may be> bigger than a pointer, but they must be at least that size. No. This is very false.There is (are) the standards, and there is the practical reality,and neither agree with your assertion. In "C89", ANSI C prior to C9x, the integral types are: char -- of wierd/uncertain signedness unsigned char signed char short (aka short int aka signed short ? aka signed short int) unsigned short (aka unsigned short int) int (aka signed int) unsigned (aka unsigned int) long (aka long int aka signed long int) unsigned long (aka unsigned long int) limits.h #defines CHAR_BIT, the number of bits in a char (or signed char or unsigned char) CHAR_BIT must be at least 8.Practically speaking it is always exactly 8, but..perhaps not on a Cray. sizeof(char) == 1, by definition if char is more than 8 bits, then CHAR_BIT must be adjusted, not sizeof(char) sizeof(short) >= 2 sizeof(int) >= sizeof(short)sizeof(long) >= sizeof(int)sizeof(long) >= 4 There are some types size_t and ptrdiff_t that I'm not sure what the standard says.Something like, size_t can hold the index for any array.However, the standard doesn't like speak of address spaces and their sizes, so just what is the maximum index for an array, I don't know. Practically speaking, size_t and ptrdiff_t are the exact same size as a pointer.Practially speaking, all pointers are of the same size. Though that isn't clear in the standard as I understand.Practically speaking, all pointers roundtrip through any pointer type, as well as size_t or ptrdiff_t. There is no relationship between long and pointers, in the standard. Practically speaking:CHAR_BIT == 8sizeof(short) == 2sizeof(int) == 4sizeof(long) == 4 in all 32bit and 64bit (and 16bit) Windows programming environmentssizeof(long) == sizeof(void*) in most non-Windows programming environments C9x introduces several new types and typedefs.As I understand, many of the typedefs are in stdint.h, and many are optional. long long I presume is speced as:sizeof(long long) >= sizeof(long)sizeof(long long) >= 8 Practically speaking, sizeof(long long) == 8. stdint.h goes nuts with the obvious options.It defines things like: fast_intN_t -- signed type that is "fast" and at least N bits in size fast_uintN_t -- unsigned ditto least_intN_t -- smallest integer that is at leasrt N bits in size least_uintN_t -- unsigned ditto intN_t -- signed integer exactly N bits in size uintN_t -- usigned ditto intptr_t -- signed integer exactly the size of a pointer uintptr_t -- unsigned ditto Not every type is mandatory though, and "fast" is vague. Then, they go even further, they have #defines for the printf and scanf strings for each type..I think. At least they have a bunch of #defines to abstract printf/scanf, not sure they have every single one.Boom goes the combinatorial explosion. So, personally, I think this is overkill. I think you should have just the exact sized types, plus the pointer-sized types.Throw out the "least" and "fast" types. Printf/scanf is thornier.It does seem a real problem, with no pretty solution. When I am just printing for debugging purposes, I often just hardcode %u or %lu and cast my data. I usually don't care if I lose the upper 32 bits, if they are even there, when I am just debugging. Microsoft long ago introduced %I64u and %I64d, but everyone else use something else, I guess %llu and %lld for long long, or maybe %Lu and %Ld. "long long" and %ll and "least"/"fast" are all nice and abstract, but again, I think it is all overkill in terms of abstraction. As you said, persistance formats are a large concern.Persistance formats frequently guide in-memory representations.Furthermore, I theorize that the abstractions aren't all that useful for in-memory data either.If you want your capacity to grow as address space grows, use size_t.Otherwise, pick a "reasonable" type.uint32_t is almost always reasonably efficent and offers adequate capacity.If you aren't sure, well go with uint64_t, it is still /fairly/ efficient on current 32 bit systems, offers nearly infinite capacity, and is perfectly efficient on 64bit systems..and 32bit should be trending downward..maybe.64bit is still memory-inefficient, so if you have large structs/arrays and certainly are comfy with fewer bits, use small. So..the decision isn't always trivial, but I still suspect using exactly sized types is plenty adequate, and that worrying about the other types is too much. gcc internally uses pairs of longs to portably represent 64 bits.And they also have "wide" integers -- the hosts widest integral type.I forget what they use them for, but I'm sure they are compatible with a 32 bit "wide" -- gcc is after all portable to a C compiler without long long, but probably not to a compiler with 16 bit int (unless maybe they use long everywhere in that situation? I don't know.) - Jay From: jay.krell at cornell.eduTo: eiserlohpp at yahoo.com; m3devel at elegosoft.comSubject: RE: [M3devel] long vs. INTEGER? ranges vs. word/integer?Date: Sat, 3 Jan 2009 07:45:26 +0000 Peter, Huh? Of course not. "long long" is always exactly 64 bits, except on systems where it doesn't exist at all. There isn't really any 128 bit integer type in widespread use, aside from multi precision arithmetic libraries and such. long on Windows is always 32bits, as I said. The pointer sized types are: size_t, ptrdiff_t, ssize_t, INTEGER, and any pointer Surely sizeof(long) == sizeof(void*) was considered for Win64, but rejected due to the wider spread source incompatibility it would have caused. Yes, I know, every other 64 bit system took a different route -- Alpha, AIX, Solaris, IRIX, Darwin -- but they all probably had far less code to deal with. I have also programmed with a 16bit int, but nobody seems to care about portability to that these days/decades/centuries. If folks here want to imagine Modula-3 is portable to such a system, with 16 bit INTEGER, I am willing to entertain discussion and maybe even code as to the ramifications..maybe.. - Jay> Date: Fri, 2 Jan 2009 22:52:26 -0800> From: eiserlohpp@> To: m3devel@> Subject: Re: [M3devel] long vs. INTEGER? ranges vs. word/integer?> > Jay,> > Please don't make size_t 128 bits in size. In "C" a> long is specified by the language spec to be an integral > type big enough to hold a pointer. Longs in "C" may be> bigger than a pointer, but they must be at least that size. > > NOTE: an int (integer) does not have that guarantee.> > In fact, I once programed on a platform (Amiga) that had> two different compilers one used 16-bits and other 32 for> their integers. You can imagine the difficulties.> > Windows machines, as you have been using, give an address> space of 32 bits to user space. This is regardless of how> much RAM it may actually have. I would expect that on a> Win64 platform, pointers are 64 bits, and "long" is also > 64 bits.> > On my AMD64_LINUX box, pointers are 64 bits, and therefore> a long is 64, and a long long is 128. The system type> size_t is 64 bits. If you attempt to map Cstddef.size_t> to 128 bits it will not only break the syscall interfaces> to the kernel, but also be a waste of space.> > From that standpoint the type definitions> size_t = Ctypes.unsigned_long;> ..., etc.> > are correct.> > Please don't define > size_t = Ctypes.unsigned_long_long;> > > The "C" include files> /usr/includes/bits/types.h> /usr/includes/bits/typesizes.h> > play preprocessor games to ensure that the ssize_t are> defined to use the "natural" word size. > > Other types get defined to fixed sizes (ie, _int32 must> always be 32 bits) otherwise external interfaces (file> formats, inodes, ..., etc) would be corrupted. For that> reason explicitly sized types need to be defined.> > Actually, GNU/Modula-2 recently defined explictly sized> types.> > > Peter Eiserloh.> > > > Date: Fri, 2 Jan 2009 23:05:24 +0000> From: Jay > Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer?> To: m3devel , Tony > Message-ID: > Content-Type: text/plain; charset="iso-8859-1"> > > I'd like to avoid using "long" and "ulong" anywhere.> On Unix, they are always pointer sized.> On Windows, they are always 32 bits.> > This divergence of meaning I think it renders it useless.> > I believe for pointer-sized integers, the right types are any of:> unsigned: size_t, Word.T> signed: INTEGER, ssize_t, ptrdiff_t> For 32bit integers: int32_t and uint32_t, perhaps int.> > There is arguably some ambiguity if you consider 16bit platforms.> > Now, I noticed we have:> INTERFACE Cstddef;> > size_t = Ctypes.unsigned_long; ssize_t = Ctypes.long; ptrdiff_t = Ctypes.long;> > I would like to change this, either to:> > 32bits:> size_t = Ctypes.unsigned_int; ssize_t = Ctypes.int; ptrdiff_t = Ctypes.int;> > 64bits:> size_t = Ctypes.unsigned_long_long; ssize_t = Ctypes.long_long; ptrdiff_t = Ctypes.long_long;> > or portable:> size_t = Word.T; ssize_t = INTEGER; ptrdiff_t = INTEGER;> but, my question then is, why isn't the portable version already in use?> Especially for the signed types.> > I mean, you know, we have:> > 32bits/BasicCtypes:> > INTERFACE BasicCtypes;> IMPORT Word, Long;> TYPE (* the four signed integer types *) signed_char = [-16_7f-1 .. 16_7f]; short_int = [-16_7fff-1 .. 16_7fff]; int = [-16_7fffffff-1 .. 16_7fffffff]; long_int = [-16_7fffffff-1 .. 16_7fffffff];> question is, why aren't int and long_int INTEGER?> > 64bits/BasicCtypes:> > long_int = [-16_7fffffffffffffff -1 .. 16_7fffffffffffffff ]; long_long = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];> > why not INTEGER?> > > > +--------------------------------------------------------+> | Peter P. Eiserloh |> +--------------------------------------------------------+> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stsp at elego.de Sat Jan 3 13:41:52 2009 From: stsp at elego.de (Stefan Sperling) Date: Sat, 3 Jan 2009 13:41:52 +0100 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> <20090101114139.GC10003@jack.stsp.name> Message-ID: <20090103124152.GA25002@jack.stsp.name> On Thu, Jan 01, 2009 at 07:45:44PM +0000, Jay wrote: > > What do you mean by "bootstrap binaries"? > > There are a variety of ways to get a usable system. > > > There is > [1]http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-I386_OP > ENBSD-1.tar.gz > extract it (tar zxf ...) > cd into it (cd ...) > add -lm and -lpthread to the link line > make > mkdir -p /usr/local/cm3/bin > mv cm3 /usr/local/cm3/bin > export PATH=$PATH:/usr/local/cm3/bin > export CM3_ROOT=/usr/src/cm3 or whatever > export CVSROOT=:ext:stefan at m3.elegosoft.com:/usr/cvs > cvs -z3 checkout cm3 > cd /usr/src/scripts/python > ./do-cm3-front.py buildship Thanks. I've tried that, and the ./do-cm3-front.py buildship step fails with: cd . && cd gcc && gmake CC="gcc" CFLAGS="-g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a _m3.log cd . && cd gcc && gmake CC="gcc" CFLAGS="-g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a _m3.log TARGET_CPU_DEFAULT="" \ HEADERS="auto-host.h ansidecl.h" DEFINES="" \ /bin/sh ../../gcc/gcc/mkconfig.sh bconfig.h gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc/gcc -I../../gcc/gcc/build -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I/home/stsp/src/cm3/m3-sys/m3cc/I386_OPENBSD/./gmp -I/home/stsp/src/cm3/m3-sys/m3cc/gcc/gmp -I/home/stsp/src/cm3/m3-sys/m3cc/I386_OPENBSD/./mpfr -I/home/stsp/src/cm3/m3-sys/m3cc/gcc/mpfr -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/local/include -o build/errors.o ../../gcc/gcc/errors.c build/genmodes > tmp-modes.c /bin/sh: build/genmodes: not found gmake: *** [s-modes] Error 127 "/home/stsp/src/cm3/m3-sys/m3cc/src/m3makefile", line 378: quake runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2 --procedure-- -line- -file--- cp_if -- postcp 378 /home/stsp/src/cm3/m3-sys/m3cc/src/m3makefile include_dir 444 /home/stsp/src/cm3/m3-sys/m3cc/src/m3makefile 8 /home/stsp/src/cm3/m3-sys/m3cc/I386_OPENBSD/m3make.args Fatal Error: package build failed *** execution of [, ] failed *** Stefan From eiserlohpp at yahoo.com Sat Jan 3 13:50:53 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sat, 3 Jan 2009 04:50:53 -0800 (PST) Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer? Message-ID: <83996.89296.qm@web56807.mail.re3.yahoo.com> Hi Jay, Sorry, for not speaking up earlier, I have been lurking for the last ten years. The last thing that got me really interested was the discussion about NEW() returning either NULL, or a checked runtime exception on failure to allocate memory. Okay, I wrote a test program. You are right sizeof(long) == sizeof(long long) equals 8 bytes (64 bits). So, I looked it up in the "C A Reference Manual" (CARM) 4th edition. It has been over ten years since I last looked at it. I have been corrected and educated. Sorry about discussing a foreign language, but ... To quote from page 120 (5.3): The size of a pointer is implementation dependent and in some cases varies depending on the type of the object pointed to. For example, data pointers may be shorter or longer than function pointers (section 6.1.5). There is not necessarily any relationship between pointer sizes and the size of any integer type, although it is common to assume that type _long_ is at least as large as any pointer type. Page 123 (5.3.3): 1 - Pointers are often not the same size as _int_, and sometimes not the same size as _long_. Sometimes their size is a compiler option. 2 - Character and void * pointers can be larger that other kinds of pointers, or may use a representation that is incompatible with other kinds of pointers. 3 - Function pointers and data pointer may have significantly different representations, including different sizes. Page 292 (11.1) Type _size_t_ is the unsigned integral type of the result of the sizeof operator -- probably _unsigned long_; pre-ISO implementations often use the (unsigned) type _int_ for this purpose. To paraphrase both Nelson (SPWM3) and Harbison (Modula-3). When doing a LOOPHOLE(e,T), ensure that BITSIZE(e) equals BITSIZE(T). In addition, -(x,y : ADDRESS) : INTEGER The SPWM3 does not have a LONGINT, but we now do as of a few months ago. The above operation on addresses implies that the difference between ANY two addresses can be represented in an INTEGER, with the further implication that an ADDRESS can be represented in an INTEGER (i.e., a size_t is an INTEGER). [Roland] So MS-DOS used a size_t of 2, but void* was 4, wow, that sure sounds broken. 64 KB is the maximum size of an object in memory. Thank god, we don't use MS-DOS anymore. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Sat Jan 3 16:21:23 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 3 Jan 2009 15:21:23 +0000 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: <20090103124152.GA25002@jack.stsp.name> References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> <20090101114139.GC10003@jack.stsp.name> <20090103124152.GA25002@jack.stsp.name> Message-ID: Please try export OMIT_GCC=yes. - Jay> Date: Sat, 3 Jan 2009 13:41:52 +0100> From: stsp at elego.de> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] I386_OPENBSD uploaded-archives> > On Thu, Jan 01, 2009 at 07:45:44PM +0000, Jay wrote:> > > > What do you mean by "bootstrap binaries"?> > > > There are a variety of ways to get a usable system.> > > > > > There is> > [1]http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-I386_OP> > ENBSD-1.tar.gz> > extract it (tar zxf ...)> > cd into it (cd ...)> > add -lm and -lpthread to the link line> > make> > mkdir -p /usr/local/cm3/bin> > mv cm3 /usr/local/cm3/bin> > export PATH=$PATH:/usr/local/cm3/bin> > export CM3_ROOT=/usr/src/cm3 or whatever> > export CVSROOT=:ext:stefan at m3.elegosoft.com:/usr/cvs> > cvs -z3 checkout cm3> > cd /usr/src/scripts/python> > ./do-cm3-front.py buildship> > Thanks. I've tried that, and the ./do-cm3-front.py buildship step fails with:> > cd . && cd gcc && gmake CC="gcc" CFLAGS="-g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a _m3.log> cd . && cd gcc && gmake CC="gcc" CFLAGS="-g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a _m3.log> TARGET_CPU_DEFAULT="" \> HEADERS="auto-host.h ansidecl.h" DEFINES="" \> /bin/sh ../../gcc/gcc/mkconfig.sh bconfig.h> gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc/gcc -I../../gcc/gcc/build -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I/home/stsp/src/cm3/m3-sys/m3cc/I386_OPENBSD/./gmp -I/home/stsp/src/cm3/m3-sys/m3cc/gcc/gmp -I/home/stsp/src/cm3/m3-sys/m3cc/I386_OPENBSD/./mpfr -I/home/stsp/src/cm3/m3-sys/m3cc/gcc/mpfr -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/local/include -o build/errors.o ../../gcc/gcc/errors.c> build/genmodes > tmp-modes.c> /bin/sh: build/genmodes: not found> gmake: *** [s-modes] Error 127> "/home/stsp/src/cm3/m3-sys/m3cc/src/m3makefile", line 378: quake runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2> > --procedure-- -line- -file---> cp_if -- > postcp 378 /home/stsp/src/cm3/m3-sys/m3cc/src/m3makefile> include_dir 444 /home/stsp/src/cm3/m3-sys/m3cc/src/m3makefile> 8 /home/stsp/src/cm3/m3-sys/m3cc/I386_OPENBSD/m3make.args> > Fatal Error: package build failed> *** execution of [, ] failed ***> > > Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From stsp at elego.de Sat Jan 3 16:27:24 2009 From: stsp at elego.de (Stefan Sperling) Date: Sat, 3 Jan 2009 16:27:24 +0100 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> <20090101114139.GC10003@jack.stsp.name> <20090103124152.GA25002@jack.stsp.name> Message-ID: <20090103152724.GC25002@jack.stsp.name> On Sat, Jan 03, 2009 at 03:21:23PM +0000, Jay wrote: > > Please try export OMIT_GCC=yes. No dice: new exporters -> recompiling SchedulerPosix.i3 /bin/sh: m3cg: not found m3_backend => 127 m3cc (aka cm3cg) failed compiling: SchedulerPosix.ic new exporters -> recompiling ThreadF.i3 /bin/sh: m3cg: not found m3_backend => 127 m3cc (aka cm3cg) failed compiling: ThreadF.ic new exporters -> recompiling ThreadInternal.i3 /bin/sh: m3cg: not found m3_backend => 127 m3cc (aka cm3cg) failed compiling: ThreadInternal.ic new exporters -> recompiling Time.i3 /bin/sh: m3cg: not found m3_backend => 127 m3cc (aka cm3cg) failed compiling: Time.ic new exporters -> recompiling Tick.i3 /bin/sh: m3cg: not found m3_backend => 127 m3cc (aka cm3cg) failed compiling: Tick.ic new exporters -> recompiling Date.i3 /bin/sh: m3cg: not found m3_backend => 127 m3cc (aka cm3cg) failed compiling: Date.ic new exporters -> recompiling Text.i3 /bin/sh: m3cg: not found m3_backend => 127 m3cc (aka cm3cg) failed compiling: Text.ic compilation failed => not building library "libm3core.a" Fatal Error: package build failed *** execution of [, ] failed *** Stefan From jay.krell at cornell.edu Sat Jan 3 16:30:38 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 3 Jan 2009 15:30:38 +0000 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: <20090103152724.GC25002@jack.stsp.name> References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> <20090101114139.GC10003@jack.stsp.name> <20090103124152.GA25002@jack.stsp.name> <20090103152724.GC25002@jack.stsp.name> Message-ID: Both the "min" and "std" archives should have cm3cg. Wherever you extracted the archive, did you put its bin directory in $PATH? ie: are you running cm3 by full path or via $PATH? - Jay> Date: Sat, 3 Jan 2009 16:27:24 +0100> From: stsp at elego.de> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] I386_OPENBSD uploaded-archives> > On Sat, Jan 03, 2009 at 03:21:23PM +0000, Jay wrote:> > > > Please try export OMIT_GCC=yes.> > No dice:> > new exporters -> recompiling SchedulerPosix.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: SchedulerPosix.ic> new exporters -> recompiling ThreadF.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: ThreadF.ic> new exporters -> recompiling ThreadInternal.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: ThreadInternal.ic> new exporters -> recompiling Time.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Time.ic> new exporters -> recompiling Tick.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Tick.ic> new exporters -> recompiling Date.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Date.ic> new exporters -> recompiling Text.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Text.ic> compilation failed => not building library "libm3core.a"> Fatal Error: package build failed> *** execution of [, ] failed ***> > > Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jan 3 16:59:42 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 3 Jan 2009 15:59:42 +0000 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: <20090103152724.GC25002@jack.stsp.name> References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> <20090101114139.GC10003@jack.stsp.name> <20090103124152.GA25002@jack.stsp.name> <20090103152724.GC25002@jack.stsp.name> Message-ID: > Both the "min" and "std" archives should have cm3cg. Confirmed at least for min: C:\net\modula3>lzma -d cm3-min-I386_OPENBSD-d5.7.0.tar.lzma C:\net\modula3>tar tf cm3-min-I386_OPENBSD-d5.7.0.tar | morecm3-min-I386_OPENBSD-d5.7.0cm3-min-I386_OPENBSD-d5.7.0/bincm3-min-I386_OPENBSD-d5.7.0/bin/cm3cm3-min-I386_OPENBSD-d5.7.0/bin/cm3cgcm3-min-I386_OPENBSD-d5.7.0/bin/mklibcm3-min-I386_OPENBSD-d5.7.0/bin/I386_OPENBSDcm3-min-I386_OPENBSD-d5.7.0/bin/Unix.commoncm3-min-I386_OPENBSD-d5.7.0/bin/cm3cfg.common I guess all that probing I put in (and that I use all the time, doing cross builds) MIGHT confuse things. You can look in cm3cfg.common for a big nested loop and remove it all and let it fall back to just running "cm3cg", whatever is first in $PATH. - Jay From: jay.krell at cornell.eduTo: stsp at elego.deCC: m3devel at elegosoft.comSubject: RE: [M3devel] I386_OPENBSD uploaded-archivesDate: Sat, 3 Jan 2009 15:30:38 +0000 Both the "min" and "std" archives should have cm3cg.Wherever you extracted the archive, did you put its bin directory in $PATH?ie: are you running cm3 by full path or via $PATH? - Jay> Date: Sat, 3 Jan 2009 16:27:24 +0100> From: stsp at elego.de> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] I386_OPENBSD uploaded-archives> > On Sat, Jan 03, 2009 at 03:21:23PM +0000, Jay wrote:> > > > Please try export OMIT_GCC=yes.> > No dice:> > new exporters -> recompiling SchedulerPosix.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: SchedulerPosix.ic> new exporters -> recompiling ThreadF.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: ThreadF.ic> new exporters -> recompiling ThreadInternal.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: ThreadInternal.ic> new exporters -> recompiling Time.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Time.ic> new exporters -> recompiling Tick.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Tick.ic> new exporters -> recompiling Date.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Date.ic> new exporters -> recompiling Text.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Text.ic> compilation failed => not building library "libm3core.a"> Fatal Error: package build failed> *** execution of [, ] failed ***> > > Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jan 3 17:07:05 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 3 Jan 2009 16:07:05 +0000 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: <20090103152724.GC25002@jack.stsp.name> References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> <20090101114139.GC10003@jack.stsp.name> <20090103124152.GA25002@jack.stsp.name> <20090103152724.GC25002@jack.stsp.name> Message-ID: I think I see the problem. In the file cm3cfg.common, find: % write("using m3cg in PATH (if there is one)\n") m3back = "@m3cg " & m3back_flags and change it to: % write("using cm3cg in PATH (if there is one)\n") m3back = "@cm3cg " & m3back_flags OR copy/rename/link the file to match, either way. You should be able to take the file I just commited to CVS, seconds ago. It works for me because the probing always finds my unshipped backends. This doesn't explain why you can't build in the m3cc directory. - Jay From: jay.krell at cornell.eduTo: stsp at elego.deCC: m3devel at elegosoft.comSubject: RE: [M3devel] I386_OPENBSD uploaded-archivesDate: Sat, 3 Jan 2009 15:59:42 +0000 > Both the "min" and "std" archives should have cm3cg.Confirmed at least for min: C:\net\modula3>lzma -d cm3-min-I386_OPENBSD-d5.7.0.tar.lzmaC:\net\modula3>tar tf cm3-min-I386_OPENBSD-d5.7.0.tar | morecm3-min-I386_OPENBSD-d5.7.0cm3-min-I386_OPENBSD-d5.7.0/bincm3-min-I386_OPENBSD-d5.7.0/bin/cm3cm3-min-I386_OPENBSD-d5.7.0/bin/cm3cgcm3-min-I386_OPENBSD-d5.7.0/bin/mklibcm3-min-I386_OPENBSD-d5.7.0/bin/I386_OPENBSDcm3-min-I386_OPENBSD-d5.7.0/bin/Unix.commoncm3-min-I386_OPENBSD-d5.7.0/bin/cm3cfg.commonI guess all that probing I put in (and that I use all the time, doing cross builds) MIGHT confuse things.You can look in cm3cfg.common for a big nested loop and remove it all and let it fall back to just running "cm3cg", whatever is first in $PATH. - Jay From: jay.krell at cornell.eduTo: stsp at elego.deCC: m3devel at elegosoft.comSubject: RE: [M3devel] I386_OPENBSD uploaded-archivesDate: Sat, 3 Jan 2009 15:30:38 +0000 Both the "min" and "std" archives should have cm3cg.Wherever you extracted the archive, did you put its bin directory in $PATH?ie: are you running cm3 by full path or via $PATH? - Jay> Date: Sat, 3 Jan 2009 16:27:24 +0100> From: stsp at elego.de> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] I386_OPENBSD uploaded-archives> > On Sat, Jan 03, 2009 at 03:21:23PM +0000, Jay wrote:> > > > Please try export OMIT_GCC=yes.> > No dice:> > new exporters -> recompiling SchedulerPosix.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: SchedulerPosix.ic> new exporters -> recompiling ThreadF.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: ThreadF.ic> new exporters -> recompiling ThreadInternal.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: ThreadInternal.ic> new exporters -> recompiling Time.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Time.ic> new exporters -> recompiling Tick.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Tick.ic> new exporters -> recompiling Date.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Date.ic> new exporters -> recompiling Text.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Text.ic> compilation failed => not building library "libm3core.a"> Fatal Error: package build failed> *** execution of [, ] failed ***> > > Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From stsp at elego.de Sat Jan 3 17:20:50 2009 From: stsp at elego.de (Stefan Sperling) Date: Sat, 3 Jan 2009 17:20:50 +0100 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> <20090101114139.GC10003@jack.stsp.name> <20090103124152.GA25002@jack.stsp.name> <20090103152724.GC25002@jack.stsp.name> Message-ID: <20090103162050.GD25002@jack.stsp.name> On Sat, Jan 03, 2009 at 03:30:38PM +0000, Jay wrote: > > Both the "min" and "std" archives should have cm3cg. I'm not using either of those. Your initial description of ho to build this mentioned those as alternatives, but it didn't sound like they were required. Maybe I didn't read carefully enough? I am using just these steps, as you outlined: fetch http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-I386_OPENBSD-1.tar.gz extract it (tar zxf ...) cd into it (cd ...) add -lm and -lpthread to the link line make mkdir -p /usr/local/cm3/bin mv cm3 /usr/local/cm3/bin export PATH=$PATH:/usr/local/cm3/bin export CM3_ROOT=/usr/src/cm3 or whatever export CVSROOT=:ext:stefan at m3.elegosoft.com:/usr/cvs cvs -z3 checkout cm3 cd /usr/src/scripts/python ./do-cm3-front.py buildship The very last step results in the error. The other steps succeed. > Wherever you extracted the archive, Which archive? > did you put its bin directory in $PATH? Following the steps above, I now have this: $ find /usr/local/cm3 /usr/local/cm3 /usr/local/cm3/bin /usr/local/cm3/bin/cm3 $ /usr/local/cm3/bin/cm3 -help Fatal Error: unable to locate configuration file, "cm3.cfg" $ Prior to running do-cm3-front.py, I run: export PATH=$PATH:/usr/local/cm3/bin > ie: are you running cm3 by full path or via $PATH? No idea. Whatever ./doc-m3-front.py buildship does, I guess. Stefan From jay.krell at cornell.edu Sat Jan 3 18:21:21 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 3 Jan 2009 17:21:21 +0000 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: <20090103162050.GD25002@jack.stsp.name> References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> <20090101114139.GC10003@jack.stsp.name> <20090103124152.GA25002@jack.stsp.name> <20090103152724.GC25002@jack.stsp.name> <20090103162050.GD25002@jack.stsp.name> Message-ID: Ok, well, you have to change something somewhere. If you can't build in m3cc, which we have no idea why not, and which I have you skip with export OMIT_GCC=yes, then at least get the cm3cg from the "min" or "std" archives and put it in the directory you will put cm3. The failure buildng m3cg/cm3cg/m3cc I cannot tell at all from below. Personally the problem I ran into twice is not having "gmake", but it looks like you got well past that. It doesn't fail as early or clearly as you might hope, but again, I think you got past that. - Jay> Date: Sat, 3 Jan 2009 17:20:50 +0100> From: stsp at elego.de> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] I386_OPENBSD uploaded-archives> > On Sat, Jan 03, 2009 at 03:30:38PM +0000, Jay wrote:> > > > Both the "min" and "std" archives should have cm3cg.> > I'm not using either of those. Your initial description of ho> to build this mentioned those as alternatives, but it didn't> sound like they were required. Maybe I didn't read carefully> enough?> > I am using just these steps, as you outlined:> > fetch http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-I386_OPENBSD-1.tar.gz> extract it (tar zxf ...) > cd into it (cd ...) > add -lm and -lpthread to the link line > make > mkdir -p /usr/local/cm3/bin > mv cm3 /usr/local/cm3/bin > export PATH=$PATH:/usr/local/cm3/bin > export CM3_ROOT=/usr/src/cm3 or whatever > export CVSROOT=:ext:stefan at m3.elegosoft.com:/usr/cvs > cvs -z3 checkout cm3 > cd /usr/src/scripts/python > ./do-cm3-front.py buildship > > The very last step results in the error.> The other steps succeed.> > > Wherever you extracted the archive,> > Which archive?> > > did you put its bin directory in $PATH?> > Following the steps above, I now have this:> > $ find /usr/local/cm3> /usr/local/cm3> /usr/local/cm3/bin> /usr/local/cm3/bin/cm3> $ /usr/local/cm3/bin/cm3 -help> > Fatal Error: unable to locate configuration file, "cm3.cfg"> > $> > Prior to running do-cm3-front.py, I run:> export PATH=$PATH:/usr/local/cm3/bin> > > ie: are you running cm3 by full path or via $PATH?> > No idea. Whatever ./doc-m3-front.py buildship does, I guess.> > Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 4 23:57:09 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 4 Jan 2009 22:57:09 +0000 Subject: [M3devel] determing current processor as string In-Reply-To: <20090102202255.9177E10D5D00@birch.elegosoft.com> References: <20090102202255.9177E10D5D00@birch.elegosoft.com> Message-ID: Thoughts here? Does the processor need to be "friendly" and "precise" including stuff not knowable at compile time (386 vs. 486 vs. 586, etc.), or would just "PowerPC" or "PPC" suffice? This question affects the Posix code. The Posix code tries to fetch some data at runtime from uname, and if that fails it falls back to built in data. Besides that the data is used in an unlikely error path, we bother carrying the data for all systems, which afaik is completely unnecessary. Once I confirm, I'll have Quake generate just what is needed. Similarly, I think cm3 should have -print-host or somesuch. Then the platform probing in sysinfo.sh could probably all go away. (Except for my idea of /cm3/bin/cm3.sh that calls /cm3/bin/target/cm3.) There is more here than just the processor. So some runtime code would remain, even if the processor became hard coded at compile time. You know, there are a few models here: Use data at runtime asis. e.g. GetEnv("PROCESSOR_ARCHITECTURE") and be done. Does that work on CE? Build-in the data at compile time and be done. This requires possibly a revisit for every port, but simple. It goes obsolete in time, but not quietly, it'd be an error in the Quake code when a new platform is introduced. Or, if the string is just then automatically ports, no revisit. This doesn't have the concern "does it work on CE?" or of Posix vs. Win32 portability. Use data at runtime to pick among compile time data. This is the current approach and it goes obsolete quietly in time. As well, these functions are never even used that I can see. Remove them? Or assume they might be used outside the cm3 tree? (That's quite a "line" in decision makiing. It's so much nicer to assume/know you have all the relevant code visible and therefore can make any change, provided you fix the client code, vs. having to assume there is "anything" out there.) - Jay> Date: Fri, 2 Jan 2009 21:22:55 +0000> To: m3commit@> From: jkrell@> Subject: [M3commit] CVS Update: cm3> > 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> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 5 02:12:56 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jan 2009 12:12:56 +1100 Subject: [M3devel] determing current processor as string In-Reply-To: References: <20090102202255.9177E10D5D00@birch.elegosoft.com> Message-ID: <3C9A9351-C543-44CE-A76F-B2490C423641@cs.purdue.edu> As far as I am concerned I think PPC or PowerPC is sufficient, since the gcc-based backend figures out what it needs. Why would the front- ends need to know? Perhaps I am missing your point... On 5 Jan 2009, at 09:57, Jay wrote: > Thoughts here? > > > Does the processor need to be "friendly" and "precise" including stuff > not knowable at compile time (386 vs. 486 vs. 586, etc.), > or would just "PowerPC" or "PPC" suffice? > > > This question affects the Posix code. > > > The Posix code tries to fetch some data at runtime from uname, and > if that fails > it falls back to built in data. Besides that the data is used in an > unlikely > error path, we bother carrying the data for all systems, which afaik > is completely unnecessary. Once I confirm, I'll have Quake generate > just what is needed. > > > Similarly, I think cm3 should have -print-host or somesuch. > Then the platform probing in sysinfo.sh could probably all go away. > (Except for my idea of /cm3/bin/cm3.sh that calls /cm3/bin/target/ > cm3.) > > > There is more here than just the processor. > So some runtime code would remain, even if the processor > became hard coded at compile time. > > You know, there are a few models here: > > Use data at runtime asis. > e.g. GetEnv("PROCESSOR_ARCHITECTURE") and be done. > Does that work on CE? > > Build-in the data at compile time and be done. > This requires possibly a revisit for every port, but simple. > It goes obsolete in time, but not quietly, it'd be an error in > the Quake code > when a new platform is introduced. > Or, if the string is just then automatically ports, no > revisit. > This doesn't have the concern "does it work on CE?" or > of Posix vs. Win32 portability. > > Use data at runtime to pick among compile time data. > This is the current approach and it goes obsolete quietly in > time. > > > As well, these functions are never even used that I can see. > Remove them? > Or assume they might be used outside the cm3 tree? > > (That's quite a "line" in decision makiing. It's so much nicer > to assume/know you have all the relevant code visible and therefore > can make any change, provided you fix the client code, vs. having to > assume there is "anything" out there.) > > - Jay > > > > Date: Fri, 2 Jan 2009 21:22:55 +0000 > > To: m3commit@ > > From: jkrell@ > > Subject: [M3commit] CVS Update: cm3 > > > > 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 5 02:23:45 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 5 Jan 2009 01:23:45 +0000 Subject: [M3devel] determing current processor as string In-Reply-To: <3C9A9351-C543-44CE-A76F-B2490C423641@cs.purdue.edu> References: <20090102202255.9177E10D5D00@birch.elegosoft.com> <3C9A9351-C543-44CE-A76F-B2490C423641@cs.purdue.edu> Message-ID: Sorry, I had a tangent there. The main question was regiarding a library feature, not a compiler issue. libm3/src/os/POSIX/OSConfigPosix.m3 libm3/src/os/POSIX/OSConfig.i3 libm3/src/os/WIN32/OSConfigWin32.m3 libm3/src/os/WIN32/OSConfig.i3 The bulk of this code is never used in the cm3 tree anyway. The tangent was regarding "cm3 -dump-host" or such, though it's more complicated maybe. Some hosts are "biarch" or "multiarch". - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] determing current processor as stringDate: Mon, 5 Jan 2009 12:12:56 +1100 As far as I am concerned I think PPC or PowerPC is sufficient, since the gcc-based backend figures out what it needs. Why would the front-ends need to know? Perhaps I am missing your point... On 5 Jan 2009, at 09:57, Jay wrote: Thoughts here? Does the processor need to be "friendly" and "precise" including stuffnot knowable at compile time (386 vs. 486 vs. 586, etc.),or would just "PowerPC" or "PPC" suffice? This question affects the Posix code. The Posix code tries to fetch some data at runtime from uname, and if that failsit falls back to built in data. Besides that the data is used in an unlikelyerror path, we bother carrying the data for all systems, which afaikis completely unnecessary. Once I confirm, I'll have Quake generatejust what is needed. Similarly, I think cm3 should have -print-host or somesuch.Then the platform probing in sysinfo.sh could probably all go away.(Except for my idea of /cm3/bin/cm3.sh that calls /cm3/bin/target/cm3.) There is more here than just the processor.So some runtime code would remain, even if the processorbecame hard coded at compile time. You know, there are a few models here: Use data at runtime asis. e.g. GetEnv("PROCESSOR_ARCHITECTURE") and be done. Does that work on CE? Build-in the data at compile time and be done. This requires possibly a revisit for every port, but simple. It goes obsolete in time, but not quietly, it'd be an error in the Quake code when a new platform is introduced. Or, if the string is just then automatically ports, no revisit. This doesn't have the concern "does it work on CE?" or of Posix vs. Win32 portability. Use data at runtime to pick among compile time data. This is the current approach and it goes obsolete quietly in time. As well, these functions are never even used that I can see.Remove them?Or assume they might be used outside the cm3 tree? (That's quite a "line" in decision makiing. It's so much nicerto assume/know you have all the relevant code visible and thereforecan make any change, provided you fix the client code, vs. having toassume there is "anything" out there.) - Jay> Date: Fri, 2 Jan 2009 21:22:55 +0000> To: m3commit@> From: jkrell@> Subject: [M3commit] CVS Update: cm3> > 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> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 5 03:17:47 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jan 2009 13:17:47 +1100 Subject: [M3devel] determing current processor as string In-Reply-To: References: <20090102202255.9177E10D5D00@birch.elegosoft.com> <3C9A9351-C543-44CE-A76F-B2490C423641@cs.purdue.edu> Message-ID: <02B4C407-A359-4358-A77E-F8C93EF07380@cs.purdue.edu> Hmm. I'm not sure I know what all the implications are to have an opinion. On 5 Jan 2009, at 12:23, Jay wrote: > Sorry, I had a tangent there. > The main question was regiarding a library feature, not a compiler > issue. > > > libm3/src/os/POSIX/OSConfigPosix.m3 > libm3/src/os/POSIX/OSConfig.i3 > libm3/src/os/WIN32/OSConfigWin32.m3 > libm3/src/os/WIN32/OSConfig.i3 > > The bulk of this code is never used in the cm3 tree anyway. > > The tangent was regarding "cm3 -dump-host" or such, though it's more > complicated maybe. Some hosts are "biarch" or "multiarch". > > - Jay > > > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] determing current processor as string > Date: Mon, 5 Jan 2009 12:12:56 +1100 > > > As far as I am concerned I think PPC or PowerPC is sufficient, since > the gcc-based backend figures out what it needs. Why would the > front-ends need to know? Perhaps I am missing your point... > > On 5 Jan 2009, at 09:57, Jay wrote: > > Thoughts here? > > > Does the processor need to be "friendly" and "precise" including stuff > not knowable at compile time (386 vs. 486 vs. 586, etc.), > or would just "PowerPC" or "PPC" suffice? > > > This question affects the Posix code. > > > The Posix code tries to fetch some data at runtime from uname, and > if that fails > it falls back to built in data. Besides that the data is used in an > unlikely > error path, we bother carrying the data for all systems, which afaik > is completely unnecessary. Once I confirm, I'll have Quake generate > just what is needed. > > > Similarly, I think cm3 should have -print-host or somesuch. > Then the platform probing in sysinfo.sh could probably all go away. > (Except for my idea of /cm3/bin/cm3.sh that calls /cm3/bin/target/ > cm3.) > > > There is more here than just the processor. > So some runtime code would remain, even if the processor > became hard coded at compile time. > > You know, there are a few models here: > > Use data at runtime asis. > e.g. GetEnv("PROCESSOR_ARCHITECTURE") and be done. > Does that work on CE? > > Build-in the data at compile time and be done. > This requires possibly a revisit for every port, but simple. > It goes obsolete in time, but not quietly, it'd be an error in > the Quake code > when a new platform is introduced. > Or, if the string is just then automatically ports, no > revisit. > This doesn't have the concern "does it work on CE?" or > of Posix vs. Win32 portability. > > Use data at runtime to pick among compile time data. > This is the current approach and it goes obsolete quietly in > time. > > > As well, these functions are never even used that I can see. > Remove them? > Or assume they might be used outside the cm3 tree? > > (That's quite a "line" in decision makiing. It's so much nicer > to assume/know you have all the relevant code visible and therefore > can make any change, provided you fix the client code, vs. having to > assume there is "anything" out there.) > > - Jay > > > > Date: Fri, 2 Jan 2009 21:22:55 +0000 > > To: m3commit@ > > From: jkrell@ > > Subject: [M3commit] CVS Update: cm3 > > > > 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 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 5 06:01:49 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 5 Jan 2009 05:01:49 +0000 Subject: [M3devel] race conditions under loose memory models/ compiler/processor reordering In-Reply-To: <20090105043713.783AD10D5E5B@birch.elegosoft.com> References: <20090105043713.783AD10D5E5B@birch.elegosoft.com> Message-ID: This code is very likely buggy, due to compiler or processor reordering, in a multithread environment, which we have. Prior to my change, it only required multiple threads to have a race condition. We need some sort of "barriers", as they are called. The writes to null_done must "divide" the code before it and the code after it. While they appear to, in the source, this is not likely guaranteed by the compiler or processor. It doesn't matter in a single threaded environment, but they don't generally exist. Or maybe an ability to mark variables as "volatile". In C, a fairly portable overkill fix is to sprinkle around volatile, but that generally makes the code more deoptimized than necessary. Volatile inhibits any reads or writes of the variable from being optimized away, and generally any reordering. However not all reads/writes need such treatment. Imagine a function that initialized a global on-demand, and then return that global plus itself -- the addition need only fetch the value once. What to do? VAR null_done := FALSE; null_stat: Ustat.struct_stat; null_fd: INTEGER; PROCEDURE IsDevNull(READONLY statbuf: Ustat.struct_stat): BOOLEAN RAISES {} = VAR result: INTEGER; BEGIN IF NOT null_done THEN null_fd := Unix.open(M3toC.FlatTtoS("/dev/null"), Unix.O_RDONLY, Unix.Mrwrwrw); IF null_fd < 0 THEN; null_done := TRUE; RETURN FALSE ELSE result := Ustat.fstat(null_fd, ADR(null_stat)); EVAL Unix.close(null_fd); IF result # 0 THEN null_fd := -1 END END; null_done := TRUE; END; RETURN null_fd >= 0 AND statbuf.st_rdev = null_stat.st_rdev END IsDevNull; - Jay> Date: Mon, 5 Jan 2009 05:37:13 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > 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..)> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Jan 5 11:49:15 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 05 Jan 2009 02:49:15 -0800 Subject: [M3devel] TEXT & etc. In-Reply-To: Your message of "Wed, 31 Dec 2008 15:52:06 CST." <495BE986.3030806@bellsouth.net> Message-ID: <200901051049.n05AnFrS077134@camembert.async.caltech.edu> Martin Bishop writes: .... >> > >This is somewhat off-topic, but is there a reason why you use CM3 as >opposed to PM3? I was under the impression that PM3 was "dead" and most >of it merged with CM3. I take it you got it backwards? You're asking why I use PM3? I use the following versions of Modula-3: -- on FreeBSD4 : PM3 (I also have CM3 for testing) -- PPC_DARWIN : CM3 (PM3 doesn't work) -- LINUXLIBC6 : CM3 (ditto) -- Windows (2000, XP, 2003 Server) : PM3 (Klagenfurt, very old) My main development and production platform is FreeBSD4, so I mainly use PM3. I used to use Windows 2003 for production as well, but hopefully that is now ended, and I can stick with FreeBSD (I'll run it in VMware on the win2003 system rather than deal with Windows). I have been trying to switch to CM3 for years, but for various reasons I have never managed to pull it off. At one time, CM3 didn't work on Cygwin (I don't care about that anymore, I hope, see above), and because I extensively use Pickles and Network Objects, I really do have to switch the production systems simultaneously from PM3 to CM3. Otherwise, there are the performance issues I raised in my previous email. Much of the code I have does run faster (sometimes a lot faster) under PM3; see some of my previous emails to m3devel on this issue. Most of the reasons I find switching from PM3 to CM3 difficult have, it turns out, something to do with the change in implementation of TEXT. That's why I had a modification to the text package attached to the email you responded to. Mika P.S. Let me add my voice to those calling for easy-to-install Modula-3 systems. I think it is just far too difficult to install the system, on many architecture/OS combinations. I think I am now unable to get one that works right on PPC_DARWIN... the bootstrap on the site is too old to compile the latest sources and it still has GC bugs in it... I know this is easy for people like Tony who do it all the time, but I come to it about once every six months and every time I think "oh no, not this again"... From hosking at cs.purdue.edu Mon Jan 5 11:47:15 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jan 2009 21:47:15 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20090105072548.AB46610D5D2A@birch.elegosoft.com> References: <20090105072548.AB46610D5D2A@birch.elegosoft.com> Message-ID: According to the language spec: The following operations are primarily used for address arithmetic: ADR (VAR x: Any) : ADDRESS infix + (x: ADDRESS, y:INTEGER) : ADDRESS infix - (x: ADDRESS, y:INTEGER) : ADDRESS infix - (x,y: ADDRESS) : INTEGER ADR(x) is the address of the variable x. The actual argument must be a designator but need not be writable. On 5 Jan 2009, at 08:25, Jay Krell wrote: > 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.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Jan 5 12:23:19 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 05 Jan 2009 03:23:19 -0800 Subject: [M3devel] variations of waitpid..? In-Reply-To: Your message of "Fri, 02 Jan 2009 19:15:48 GMT." Message-ID: <200901051123.n05BNJVB078904@camembert.async.caltech.edu> This is all really inside Process.Wait, right? On user threads: I can report (from having tried it) that changing the Wait to a small number doesn't really work. Once you have yielded, as far as the OS is concerned, you've already lost (at least on FreeBSD). The only thing that really works is busy waiting. The "correct" thing to do on unix is to catch SIGCHLD (SIGCLD?)... I started coding this up once, but I'm not sure I shared my code with anyone? I think it was Tony that pointed out that it was unnecessary with pthreads... Mika P.S. Happy New Year, everyone. Jay writes: >--_e7fe8011-c1fe-42de-b7fb-8ae54fa172fc_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >I didn't read that well -- the deadlock risk in sysutils is not there. >The bad perf is probably. >=20 >=20 >To be clear (esp. for folks that might not already know about this=2C >I didn't know about until fairly recently)=2C there are two options: >=20 >=20 >waitpid(pid=2C flags =3D 0) >move along >=20 >=20 >or >while (waitpid(pid=2C flags =3D nohang) !=3D 0) > sleep(some value) >=20 >=20 >The second is what sysutils was doing=2C and works=2C doesn't deadlock=2C i= >s deoptimized. > m3core/libm3 did this for a long time as well. When I complained about per= >f=2C it was pointed out to me. >=20 >The first has deadlock potential with userthreads=2C but is ok and faster w= >ith kernel threads. >=20 >=20 >waitpid(flags =3D nohang =3D don't actually wait=2C just get the exit code= >=2C if there is one) is a way to quickly poll if a process has ended=2C and= > if so=2C get its exit code. In Win32 there are two seperate functions GetE= >xitCodeProcess and WaitForSingleObject or WaitForMultipleObjects ("waiting"= > is generalized across files=2C processes=2C sockets=2C files=2C threads=2C= > semaphores=2C mutexes=2C events and more..but not critical sections..only = >kernel objects). These have a bug too. One particular exit code is reserved= > to mean "the process is still running"=2C but that is easily avoided by us= >ing Wait first. I have seen code get confused by this though. Wait also acc= >epts a timeout=2C 32bit unsigned milliseconds=2C including 0 and infinity= >=2C so also can be used to poll. Win32 also defines the exit code to be 32b= >its=2C whereas Posix only allows for 8 bits which can be an interop problem= >. Perl on Win32 truncates exit codes to 8 bits=2C very bad. Unhandled excep= >tions end up as "large" exit codes. >=20 >Anyway... >=20 >The problem with the polling approach=2C at least part of the problem=2C is= > that if the child process isn't done when waitpid is first called=2C but f= >inishes before sleep(whatever value) ends=2C we will still sleep for the fu= >ll "whatever value". You only really want to sleep until the child process = >is done=2C and no longer. >=20 >=20 >Making just the first sleep shorter might be a good idea. >You know=2C to handle processes that are short-lived=2C but not "zero" live= >d. >("zero" being the amount of time it takes for the code to proceed from fork= >/exec to waitpid=2C surely much smaller than a small sleep() but longer tha= >n no sleep). >=20 >=20 >Calling just waitpid(flags =3D 0) could deadlock if=2C for example=2C a par= >ent thread is writing to a child's stdin=2C and the child won't finish unti= >l the parent has written all that it needs to. The parent and child process= >=2C er=2C other threads in the parent process=2C need to be allowed to run = >concurrently=2C for the sake of at least some reasonable scenarios. >=20 >With kernelthreads=2C the implementation of waitpid knows about threads and= > will itself=2C in a sense=2C do the poll/sleep=2C but not exactly that -- = >it won't sleep beyond the child process finishing. >=20 >=20 >Hopefully this makes sense and lets more folks understand the problem. >=20 >=20 >What you can do=2C of course=2C is like: >=20 >=20 >if kernelthreads > waitpid(flags =3D 0) >else > while (waitpid(flags =3D nohang) !=3D 0) > sleep >=20 >=20 >and that is basically what the code looks like now. >=20 >The part "if kernelthreads" I propose be "if SchedulerPosix.DoesWaitPidYiel= >d()" >though a really direct "if Thread or Scheduler.KernelThreads" might be reas= >onable. >Up to folks then to decide what that implies.. >=20 > - Jay> Date: Fri=2C 2 Jan 2009 11:27:24 +0100> From: wagner at elegosoft.com>= > To: m3devel at elegosoft.com> Subject: Re: [M3devel] variations of waitpid..?= >> > Quoting Tony Hosking :> > > If someone uses wait= >pid they get what they paid for.> It is so long ago that we wrote those sys= >utils routines...> They have only ever be used in simple command line utili= >ties (like cm3)> without much concurrency=2C I think. If there is potential= > for deadlocks> and bad performance=2C we should at least document that in = >the interfaces.> > I am not up-to-date wrt. the M3 system interfaces and th= >reads> implementation: is there a way for a thread to wait for the exit cod= >e> of another process without blocking other threads? If so=2C I'll adapt> = >the sysutils code... If not=2C can we introduce such an interface in> m3cor= >e/libm3?> > Olaf> > > On 1 Jan 2009=2C at 06:24=2C Jay wrote:> >> >>> >> Yo= >u mean=2C this function is easy to misuse?> >>> People who declare their ow= >n <*EXTERNAL*>> >> Like waitpid exposed from m3core?> >>> >> waitpid is alr= >eady easy to misuse=2C on a userthread system=2C leading > >> to possible (= >though I think rare) deadlock.> >> It is easy to misuse on pthreads=2C lead= > "just" to bad performance=2C > >> and in fact I believe cm3 is doing this= >=2C via sysutils.> >> This at least guides you between two patterns of use= >=2C and fix the > >> perf of cm3/sysutils.> >>> >> On a userthread system= >=2C waitpid(pid=2C flags =3D 0) waits for the child > >> process=2C with al= >l parent threads suspended.> >> Generally I doubt the child depends on pare= >nt threads progressing=2C > >> but=2C yeah=2C that could deadlock=2C like i= >f a parent thread is waiting > >> to a file or stdin of the child=2C or rea= >ding a child's stdout.> >>> >> The various uses do waitpid(pid=2C flags =3D= > nohang) and then sleep and > >> try again.> >>> >> pthreads just uses wait= >pid(pid=2C flags =3D 0) and all threads keep running> > > > -- > Olaf Wagne= >r -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C= > 13355 Berlin=2C Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 86= >9 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch=E4ftsf=FChrer: = >Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB = >77719 | USt-IdNr: DE163214194> = > >--_e7fe8011-c1fe-42de-b7fb-8ae54fa172fc_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >I didn't read that well -- the deadlock risk in sysutils is not there.
>The bad perf is probably.
> =3B
> =3B
>To be clear (esp. for folks that might not already know about this=2C
>I didn't know about until fairly recently)=2C there are two options:
> =3B
> =3B
>waitpid(pid=2C flags =3D 0)
>move along
> =3B
> =3B
>or
>while (waitpid(pid=2C flags =3D nohang) !=3D 0)
> =3B =3B sleep(some value)
> =3B
> =3B
>The second is what sysutils was doing=2C and works=2C doesn't deadlock=2C i= >s deoptimized.
> =3Bm3core/libm3 did this for a long time as well. When I complained ab= >out perf=2C it was pointed out to me.
> =3B
>The first has deadlock potential with userthreads=2C but is ok and faster w= >ith kernel threads.
> =3B
> =3B
>waitpid(flags =3D nohang =3D =3Bdon't actually wait=2C just get the exi= >t code=2C if there is one) is a way to quickly poll if a process has ended= >=2C and if so=2C get its exit code. In Win32 there are two seperate functio= >ns GetExitCodeProcess and WaitForSingleObject or WaitForMultipleObjects ("w= >aiting" is generalized across files=2C processes=2C sockets=2C files=2C thr= >eads=2C semaphores=2C mutexes=2C events and more..but not critical sections= >..only kernel objects). These have a bug too. One particular exit code is r= >eserved to mean "the process is still running"=2C but that is easily avoide= >d by using Wait first. I have seen code get confused by this though. Wait a= >lso accepts a timeout=2C 32bit unsigned milliseconds=2C including 0 and inf= >inity=2C so also can be used to poll. Win32 also defines the exit code to b= >e 32bits=2C whereas Posix only allows for 8 bits which can be an interop pr= >oblem. Perl on Win32 truncates exit codes to 8 bits=2C very bad. Unhandled = >exceptions end up as "large" exit codes.
> =3B
>Anyway...
> =3B
>The problem with the polling approach=2C at least part of the problem=2C is= > that if the child process isn't done when waitpid is first called=2C but f= >inishes before sleep(whatever value) ends=2C we will still sleep for the fu= >ll "whatever value". You only really want to sleep until the child process = >is done=2C and no longer.
> =3B
> =3B
>Making just the first sleep shorter might be a good idea.
>You know=2C to handle processes that are short-lived=2C but not "zero" live= >d.
>("zero" being the amount of time it takes for the code to proceed from fork= >/exec to waitpid=2C surely much smaller than a small sleep() but longer tha= >n no sleep).
> =3B
> =3B
>Calling just waitpid(flags =3D 0) could deadlock if=2C for example=2C a par= >ent thread is writing to a child's stdin=2C and the child won't finish unti= >l the parent has written all that it needs to. The parent and child process= >=2C er=2C other threads in the parent process=2C need to be allowed to run = >concurrently=2C for the sake of at least some reasonable scenarios.
> =3B
>With kernelthreads=2C the implementation of waitpid knows about threads and= > will itself=2C in a sense=2C do the poll/sleep=2C but not exactly that -- = >it won't sleep beyond the child process finishing.
> =3B
> =3B
>Hopefully this makes sense and lets more folks understand the problem.
> =3B
> =3B
>What you can do=2C of course=2C is like:
> =3B
> =3B
>if kernelthreads
> =3B waitpid(flags =3D 0)
>else
> =3B while (waitpid(flags =3D nohang) !=3D 0)
> =3B =3Bsleep
> =3B
> =3B
>and that is basically what the code looks like now.
> =3B
>The part "if kernelthreads" I propose be "if SchedulerPosix.DoesWaitPidYiel= >d()"
>though a really direct "if Thread or Scheduler.KernelThreads" might be reas= >onable.
>Up to folks then to decide what that implies..
> =3B
> =3B- Jay


>=3B Date: Fri=2C 2 Jan 2009 11:27:24 +0100
&= >gt=3B From: wagner at elegosoft.com
>=3B To: m3devel at elegosoft.com
>= >=3B Subject: Re: [M3devel] variations of waitpid..?
>=3B
>=3B Qu= >oting Tony Hosking <=3Bhosking at cs.purdue.edu>=3B:
>=3B
>=3B = >>=3B If someone uses waitpid they get what they paid for.
>=3B It is= > so long ago that we wrote those sysutils routines...
>=3B They have o= >nly ever be used in simple command line utilities (like cm3)
>=3B with= >out much concurrency=2C I think. If there is potential for deadlocks
>= >=3B and bad performance=2C we should at least document that in the interfac= >es.
>=3B
>=3B I am not up-to-date wrt. the M3 system interfaces = >and threads
>=3B implementation: is there a way for a thread to wait f= >or the exit code
>=3B of another process without blocking other thread= >s? If so=2C I'll adapt
>=3B the sysutils code... If not=2C can we intr= >oduce such an interface in
>=3B m3core/libm3?
>=3B
>=3B Ola= >f
>=3B
>=3B >=3B On 1 Jan 2009=2C at 06:24=2C Jay wrote:
&g= >t=3B >=3B
>=3B >=3B>=3B
>=3B >=3B>=3B You mean=2C this = >function is easy to misuse?
>=3B >=3B>=3B>=3B People who declare= > their own <=3B*EXTERNAL*>=3B
>=3B >=3B>=3B Like waitpid expos= >ed from m3core?
>=3B >=3B>=3B
>=3B >=3B>=3B waitpid is al= >ready easy to misuse=2C on a userthread system=2C leading
>=3B >=3B= >>=3B to possible (though I think rare) deadlock.
>=3B >=3B>=3B I= >t is easy to misuse on pthreads=2C lead "just" to bad performance=2C
&g= >t=3B >=3B>=3B and in fact I believe cm3 is doing this=2C via sysutils.<= >BR>>=3B >=3B>=3B This at least guides you between two patterns of use= >=2C and fix the
>=3B >=3B>=3B perf of cm3/sysutils.
>=3B >= >=3B>=3B
>=3B >=3B>=3B On a userthread system=2C waitpid(pid=2C f= >lags =3D 0) waits for the child
>=3B >=3B>=3B process=2C with all= > parent threads suspended.
>=3B >=3B>=3B Generally I doubt the chi= >ld depends on parent threads progressing=2C
>=3B >=3B>=3B but=2C = >yeah=2C that could deadlock=2C like if a parent thread is waiting
>= >=3B >=3B>=3B to a file or stdin of the child=2C or reading a child's st= >dout.
>=3B >=3B>=3B
>=3B >=3B>=3B The various uses do wai= >tpid(pid=2C flags =3D nohang) and then sleep and
>=3B >=3B>=3B tr= >y again.
>=3B >=3B>=3B
>=3B >=3B>=3B pthreads just uses w= >aitpid(pid=2C flags =3D 0) and all threads keep running
>=3B
>= >=3B
>=3B
>=3B --
>=3B Olaf Wagner -- elego Software Solut= >ions GmbH
>=3B Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C= > Germany
>=3B phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: = >+49 30 23 45 86 95
>=3B http://www.elegosoft.com | Gesch=E4ftsf=FChrer= >: Olaf Wagner | Sitz: Berlin
>=3B Handelregister: Amtsgericht Charlott= >enburg HRB 77719 | USt-IdNr: DE163214194
>=3B

>= > >--_e7fe8011-c1fe-42de-b7fb-8ae54fa172fc_-- From jay.krell at cornell.edu Mon Jan 5 19:00:43 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 5 Jan 2009 18:00:43 +0000 Subject: [M3devel] variations of waitpid..? In-Reply-To: <200901051123.n05BNJVB078904@camembert.async.caltech.edu> References: Your message of "Fri, 02 Jan 2009 19:15:48 GMT." <200901051123.n05BNJVB078904@camembert.async.caltech.edu> Message-ID: Yes, it is "all" inside Process.Wait, except that sysutils implements this stuff itself, so it is also in there. You can consider that there are two implementations of Process.Wait. Correct, no need on pthreads or NT -- the code has two different modes, "slow" and "fast". Or rather, "slow posix", "fast posix", and "fast NT". The problem was, the posix code didn't know how to chose, so was just always "slow". Imho this just one more reason to never use user threads but I seem to be the only one. > the Wait to a small number doesn't really work. Once you have> yielded, as far as the OS is concerned, you've already lost (at> least on FreeBSD). The only thing that really works is busy waiting. I don't understand. I mean, well, ignoring something for a sec, you must yield. My suggestion, in a commit comment, that maybe the first wait should be much shorter. You know, the sequence is like: fork/exec run through a /little/ bit of code label check if process done if not "sleep" (actual a call into the m3 scheduler which will run other threads goto label A point is that the first check is going to VERY soon after the process starts. The child would have to be VERY quick for the first check to find it is done. Perhaps it is merely "fairly quick", but not "VERY quick" we could win by making just the first wait smaller. You know, the inefficiency here I believe is the time the child takes to run modulo the sleep duration, and then divided by child duration. You want to find the child is done as soon as possible after it is actually done. You don't want to keep waiting. For long running children, the inefficiency is less. For short running children, the inefficiency is likely more. Shrinking the wait has a positive and negative affect on efficiency. You know, making it very small reduces the inefficiency here, but adds inefficiency because we'd spend more time merely checking the process status. Another idea is to "hang" (be fast) if the program is single threaded, however, "single threaded" is nearly impossible to practically discover, since there will always be worker threads, just that they are not dependent or depended-upon the child process. You know, there is the garbage collector thread, at least. Ok, what I was ignoring is your suggestion of handling sigchild. I'll try to look into that, sounds promising. But again, if you just use pthreads, no problem. Again, the previous code was even slow on pthreads, but should be better now. Again, if you just ignore user threads, no longer a problem. - Jay> To: jay.krell at cornell.edu> Date: Mon, 5 Jan 2009 03:23:19 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] variations of waitpid..?> > > This is all really inside Process.Wait, right?> > On user threads: I can report (from having tried it) that changing> the Wait to a small number doesn't really work. Once you have> yielded, as far as the OS is concerned, you've already lost (at> least on FreeBSD). The only thing that really works is busy waiting.> > The "correct" thing to do on unix is to catch SIGCHLD (SIGCLD?)...> > I started coding this up once, but I'm not sure I shared my code> with anyone? I think it was Tony that pointed out that it was> unnecessary with pthreads...> > Mika> > P.S. Happy New Year, everyone.> > > > Jay writes:> >--_e7fe8011-c1fe-42de-b7fb-8ae54fa172fc_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >I didn't read that well -- the deadlock risk in sysutils is not there.> >The bad perf is probably.> >=20> >=20> >To be clear (esp. for folks that might not already know about this=2C> >I didn't know about until fairly recently)=2C there are two options:> >=20> >=20> >waitpid(pid=2C flags =3D 0)> >move along> >=20> >=20> >or> >while (waitpid(pid=2C flags =3D nohang) !=3D 0)> > sleep(some value)> >=20> >=20> >The second is what sysutils was doing=2C and works=2C doesn't deadlock=2C i=> >s deoptimized.> > m3core/libm3 did this for a long time as well. When I complained about per=> >f=2C it was pointed out to me.> >=20> >The first has deadlock potential with userthreads=2C but is ok and faster w=> >ith kernel threads.> >=20> >=20> >waitpid(flags =3D nohang =3D don't actually wait=2C just get the exit code=> >=2C if there is one) is a way to quickly poll if a process has ended=2C and=> > if so=2C get its exit code. In Win32 there are two seperate functions GetE=> >xitCodeProcess and WaitForSingleObject or WaitForMultipleObjects ("waiting"=> > is generalized across files=2C processes=2C sockets=2C files=2C threads=2C=> > semaphores=2C mutexes=2C events and more..but not critical sections..only => >kernel objects). These have a bug too. One particular exit code is reserved=> > to mean "the process is still running"=2C but that is easily avoided by us=> >ing Wait first. I have seen code get confused by this though. Wait also acc=> >epts a timeout=2C 32bit unsigned milliseconds=2C including 0 and infinity=> >=2C so also can be used to poll. Win32 also defines the exit code to be 32b=> >its=2C whereas Posix only allows for 8 bits which can be an interop problem=> >. Perl on Win32 truncates exit codes to 8 bits=2C very bad. Unhandled excep=> >tions end up as "large" exit codes.> >=20> >Anyway...> >=20> >The problem with the polling approach=2C at least part of the problem=2C is=> > that if the child process isn't done when waitpid is first called=2C but f=> >inishes before sleep(whatever value) ends=2C we will still sleep for the fu=> >ll "whatever value". You only really want to sleep until the child process => >is done=2C and no longer.> >=20> >=20> >Making just the first sleep shorter might be a good idea.> >You know=2C to handle processes that are short-lived=2C but not "zero" live=> >d.> >("zero" being the amount of time it takes for the code to proceed from fork=> >/exec to waitpid=2C surely much smaller than a small sleep() but longer tha=> >n no sleep).> >=20> >=20> >Calling just waitpid(flags =3D 0) could deadlock if=2C for example=2C a par=> >ent thread is writing to a child's stdin=2C and the child won't finish unti=> >l the parent has written all that it needs to. The parent and child process=> >=2C er=2C other threads in the parent process=2C need to be allowed to run => >concurrently=2C for the sake of at least some reasonable scenarios.> >=20> >With kernelthreads=2C the implementation of waitpid knows about threads and=> > will itself=2C in a sense=2C do the poll/sleep=2C but not exactly that -- => >it won't sleep beyond the child process finishing.> >=20> >=20> >Hopefully this makes sense and lets more folks understand the problem.> >=20> >=20> >What you can do=2C of course=2C is like:> >=20> >=20> >if kernelthreads> > waitpid(flags =3D 0)> >else> > while (waitpid(flags =3D nohang) !=3D 0)> > sleep> >=20> >=20> >and that is basically what the code looks like now.> >=20> >The part "if kernelthreads" I propose be "if SchedulerPosix.DoesWaitPidYiel=> >d()"> >though a really direct "if Thread or Scheduler.KernelThreads" might be reas=> >onable.> >Up to folks then to decide what that implies..> >=20> > - Jay> Date: Fri=2C 2 Jan 2009 11:27:24 +0100> From: wagner at elegosoft.com>=> > To: m3devel at elegosoft.com> Subject: Re: [M3devel] variations of waitpid..?=> >> > Quoting Tony Hosking :> > > If someone uses wait=> >pid they get what they paid for.> It is so long ago that we wrote those sys=> >utils routines...> They have only ever be used in simple command line utili=> >ties (like cm3)> without much concurrency=2C I think. If there is potential=> > for deadlocks> and bad performance=2C we should at least document that in => >the interfaces.> > I am not up-to-date wrt. the M3 system interfaces and th=> >reads> implementation: is there a way for a thread to wait for the exit cod=> >e> of another process without blocking other threads? If so=2C I'll adapt> => >the sysutils code... If not=2C can we introduce such an interface in> m3cor=> >e/libm3?> > Olaf> > > On 1 Jan 2009=2C at 06:24=2C Jay wrote:> >> >>> >> Yo=> >u mean=2C this function is easy to misuse?> >>> People who declare their ow=> >n <*EXTERNAL*>> >> Like waitpid exposed from m3core?> >>> >> waitpid is alr=> >eady easy to misuse=2C on a userthread system=2C leading > >> to possible (=> >though I think rare) deadlock.> >> It is easy to misuse on pthreads=2C lead=> > "just" to bad performance=2C > >> and in fact I believe cm3 is doing this=> >=2C via sysutils.> >> This at least guides you between two patterns of use=> >=2C and fix the > >> perf of cm3/sysutils.> >>> >> On a userthread system=> >=2C waitpid(pid=2C flags =3D 0) waits for the child > >> process=2C with al=> >l parent threads suspended.> >> Generally I doubt the child depends on pare=> >nt threads progressing=2C > >> but=2C yeah=2C that could deadlock=2C like i=> >f a parent thread is waiting > >> to a file or stdin of the child=2C or rea=> >ding a child's stdout.> >>> >> The various uses do waitpid(pid=2C flags =3D=> > nohang) and then sleep and > >> try again.> >>> >> pthreads just uses wait=> >pid(pid=2C flags =3D 0) and all threads keep running> > > > -- > Olaf Wagne=> >r -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C=> > 13355 Berlin=2C Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 86=> >9 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch=E4ftsf=FChrer: => >Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB => >77719 | USt-IdNr: DE163214194> => >> >--_e7fe8011-c1fe-42de-b7fb-8ae54fa172fc_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >> >I didn't read that well -- the deadlock risk in sysutils is not there.
> >The bad perf is probably.
> > =3B
> > =3B
> >To be clear (esp. for folks that might not already know about this=2C
> >I didn't know about until fairly recently)=2C there are two options:
> > =3B
> > =3B
> >waitpid(pid=2C flags =3D 0)
> >move along
> > =3B
> > =3B
> >or
> >while (waitpid(pid=2C flags =3D nohang) !=3D 0)
> > =3B =3B sleep(some value)
> > =3B
> > =3B
> >The second is what sysutils was doing=2C and works=2C doesn't deadlock=2C i=> >s deoptimized.
> > =3Bm3core/libm3 did this for a long time as well. When I complained ab=> >out perf=2C it was pointed out to me.
> > =3B
> >The first has deadlock potential with userthreads=2C but is ok and faster w=> >ith kernel threads.
> > =3B
> > =3B
> >waitpid(flags =3D nohang =3D =3Bdon't actually wait=2C just get the exi=> >t code=2C if there is one) is a way to quickly poll if a process has ended=> >=2C and if so=2C get its exit code. In Win32 there are two seperate functio=> >ns GetExitCodeProcess and WaitForSingleObject or WaitForMultipleObjects ("w=> >aiting" is generalized across files=2C processes=2C sockets=2C files=2C thr=> >eads=2C semaphores=2C mutexes=2C events and more..but not critical sections=> >..only kernel objects). These have a bug too. One particular exit code is r=> >eserved to mean "the process is still running"=2C but that is easily avoide=> >d by using Wait first. I have seen code get confused by this though. Wait a=> >lso accepts a timeout=2C 32bit unsigned milliseconds=2C including 0 and inf=> >inity=2C so also can be used to poll. Win32 also defines the exit code to b=> >e 32bits=2C whereas Posix only allows for 8 bits which can be an interop pr=> >oblem. Perl on Win32 truncates exit codes to 8 bits=2C very bad. Unhandled => >exceptions end up as "large" exit codes.
> > =3B
> >Anyway...
> > =3B
> >The problem with the polling approach=2C at least part of the problem=2C is=> > that if the child process isn't done when waitpid is first called=2C but f=> >inishes before sleep(whatever value) ends=2C we will still sleep for the fu=> >ll "whatever value". You only really want to sleep until the child process => >is done=2C and no longer.
> > =3B
> > =3B
> >Making just the first sleep shorter might be a good idea.
> >You know=2C to handle processes that are short-lived=2C but not "zero" live=> >d.
> >("zero" being the amount of time it takes for the code to proceed from fork=> >/exec to waitpid=2C surely much smaller than a small sleep() but longer tha=> >n no sleep).
> > =3B
> > =3B
> >Calling just waitpid(flags =3D 0) could deadlock if=2C for example=2C a par=> >ent thread is writing to a child's stdin=2C and the child won't finish unti=> >l the parent has written all that it needs to. The parent and child process=> >=2C er=2C other threads in the parent process=2C need to be allowed to run => >concurrently=2C for the sake of at least some reasonable scenarios.
> > =3B
> >With kernelthreads=2C the implementation of waitpid knows about threads and=> > will itself=2C in a sense=2C do the poll/sleep=2C but not exactly that -- => >it won't sleep beyond the child process finishing.
> > =3B
> > =3B
> >Hopefully this makes sense and lets more folks understand the problem.
> > =3B
> > =3B
> >What you can do=2C of course=2C is like:
> > =3B
> > =3B
> >if kernelthreads
> > =3B waitpid(flags =3D 0)
> >else
> > =3B while (waitpid(flags =3D nohang) !=3D 0)
> > =3B =3Bsleep
> > =3B
> > =3B
> >and that is basically what the code looks like now.
> > =3B
> >The part "if kernelthreads" I propose be "if SchedulerPosix.DoesWaitPidYiel=> >d()"
> >though a really direct "if Thread or Scheduler.KernelThreads" might be reas=> >onable.
> >Up to folks then to decide what that implies..
> > =3B
> > =3B- Jay


>=3B Date: Fri=2C 2 Jan 2009 11:27:24 +0100
&=> >gt=3B From: wagner at elegosoft.com
>=3B To: m3devel at elegosoft.com
>=> >=3B Subject: Re: [M3devel] variations of waitpid..?
>=3B
>=3B Qu=> >oting Tony Hosking <=3Bhosking at cs.purdue.edu>=3B:
>=3B
>=3B => >>=3B If someone uses waitpid they get what they paid for.
>=3B It is=> > so long ago that we wrote those sysutils routines...
>=3B They have o=> >nly ever be used in simple command line utilities (like cm3)
>=3B with=> >out much concurrency=2C I think. If there is potential for deadlocks
>=> >=3B and bad performance=2C we should at least document that in the interfac=> >es.
>=3B
>=3B I am not up-to-date wrt. the M3 system interfaces => >and threads
>=3B implementation: is there a way for a thread to wait f=> >or the exit code
>=3B of another process without blocking other thread=> >s? If so=2C I'll adapt
>=3B the sysutils code... If not=2C can we intr=> >oduce such an interface in
>=3B m3core/libm3?
>=3B
>=3B Ola=> >f
>=3B
>=3B >=3B On 1 Jan 2009=2C at 06:24=2C Jay wrote:
&g=> >t=3B >=3B
>=3B >=3B>=3B
>=3B >=3B>=3B You mean=2C this => >function is easy to misuse?
>=3B >=3B>=3B>=3B People who declare=> > their own <=3B*EXTERNAL*>=3B
>=3B >=3B>=3B Like waitpid expos=> >ed from m3core?
>=3B >=3B>=3B
>=3B >=3B>=3B waitpid is al=> >ready easy to misuse=2C on a userthread system=2C leading
>=3B >=3B=> >>=3B to possible (though I think rare) deadlock.
>=3B >=3B>=3B I=> >t is easy to misuse on pthreads=2C lead "just" to bad performance=2C
&g=> >t=3B >=3B>=3B and in fact I believe cm3 is doing this=2C via sysutils.<=> >BR>>=3B >=3B>=3B This at least guides you between two patterns of use=> >=2C and fix the
>=3B >=3B>=3B perf of cm3/sysutils.
>=3B >=> >=3B>=3B
>=3B >=3B>=3B On a userthread system=2C waitpid(pid=2C f=> >lags =3D 0) waits for the child
>=3B >=3B>=3B process=2C with all=> > parent threads suspended.
>=3B >=3B>=3B Generally I doubt the chi=> >ld depends on parent threads progressing=2C
>=3B >=3B>=3B but=2C => >yeah=2C that could deadlock=2C like if a parent thread is waiting
>=> >=3B >=3B>=3B to a file or stdin of the child=2C or reading a child's st=> >dout.
>=3B >=3B>=3B
>=3B >=3B>=3B The various uses do wai=> >tpid(pid=2C flags =3D nohang) and then sleep and
>=3B >=3B>=3B tr=> >y again.
>=3B >=3B>=3B
>=3B >=3B>=3B pthreads just uses w=> >aitpid(pid=2C flags =3D 0) and all threads keep running
>=3B
>=> >=3B
>=3B
>=3B --
>=3B Olaf Wagner -- elego Software Solut=> >ions GmbH
>=3B Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C=> > Germany
>=3B phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: => >+49 30 23 45 86 95
>=3B http://www.elegosoft.com | Gesch=E4ftsf=FChrer=> >: Olaf Wagner | Sitz: Berlin
>=3B Handelregister: Amtsgericht Charlott=> >enburg HRB 77719 | USt-IdNr: DE163214194
>=3B

> >=> >> >--_e7fe8011-c1fe-42de-b7fb-8ae54fa172fc_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 5 19:04:22 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 5 Jan 2009 18:04:22 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090105072548.AB46610D5D2A@birch.elegosoft.com> Message-ID: Reading the code ...there is a command line option to the compiler to apparently make it: ADR (x: T) : UNTRACED REF T. Good?bad?better?different? Seems more type safe. I haven't tried it. - Jay From: hosking at cs.purdue.eduTo: jkrell at elego.deDate: Mon, 5 Jan 2009 21:47:15 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3According to the language spec: The following operations are primarily used for address arithmetic: ADR (VAR x: Any) : ADDRESS infix + (x: ADDRESS, y:INTEGER) : ADDRESS infix - (x: ADDRESS, y:INTEGER) : ADDRESS infix - (x,y: ADDRESS) : INTEGER ADR(x) is the address of the variable x. The actual argument must be a designator but need not be writable. On 5 Jan 2009, at 08:25, Jay Krell wrote: CVSROOT: /usr/cvsChanges by: jkrell at birch. 09/01/05 08:25:48Modified 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.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Jan 5 19:18:57 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 05 Jan 2009 10:18:57 -0800 Subject: [M3devel] variations of waitpid..? In-Reply-To: Your message of "Mon, 05 Jan 2009 18:00:43 GMT." Message-ID: <200901051818.n05IIviI093998@camembert.async.caltech.edu> Jay writes: >--_5fe387c0-3f5b-4882-b57b-b7299ded497e_ ... > much shorter. >You know=2C the sequence is like: > fork/exec=20 > run through a /little/ bit of code=20 > label=20 > check if process done=20 > if not > "sleep" (actual a call into the m3 scheduler which will run other thre= >ads=20 > goto label=20 >=20 ... You're right, but under user threads, here's what can (and does) happen, e.g., in the compiler itself: - Start child process - Call Process.Wait, which... - Calls Thread.Pause(somesmallnumber) There are no runnable threads, so the runtime yields the processor. I think it calls Unix's sleep? The OS scheduler then schedules the process at a very low priority. In most OSes, processes waiting for I/O have the highest priority, and processes sleeping have the lowest. So you've gone from waiting for a process to exit, at high priority, to sleeping, at very low priority. The OS then takes its time to get around to waking you up again. This is my theory of what happens on FreeBSD anyhow. It is the way I describe my experimental result that you can change that sleep to anything and it doesn't run noticeably faster than with 0.1d0. Getting rid of the Thread.Pause speeds things up substantially :-) Mika From jay.krell at cornell.edu Mon Jan 5 20:04:16 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 5 Jan 2009 19:04:16 +0000 Subject: [M3devel] variations of waitpid..? In-Reply-To: <200901051818.n05IIviI093998@camembert.async.caltech.edu> References: Your message of "Mon, 05 Jan 2009 18:00:43 GMT." <200901051818.n05IIviI093998@camembert.async.caltech.edu> Message-ID: > - Start child process > - Call Process.Wait, which... > - Calls Thread.Pause(somesmallnumber) There is a call to waitpid before the Thread.Pause. If the process finishes /very/ quickly, probably never happens, no pause/sleep. > There are no runnable threads, so the runtime yields the processor. > I think it calls Unix's sleep? Agreed probably no runnable threads typically and sleep(). Perhaps the scheduler knows that none of the threads will become runnable, but I doubt it. > The OS scheduler then schedules the process at a very low priority. > In most OSes, processes waiting for I/O have the highest priority, > and processes sleeping have the lowest. So you've gone from waiting > for a process to exit, at high priority, to sleeping, at very low > priority. The OS then takes its time to get around to waking you > up again. Hm. Why does sleep() imply anything about priority? Why doesn't it mean "don't run at all for a certain duration, and then when the duration elapses, resume running ASAP, with the same priority as it has before sleeping"? Surely "not running at all for a certain duration" does not mean "low priority"? There is a problem -- it will wait the entire duration, even if the process exists half way through. > Getting rid of the Thread.Pause speeds things up substantially :-) But it can also cause damage. If there is a dependency between the child process and other parent threads. Often there is not, sometimes there is. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 5 21:27:50 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 5 Jan 2009 20:27:50 +0000 Subject: [M3devel] SIG_DFL, SIG_IGN duplication (and RTSignal.m3 duplication) Message-ID: SIG_DFL and SIG_IGN are effectively duplicated twice for every platform. Once in Usignal.i3, once in RTSignal.m3. 1) The duplication in RTSignal.m3 I would think wouldn't be needed if module initialization occurs in a "correct" order. ? 2) The duplication in RTSignal.m3 could be eliminated if all platforms defined Usiginal.SIG_DFL, SIG_IGN, like Darwin and Solaris do -- a constant integer that you must LOOPHOLE instead of a correctly type variable that gets initialized (the variables have multiple correct types besides, due to signal handlers having at least three possible prototypes, ANSI C, BSD, and POSIX). Perhaps Usignal could provide both a constant integer for folks to LOOPHOLE, and a typed initialized variable. Since both sides are system-dependent, there isn't a "disconnect", porters just have to check both copies. Apparently the values are always the same across all platforms, but that might be a coincidence of sorts. I rather suspect in the old days, people copied C header content around a lot to other C code, leading to values like becoming impossible to change, including constants and types, not just the arguably "easier" function prototypes. Anyway, my inclination is rewrite the small number of clients in C, fixing both this, and reducing the cloned headers. -- As well stopping the duplication of RTSignal.m3, of which there are 37 nearly identical copies, or roughly 3 variants duplicated 37 times (again, ANSI, BSD, POSIX). Other clients I see are: C:\dev2\cm3.2\m3-libs\m3core\src\float\DS3100\FloatMode.m3(360): ELSIF (p = Usignal.SIG_DFL) THENC:\dev2\cm3.2\m3-libs\m3core\src\float\IRIX5\FloatMode.m3(361): ELSIF (p = Usignal.SIG_DFL) THENC:\dev2\cm3.2\m3-libs\m3core\src\float\DS3100\FloatMode.m3(358): IF (p = Usignal.SIG_IGN) THENC:\dev2\cm3.2\m3-libs\m3core\src\float\IRIX5\FloatMode.m3(359): IF (p = Usignal.SIG_IGN) THEN but these are dead for multiple reasons. The platforms are dead/dormant, and platform-specific FloatMode is dead in general, though perhaps should not be. (I do have a machine running Irix so hope to get that building/working before much longer...DS3100 no.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinbishop at bellsouth.net Tue Jan 6 21:50:56 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Tue, 06 Jan 2009 14:50:56 -0600 Subject: [M3devel] Widechars Message-ID: <4963C430.9020804@bellsouth.net> I'm playing around with WIDECHARS, and having some trouble. VAR wide := ARRAY OF WIDECHAR {'\x304A', '\x306F', '\x3088', '\x3046'}; s := Text.FromWideChars(wide); I get these errors from the compiler: "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: syntax error: missing '}' (4) "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal 9 errors encountered It seems like it's reading '\x304A' as '\x30' (which is why it says "syntax error: missing '}' (4)") Do I need some special literal letter or something? From roland.illig at gmx.de Tue Jan 6 22:31:28 2009 From: roland.illig at gmx.de (Roland Illig) Date: Tue, 06 Jan 2009 22:31:28 +0100 Subject: [M3devel] Widechars In-Reply-To: <4963C430.9020804@bellsouth.net> References: <4963C430.9020804@bellsouth.net> Message-ID: <4963CDB0.9020500@gmx.de> Martin Bishop schrieb: > I'm playing around with WIDECHARS, and having some trouble. > > VAR wide := ARRAY OF WIDECHAR {'\x304A', '\x306F', '\x3088', '\x3046'}; > s := Text.FromWideChars(wide); >From what I just read in the CM3 compiler's source code, it only understands simple octal character escape sequences, and even those return a CHAR, not a WIDECHAR. So the question that remains is: What is the most readable, shortest form of encoding a WIDECHAR literal, or a WIDETEXT? Roland From hendrik at topoi.pooq.com Wed Jan 7 16:33:56 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 7 Jan 2009 10:33:56 -0500 Subject: [M3devel] Widechars In-Reply-To: <4963CDB0.9020500@gmx.de> References: <4963C430.9020804@bellsouth.net> <4963CDB0.9020500@gmx.de> Message-ID: <20090107153356.GA608@topoi.pooq.com> On Tue, Jan 06, 2009 at 10:31:28PM +0100, Roland Illig wrote: > Martin Bishop schrieb: > > I'm playing around with WIDECHARS, and having some trouble. > > > > VAR wide := ARRAY OF WIDECHAR {'\x304A', '\x306F', '\x3088', '\x3046'}; > > s := Text.FromWideChars(wide); > > >From what I just read in the CM3 compiler's source code, it only > understands simple octal character escape sequences, and even those > return a CHAR, not a WIDECHAR. > > So the question that remains is: What is the most readable, shortest > form of encoding a WIDECHAR literal, or a WIDETEXT? Most readable, probably UTF-8. > > Roland From dabenavidesd at yahoo.es Wed Jan 7 06:08:34 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 7 Jan 2009 05:08:34 +0000 (GMT) Subject: [M3devel] Widechars Message-ID: <601806.14495.qm@web28604.mail.ukl.yahoo.com> Hi all, I believe you need to declare wide VAR? with fixed size or create it as a Reference type ? VAR wide := ARRAY [1..4] OF WIDECHAR {'\x304A', '\x306F', '\x3088', '\x3046'};or arrWideChar:= NEW (REF ARRAY OF WIDECHAR, 4); arrWideChar[0]:='\x304A'; .... I'm not sure if you can do this, would be interesting to know: arrWideChar:= NEW (REF ARRAY OF WIDECHAR{'\x304A', '\x306F', '\x3088', '\x3046'} ); See further explanations on:? http://opencm3.net/doc/tutorial/m3/m3_54.html#SEC54 Also the language definition, http://opencm3.net/doc/reference/arrays.html Hope that helps --- El mar, 6/1/09, Martin Bishop wrote: De: Martin Bishop Asunto: [M3devel] Widechars Para: m3devel at elegosoft.com Fecha: martes, 6 enero, 2009 3:50 I'm playing around with WIDECHARS, and having some trouble. VAR wide := ARRAY OF WIDECHAR {'\x304A', '\x306F', '\x3088', '\x3046'}; s := Text.FromWideChars(wide); I get these errors from the compiler: "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: syntax error: missing '}' (4) "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal 9 errors encountered It seems like it's reading '\x304A' as '\x30' (which is why it says "syntax error: missing '}' (4)") Do I need some special literal letter or something? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Wed Jan 7 04:25:08 2009 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Tue, 06 Jan 2009 21:25:08 -0600 Subject: [M3devel] Widechars In-Reply-To: <4963C430.9020804@bellsouth.net> References: <4963C430.9020804@bellsouth.net> Message-ID: <49642094.7040400@wichita.edu> Literals of type WIDECHAR are written, e.g. W'\x304A', note the 'W'. It makes them have type WIDECHAR and also enables the 16-bit escape sequences you are using. If it is a CHAR or plain TEXT literal (no 'W' or 'w'), octal escapes must have exactly 3 octal digits and hex escapes must have exactly 2 hex digits. In WIDECHAR and wide TEXT literals, octal escapes must have exactly 6 and hex escapes exactly 4. Note that character literals without/with the 'W' are of different types, CHAR and WIDECHAR, respectively. For Text literals, both forms have the same type TEXT, but the lexical formation rules are different without/with the 'W'. I'm not sure where or even whether this is documented. Rodney Bates Martin Bishop wrote: > I'm playing around with WIDECHARS, and having some trouble. > > VAR wide := ARRAY OF WIDECHAR {'\x304A', '\x306F', '\x3088', '\x3046'}; > s := Text.FromWideChars(wide); > > I get these errors from the compiler: > "../Length.m3", line 5: missing closing quote on character literal > "../Length.m3", line 5: syntax error: missing '}' (4) > "../Length.m3", line 5: missing closing quote on character literal > "../Length.m3", line 5: missing closing quote on character literal > "../Length.m3", line 5: missing closing quote on character literal > "../Length.m3", line 5: missing closing quote on character literal > "../Length.m3", line 5: missing closing quote on character literal > "../Length.m3", line 5: missing closing quote on character literal > "../Length.m3", line 5: missing closing quote on character literal > 9 errors encountered > > It seems like it's reading '\x304A' as '\x30' (which is why it says > "syntax error: missing '}' (4)") > > Do I need some special literal letter or something? > > From darko at darko.org Wed Jan 7 07:05:01 2009 From: darko at darko.org (Darko) Date: Wed, 7 Jan 2009 15:05:01 +0900 Subject: [M3devel] Widechars In-Reply-To: <49642094.7040400@wichita.edu> References: <4963C430.9020804@bellsouth.net> <49642094.7040400@wichita.edu> Message-ID: <1817F156-E305-4126-8AC0-B3070E31B330@darko.org> Yes it is documented, if you read the compiler source code. On 07/01/2009, at 12:25 PM, Rodney M. Bates wrote: > Literals of type WIDECHAR are written, e.g. W'\x304A', note the 'W'. > It makes them have type WIDECHAR and also enables the 16-bit escape > sequences you are using. If it is a CHAR or plain TEXT literal > (no 'W' or 'w'), octal escapes must have exactly 3 octal digits and > hex escapes must have exactly 2 hex digits. In WIDECHAR and wide > TEXT literals, octal escapes must have exactly 6 and hex escapes > exactly 4. > > Note that character literals without/with the 'W' are of different > types, CHAR and WIDECHAR, respectively. For Text literals, both > forms have the same type TEXT, but the lexical formation rules > are different without/with the 'W'. > > I'm not sure where or even whether this is documented. > > Rodney Bates > > > Martin Bishop wrote: >> I'm playing around with WIDECHARS, and having some trouble. >> VAR wide := ARRAY OF WIDECHAR {'\x304A', '\x306F', '\x3088', >> '\x3046'}; >> s := Text.FromWideChars(wide); >> I get these errors from the compiler: >> "../Length.m3", line 5: missing closing quote on character literal >> "../Length.m3", line 5: syntax error: missing '}' (4) >> "../Length.m3", line 5: missing closing quote on character literal >> "../Length.m3", line 5: missing closing quote on character literal >> "../Length.m3", line 5: missing closing quote on character literal >> "../Length.m3", line 5: missing closing quote on character literal >> "../Length.m3", line 5: missing closing quote on character literal >> "../Length.m3", line 5: missing closing quote on character literal >> "../Length.m3", line 5: missing closing quote on character literal >> 9 errors encountered >> It seems like it's reading '\x304A' as '\x30' (which is why it says >> "syntax error: missing '}' (4)") >> Do I need some special literal letter or something? > From hendrik at topoi.pooq.com Thu Jan 8 07:13:56 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 8 Jan 2009 01:13:56 -0500 Subject: [M3devel] Widechars In-Reply-To: <49642094.7040400@wichita.edu> References: <4963C430.9020804@bellsouth.net> <49642094.7040400@wichita.edu> Message-ID: <20090108061355.GA2554@topoi.pooq.com> On Tue, Jan 06, 2009 at 09:25:08PM -0600, Rodney M. Bates wrote: > Literals of type WIDECHAR are written, e.g. W'\x304A', note the 'W'. > It makes them have type WIDECHAR and also enables the 16-bit escape > sequences you are using. If it is a CHAR or plain TEXT literal > (no 'W' or 'w'), octal escapes must have exactly 3 octal digits and > hex escapes must have exactly 2 hex digits. In WIDECHAR and wide > TEXT literals, octal escapes must have exactly 6 and hex escapes > exactly 4. I've always thought that octal and hexadecimal escapes should be self-delimiting. In the process of moving from 8- to 16-bit characters, the length of the escapes has changed, and we're going to hit it again when we implement the larger-than-16-bit Unicode charaters. In C, for strings, you can force early termination of an escape by ending the string with a quote, then a space, then starting a new string with another quote (since consecutive strings are implicitly concatenated, so you can write a really long string that doesn't fit on a line). At least, that's what I seem to remember. I haven't actually hacked this stuff for a long time. > > Note that character literals without/with the 'W' are of different > types, CHAR and WIDECHAR, respectively. For Text literals, both > forms have the same type TEXT, but the lexical formation rules > are different without/with the 'W'. Are we going to have to implement 'WW' to avoid retrocompatibility problems? -- hendrik From jay.krell at cornell.edu Wed Jan 7 14:36:20 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 7 Jan 2009 13:36:20 +0000 Subject: [M3devel] duplication between compiler, m3makefile, and libraries; cross build easing Message-ID: duplication between compiler, m3makefile, and libraries. I propose that there should be reduced or no duplicationamong the compiler, m3makefile, and libraries. I propose that the compiler reveal (some) of what it knows. For example, m3makefile shall not specify WORD_SIZE.The compiler should.Granted, this buys very little. m3makefile shall not contain tables identifiying endianness.Compiler shall defined TARGET_ENDIAN to "BIG" or "LITTLE",or perhaps "big" or "little".Granted, this buys very little. Libraries shall not define jumpbuf, in a sense.Compile shall define, something like: TARGET_JUMPBUF_ELEMENT = "INTEGER" or "LONGINT". aka jmpbuf alignment. TARGET_JUMPBUF_SIZE = a decimal integer. Leaving library to say: TYPE jmpbuf = ARRAY [1..size] OF element which m3makefile shall produce. or perhaps even compiler shall inject the type itself,as it injects a few things like INTERFACE Word functions. or compiler shall define TARGET_JUMPBUF_ALIGN = 32 or 64,and TARGET_JUMPBUF_SIZE in bytesleaving m3makefile to map 32 to Ctypes.int and 64 to LONGINT itself. The jumpbuf size/align bothers me more than word size and endianness.Word size and endianness are more widely known to humans I think.Endianness and word size are usually fairly obvious, thoughnot 100%. I didn't know the endianness of e.g. 88k, vax, and the historicallyterse names don't make it obvious. However, let me not confuse "jumpbuf" with "Thread.State" or such.Assume user threads stops using setjmp/longjmp and modifyor generalize proposal accordingly. Wonder if exception handling should use set/get/make/swapcontext also??Assume jumpbuf might remain on some platforms? ? As well, one should be able to specify m3config on the command line.One should be able to specify target on the command line.Compiler shall take specified target and search /somehow/ for the right config file.Perhaps in path to cm3\..\config\target.Don't probe like crazy -- not like I have it coded in Quake currently.That really bites when there is more than one, and you edit the wrong one. Probably something like, probe for path to cm3\..\config\target. but if defined $CM3_CONFIG_DIRECTORY, search instead $CM3_CONFIG_DIRECTORY\target.however this is perhaps colon or semicolon delimited, so maybe CM3_CONFIG_PATH.(In particular, I have nearly all my config files in m3-sys/cminstall/src/config-no-install,except NT386, which I'd really like to move, but will probably break something anddoesn't seem important). Reasonable ideas? Personally what I do is my Python scripts accept a target name anywhere on thecommand line, and if present, they set $M3CONFIG.So I have what I want via python already.You know, kind of a successful (imho) prototype, that should perhaps be elevatedinto the "real" stuff? You know, make it easier and easier to contruct cross-capable installations,where switching targets is changing environment variables and/or command lines,and not editing/copying files. If there isn't already, there should be a mode that doesn't run cm3cg.And possibly can still ship.That way /any/ system can do a bunch of cross-build "checking".And the file system layout for creating a "boot" archive becomesabout the same as the layout of a "real" system. Not like what I use -- I use one flat directory, since Modula-3 requires that every..basically ever .i3, .m3, .o file have a unique name. (.i3 and .m3 can clash with each other, once each, that's it). - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jan 7 15:34:12 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 7 Jan 2009 14:34:12 +0000 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: <20090103011227.vgpfs347400088sg@mail.elegosoft.com> References: <20090103011227.vgpfs347400088sg@mail.elegosoft.com> Message-ID: I looked into this a bit..and I think it's actually pretty easy.It hardly churns the code even. I have other things I want to do first. In the meantime, specify the directive?There are actually a large number of subtle options. Can I ask for any of n libraries -- NT, pthreads, user threads? setjmp vs. context? Or is it just a boolean, user vs. kernel? Is the option to "favor" or "require" a certain library? Can I set it on libraries or only programs? What if the requests clash? Is it "Favor" or "Require"? Is it a function call or setting a global variable? I favor function call, but TARGET, WORD_SIZE, BUILD_DIR establish the other precedent, and either can work. Is it flags in the moduleinfo like incgc, gengc, or separate data that there is just one of in RTLinker? Probably separate data, unless it is allowed in libraries. What are the names of the libraries? "posix" and "pthreads" ? "user" and "kernel" ? "true" and "false" (or vice versa) ? Should NT implement user threads, using fibers? Presumably it works with both standalone and shared/dynamic programs. Presumably it is ok to always bloat up m3core.dll with both libraries. Presumably it is ok to have everyone pay a teeny tiny perf. That is, there is a microscopic dispatching layer, that everyone ends up going through, not chosing to link in one library or the other. And as part of this, whenever it happens, can we bump up the minimum bootstrap to a version that includes SchedulerPosix.DoesWaitPidYield()? Or does it become VAR Scheduler.UsingKerneThreads? (no, it should be a function; but naming matter remains). (ie. as I said, the decision currently is baked into m3core.dll, but now it is also baked into sysutils.dll, but these should change together; m3core.dll should manage the knowledge). - Jay> Date: Sat, 3 Jan 2009 01:12:27 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] dynamic chose between user/kernel threads?> > An option to cm3 or a quake directive to use in the m3makefiles> would suffice in my opinion (and be a great improvement).> > Olaf> > Quoting Jay :> > >> > Should the user/kernel thread chose be available:> >> >> > On the command line to a Modula-3 executable (or even an executable > > where main is in another language, but which static or dynamic > > Modula-3 libs are used)?> >> >> > Via a quake directive when building programs?> >> >> > You know, imagine you have a bunch of Modula-3 programs and some but > > not all use a very large number of threads and benefit from > > userthreads.> >> >> > Currently the chose is locked into m3core when it is built.> >> >> > - Jay> > > -- > Olaf -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Wed Jan 7 18:32:24 2009 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 07 Jan 2009 11:32:24 -0600 Subject: [M3devel] Widechars In-Reply-To: <20090108061355.GA2554@topoi.pooq.com> References: <4963C430.9020804@bellsouth.net> <49642094.7040400@wichita.edu> <20090108061355.GA2554@topoi.pooq.com> Message-ID: <4964E728.4050306@wichita.edu> hendrik at topoi.pooq.com wrote: > On Tue, Jan 06, 2009 at 09:25:08PM -0600, Rodney M. Bates wrote: >> Literals of type WIDECHAR are written, e.g. W'\x304A', note the 'W'. >> It makes them have type WIDECHAR and also enables the 16-bit escape >> sequences you are using. If it is a CHAR or plain TEXT literal >> (no 'W' or 'w'), octal escapes must have exactly 3 octal digits and >> hex escapes must have exactly 2 hex digits. In WIDECHAR and wide >> TEXT literals, octal escapes must have exactly 6 and hex escapes >> exactly 4. > > I've always thought that octal and hexadecimal escapes should be > self-delimiting. In the process of moving from 8- to 16-bit characters, > the length of the escapes has changed, and we're going to hit it again > when we implement the larger-than-16-bit Unicode charaters. > > In C, for strings, you can force early termination of an escape by > ending the string with a quote, then a space, then starting a new string > with another quote (since consecutive strings are implicitly > concatenated, so you can write a really long string that doesn't fit on > a line). At least, that's what I seem to remember. I haven't actually > hacked this stuff for a long time. This would be easy to implement, wouldn't break any existing code, and concatenating the fragments without an explicit '&' operator between would not suffer from ambiguity over whether the programmer expected runtime concatenation. I have liked this facility in C for long strings, just because I find wrapped long lines both very difficult to read and ugly. We could also easily make escapes prematurely terminated by a closing quote legal, again without breaking any existing code, which might be occasionally useful. However, if somebody wants to put a lot of escape-specified characters in a row in a TEXT literal, and not have to give every one all the most significant digits, terminating with a closing quote, then starting another literal would make things even more pedantic than they are. I have been thinking of a new set of escape letters (like the 'x', that immediately follow the backslash) that can be given independently of the 'W', and each one implies the base and number of digits. In theory, this could break existing code, if somebody had already redundantly escaped one of these new escape letters. This seems rather unlikely to have happened. > >> Note that character literals without/with the 'W' are of different >> types, CHAR and WIDECHAR, respectively. For Text literals, both >> forms have the same type TEXT, but the lexical formation rules >> are different without/with the 'W'. > > Are we going to have to implement 'WW' to avoid retrocompatibility > problems? > > -- hendrik Rodney Bates From hendrik at topoi.pooq.com Thu Jan 8 12:55:30 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 8 Jan 2009 06:55:30 -0500 Subject: [M3devel] Widechars In-Reply-To: <4964E728.4050306@wichita.edu> References: <4963C430.9020804@bellsouth.net> <49642094.7040400@wichita.edu> <20090108061355.GA2554@topoi.pooq.com> <4964E728.4050306@wichita.edu> Message-ID: <20090108115529.GA3157@topoi.pooq.com> On Wed, Jan 07, 2009 at 11:32:24AM -0600, Rodney M. Bates wrote: > hendrik at topoi.pooq.com wrote: > >On Tue, Jan 06, 2009 at 09:25:08PM -0600, Rodney M. Bates wrote: > >>Literals of type WIDECHAR are written, e.g. W'\x304A', note the 'W'. > >>It makes them have type WIDECHAR and also enables the 16-bit escape > >>sequences you are using. If it is a CHAR or plain TEXT literal > >>(no 'W' or 'w'), octal escapes must have exactly 3 octal digits and > >>hex escapes must have exactly 2 hex digits. In WIDECHAR and wide > >>TEXT literals, octal escapes must have exactly 6 and hex escapes > >>exactly 4. > > > >I've always thought that octal and hexadecimal escapes should be > >self-delimiting. In the process of moving from 8- to 16-bit characters, > >the length of the escapes has changed, and we're going to hit it again > >when we implement the larger-than-16-bit Unicode charaters. > > > >In C, for strings, you can force early termination of an escape by > >ending the string with a quote, then a space, then starting a new string > >with another quote (since consecutive strings are implicitly > >concatenated, so you can write a really long string that doesn't fit on > >a line). At least, that's what I seem to remember. I haven't actually > >hacked this stuff for a long time. > > This would be easy to implement, wouldn't break any existing code, and > concatenating the fragments without an explicit '&' operator between > would not suffer from ambiguity over whether the programmer expected > runtime concatenation. I have liked this facility in C for long strings, > just because I find wrapped long lines both very difficult to read and > ugly. In C you don't have a concatenation operator. I guess compile-time concatenation does really have different semantics from run-time, in the sense that compile-time gives you just one copy of the string, and run-time gives you a new one every time. > > We could also easily make escapes prematurely terminated by a closing > quote legal, again without breaking any existing code, which might be > occasionally useful. Of course, escapes could also be terminated by the backslash of the next escape. I don't like this as much as an explicit terminator. > > However, if somebody wants to put a lot of escape-specified characters > in a row in a TEXT literal, and not have to give every one all the > most significant digits, terminating with a closing quote, then > starting another literal would make things even more pedantic than > they are. Well, you could choose a character that does nothing but terminate an escape. Then you wouldn't have to start a new string. But it would break existing code that happens to have that character after a string. > > I have been thinking of a new set of escape letters (like the 'x', > that immediately follow the backslash) that can be given independently > of the 'W', and each one implies the base and number of digits. In > theory, this could break existing code, if somebody had already > redundantly escaped one of these new escape letters. This seems rather > unlikely to have happened. > > > > >>Note that character literals without/with the 'W' are of different > >>types, CHAR and WIDECHAR, respectively. For Text literals, both > >>forms have the same type TEXT, but the lexical formation rules > >>are different without/with the 'W'. > > > >Are we going to have to implement 'WW' to avoid retrocompatibility > >problems? > > > >-- hendrik > > Rodney Bates > > From hosking at cs.purdue.edu Thu Jan 8 03:46:58 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 8 Jan 2009 13:46:58 +1100 Subject: [M3devel] duplication between compiler, m3makefile, and libraries; cross build easing In-Reply-To: References: Message-ID: Why would the compiler know anything about jmpbuf in general? (Yes, I know it is used for exception handling). I would prefer that we had table-based exception handling as on SOLgnu for all targets, but that depends on support for stack unwinding for each target. I would hate for the compiler to inject a type for something like jmpbuf which is an *internal* detail of the exceptions implementation rather than a language-defined type. Also, there are advantages in the current approach, which decouples communication of information amongst the tool-chain components. Why would you use setcontext, getcontext, etc. for exception handling. setjmp/longjmp are perfectly adequate to the task. setcontext/getcontext are intended for user-thread switching, etc. I think you'll find there already is a compiler mode that does not invoke cm3cg. 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 8 Jan 2009, at 00:36, Jay wrote: > duplication between compiler, m3makefile, and libraries. > > > I propose that there should be reduced or no duplication > among the compiler, m3makefile, and libraries. > > > I propose that the compiler reveal (some) of what it knows. > > > For example, m3makefile shall not specify WORD_SIZE. > The compiler should. > Granted, this buys very little. > > > m3makefile shall not contain tables identifiying endianness. > Compiler shall defined TARGET_ENDIAN to "BIG" or "LITTLE", > or perhaps "big" or "little". > Granted, this buys very little. > > > Libraries shall not define jumpbuf, in a sense. > Compile shall define, something like: > TARGET_JUMPBUF_ELEMENT = "INTEGER" or "LONGINT". > aka jmpbuf alignment. > TARGET_JUMPBUF_SIZE = a decimal integer. > Leaving library to say: > TYPE jmpbuf = ARRAY [1..size] OF element > which m3makefile shall produce. > > > or perhaps even compiler shall inject the type itself, > as it injects a few things like INTERFACE Word functions. > > > or compiler shall define TARGET_JUMPBUF_ALIGN = 32 or 64, > and TARGET_JUMPBUF_SIZE in bytes > leaving m3makefile to map 32 to Ctypes.int and 64 to LONGINT itself. > > > The jumpbuf size/align bothers me more than word size and endianness. > Word size and endianness are more widely known to humans I think. > Endianness and word size are usually fairly obvious, though > not 100%. I didn't know the endianness of e.g. 88k, vax, and the > historically > terse names don't make it obvious. > > > However, let me not confuse "jumpbuf" with "Thread.State" or such. > Assume user threads stops using setjmp/longjmp and modify > or generalize proposal accordingly. > > Wonder if exception handling should use set/get/make/swapcontext > also?? > Assume jumpbuf might remain on some platforms? > > ? > > As well, one should be able to specify m3config on the command line. > One should be able to specify target on the command line. > Compiler shall take specified target and search /somehow/ for the > right config file. > Perhaps in path to cm3\..\config\target. > Don't probe like crazy -- not like I have it coded in Quake currently. > That really bites when there is more than one, and you edit the > wrong one. > > Probably something like, > probe for path to cm3\..\config\target. > > but if defined $CM3_CONFIG_DIRECTORY, search instead > $CM3_CONFIG_DIRECTORY\target. > however this is perhaps colon or semicolon delimited, so maybe > CM3_CONFIG_PATH. > (In particular, I have nearly all my config files in m3-sys/ > cminstall/src/config-no-install, > except NT386, which I'd really like to move, but will probably break > something and > doesn't seem important). > > Reasonable ideas? > > > Personally what I do is my Python scripts accept a target name > anywhere on the > command line, and if present, they set $M3CONFIG. > So I have what I want via python already. > You know, kind of a successful (imho) prototype, that should perhaps > be elevated > into the "real" stuff? > > > You know, make it easier and easier to contruct cross-capable > installations, > where switching targets is changing environment variables and/or > command lines, > and not editing/copying files. > > > If there isn't already, there should be a mode that doesn't run cm3cg. > And possibly can still ship. > That way /any/ system can do a bunch of cross-build "checking". > And the file system layout for creating a "boot" archive becomes > about the same as the layout of a "real" system. > Not like what I use -- I use one flat directory, since Modula-3 > requires that every..basically ever .i3, .m3, .o file have a unique > name. > (.i3 and .m3 can clash with each other, once each, that's it). > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jan 8 03:51:15 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 8 Jan 2009 13:51:15 +1100 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: References: <20090103011227.vgpfs347400088sg@mail.elegosoft.com> Message-ID: <44664E56-D816-4A94-AD2E-96A0DB383DDF@cs.purdue.edu> Jay, perhaps you can provide some context and motivation for your proposals. I am unable to evaluate your proposals in the form of a simple laundry-list. On 8 Jan 2009, at 01:34, Jay wrote: > I looked into this a bit..and I think it's actually pretty easy. > It hardly churns the code even. > > > I have other things I want to do first. > > > In the meantime, specify the directive? > There are actually a large number of subtle options. > > > Can I ask for any of n libraries -- NT, pthreads, user threads? > setjmp vs. context? Or is it just a boolean, user vs. kernel? > > > Is the option to "favor" or "require" a certain library? > > > Can I set it on libraries or only programs? > What if the requests clash? > > > Is it "Favor" or "Require"? > Is it a function call or setting a global variable? > I favor function call, but TARGET, WORD_SIZE, BUILD_DIR establish > the other precedent, > and either can work. > > Is it flags in the moduleinfo like incgc, gengc, or separate data that > there is just one of in RTLinker? Probably separate data, unless it > is allowed in libraries. > > > What are the names of the libraries? > "posix" and "pthreads" ? > "user" and "kernel" ? > "true" and "false" (or vice versa) ? > > > Should NT implement user threads, using fibers? > > > Presumably it works with both standalone and shared/dynamic programs. > Presumably it is ok to always bloat up m3core.dll with both libraries. > Presumably it is ok to have everyone pay a teeny tiny perf. > That is, there is a microscopic dispatching layer, that everyone > ends up going through, not chosing to link in one library or the > other. > > > And as part of this, whenever it happens, can we bump up the minimum > bootstrap to a version that includes > SchedulerPosix.DoesWaitPidYield()? > Or does it become VAR Scheduler.UsingKerneThreads? > (no, it should be a function; but naming matter remains). > > > (ie. as I said, the decision currently is baked into m3core.dll, but > now it is also baked into sysutils.dll, but these should change > together; > m3core.dll should manage the knowledge). > > > - Jay > > > > Date: Sat, 3 Jan 2009 01:12:27 +0100 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] dynamic chose between user/kernel threads? > > > > An option to cm3 or a quake directive to use in the m3makefiles > > would suffice in my opinion (and be a great improvement). > > > > Olaf > > > > Quoting Jay : > > > > > > > > Should the user/kernel thread chose be available: > > > > > > > > > On the command line to a Modula-3 executable (or even an > executable > > > where main is in another language, but which static or dynamic > > > Modula-3 libs are used)? > > > > > > > > > Via a quake directive when building programs? > > > > > > > > > You know, imagine you have a bunch of Modula-3 programs and some > but > > > not all use a very large number of threads and benefit from > > > userthreads. > > > > > > > > > Currently the chose is locked into m3core when it is built. > > > > > > > > > - Jay > > > > > > -- > > Olaf -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 8 04:10:49 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 8 Jan 2009 03:10:49 +0000 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: <44664E56-D816-4A94-AD2E-96A0DB383DDF@cs.purdue.edu> References: <20090103011227.vgpfs347400088sg@mail.elegosoft.com> <44664E56-D816-4A94-AD2E-96A0DB383DDF@cs.purdue.edu> Message-ID: Olaf understood the point (I think). :) Some programs, people say, and I believe, run "better" (faster, without running out of address space) with user threads instead of kernel threads. On systems that have both. A good example might be a program that needs lots of threads and therefore small stacks, and the kernel threads, due to code below the Modula-3 runtime, might force fairly large stacks. (Such a program might have to adjust thread size differently for different threads, and only call into the underlying system on threads with larger stacks.) It might be nice for such programs to be able to mandate or request (two slightly different things) that the user thread library be used by them, even if the platform's default is to use kernel threads. The only minor detail then is, how to express the request, and the precise meaning. It is a request or a mandate? As well, if the issue is address space, sholud there a "built in" way to only make the request on 32bit platforms, or should uses manually say if equal (WORD_SIZE, "32BITS")? Is it a boolean or an enum? Cygwin might conceivably get pthreads support (Cygwin has it, but Modula-3/Cygwin does not). Therefore, is the choice among "posix" threads, "pthreads" and "NT" threads? Or just user vs. kernel? I think the "important" part here is easy to implement. But again.. The easier straightforward implementation always links both pieces of code in and makes a choice early in startup as to which to use, either setting a boolean, or an enum, or a pointer to a record of function pointers. This means that people that don't care to ever use user threads pay a small price, in code bloat and probably in a few extra instructions per certain functions. This is probably ok. However if that was not ok, the choice could be made at link time and only be supported for standalone programs. - Jay CC: wagner at elegosoft.com; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] dynamic chose between user/kernel threads?Date: Thu, 8 Jan 2009 13:51:15 +1100 Jay, perhaps you can provide some context and motivation for your proposals. I am unable to evaluate your proposals in the form of a simple laundry-list. On 8 Jan 2009, at 01:34, Jay wrote: I looked into this a bit..and I think it's actually pretty easy.It hardly churns the code even. I have other things I want to do first. In the meantime, specify the directive?There are actually a large number of subtle options. Can I ask for any of n libraries -- NT, pthreads, user threads? setjmp vs. context? Or is it just a boolean, user vs. kernel? Is the option to "favor" or "require" a certain library? Can I set it on libraries or only programs? What if the requests clash? Is it "Favor" or "Require"?Is it a function call or setting a global variable?I favor function call, but TARGET, WORD_SIZE, BUILD_DIR establish the other precedent,and either can work. Is it flags in the moduleinfo like incgc, gengc, or separate data thatthere is just one of in RTLinker? Probably separate data, unless it is allowed in libraries. What are the names of the libraries? "posix" and "pthreads" ? "user" and "kernel" ? "true" and "false" (or vice versa) ? Should NT implement user threads, using fibers? Presumably it works with both standalone and shared/dynamic programs.Presumably it is ok to always bloat up m3core.dll with both libraries.Presumably it is ok to have everyone pay a teeny tiny perf. That is, there is a microscopic dispatching layer, that everyone ends up going through, not chosing to link in one library or the other. And as part of this, whenever it happens, can we bump up the minimumbootstrap to a version that includes SchedulerPosix.DoesWaitPidYield()?Or does it become VAR Scheduler.UsingKerneThreads?(no, it should be a function; but naming matter remains). (ie. as I said, the decision currently is baked into m3core.dll, butnow it is also baked into sysutils.dll, but these should change together;m3core.dll should manage the knowledge). - Jay> Date: Sat, 3 Jan 2009 01:12:27 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] dynamic chose between user/kernel threads?> > An option to cm3 or a quake directive to use in the m3makefiles> would suffice in my opinion (and be a great improvement).> > Olaf> > Quoting Jay :> > >> > Should the user/kernel thread chose be available:> >> >> > On the command line to a Modula-3 executable (or even an executable > > where main is in another language, but which static or dynamic > > Modula-3 libs are used)?> >> >> > Via a quake directive when building programs?> >> >> > You know, imagine you have a bunch of Modula-3 programs and some but > > not all use a very large number of threads and benefit from > > userthreads.> >> >> > Currently the chose is locked into m3core when it is built.> >> >> > - Jay> > > -- > Olaf -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 8 04:44:40 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 8 Jan 2009 03:44:40 +0000 Subject: [M3devel] duplication between compiler, m3makefile, and libraries; cross build easing In-Reply-To: References: Message-ID: Is table-based exception handling close to being feasible on many targets? I figured it was mostly a lost cause but wouldn't mind being wrong. Perhaps the evolution of gcc has made it much easier these days? You know, what with Ada and C++ exception handling support being whatever it is? Imho target-specific information should be kept to a minimum kept to a minimum number of places/files perhaps kept to a minimum distance from other target-specific information (places/files) and like other information, not duplicated If jumpbuf wasn't used by the compiler, then my position weakens. However currently the size and alignment of jumpbuf is duplicated. And endianness is duplicated. And wordsize is duplicated. I wouldn't mind if jumpbuf was only, say, Csetjmp.i3, and wordsize was only in the config file. But duplication bugs me. > why context for exception handling vs. setjmp/longjmp. Just my ignorant questioning. If setjmp/longjmp suffice, ok. They are just similar and perhaps if switch one, switch the other. I realize that longjmp can only officially be called once per setjmp, and that contexts are "reusable" (can be swapped an arbitrary number of times). - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Thu, 8 Jan 2009 13:46:58 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] duplication between compiler, m3makefile, and libraries; cross build easingWhy would the compiler know anything about jmpbuf in general? (Yes, I know it is used for exception handling). I would prefer that we had table-based exception handling as on SOLgnu for all targets, but that depends on support for stack unwinding for each target. I would hate for the compiler to inject a type for something like jmpbuf which is an *internal* detail of the exceptions implementation rather than a language-defined type. Also, there are advantages in the current approach, which decouples communication of information amongst the tool-chain components. Why would you use setcontext, getcontext, etc. for exception handling. setjmp/longjmp are perfectly adequate to the task. setcontext/getcontext are intended for user-thread switching, etc. I think you'll find there already is a compiler mode that does not invoke cm3cg. 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 8 Jan 2009, at 00:36, Jay wrote: duplication between compiler, m3makefile, and libraries. I propose that there should be reduced or no duplicationamong the compiler, m3makefile, and libraries. I propose that the compiler reveal (some) of what it knows. For example, m3makefile shall not specify WORD_SIZE.The compiler should.Granted, this buys very little. m3makefile shall not contain tables identifiying endianness.Compiler shall defined TARGET_ENDIAN to "BIG" or "LITTLE",or perhaps "big" or "little".Granted, this buys very little. Libraries shall not define jumpbuf, in a sense.Compile shall define, something like: TARGET_JUMPBUF_ELEMENT = "INTEGER" or "LONGINT". aka jmpbuf alignment. TARGET_JUMPBUF_SIZE = a decimal integer.Leaving library to say: TYPE jmpbuf = ARRAY [1..size] OF elementwhich m3makefile shall produce. or perhaps even compiler shall inject the type itself,as it injects a few things like INTERFACE Word functions. or compiler shall define TARGET_JUMPBUF_ALIGN = 32 or 64,and TARGET_JUMPBUF_SIZE in bytesleaving m3makefile to map 32 to Ctypes.int and 64 to LONGINT itself. The jumpbuf size/align bothers me more than word size and endianness.Word size and endianness are more widely known to humans I think.Endianness and word size are usually fairly obvious, thoughnot 100%. I didn't know the endianness of e.g. 88k, vax, and the historicallyterse names don't make it obvious. However, let me not confuse "jumpbuf" with "Thread.State" or such.Assume user threads stops using setjmp/longjmp and modifyor generalize proposal accordingly.Wonder if exception handling should use set/get/make/swapcontext also??Assume jumpbuf might remain on some platforms? ?As well, one should be able to specify m3config on the command line.One should be able to specify target on the command line.Compiler shall take specified target and search /somehow/ for the right config file.Perhaps in path to cm3\..\config\target.Don't probe like crazy -- not like I have it coded in Quake currently.That really bites when there is more than one, and you edit the wrong one.Probably something like, probe for path to cm3\..\config\target.but if defined $CM3_CONFIG_DIRECTORY, search instead $CM3_CONFIG_DIRECTORY\target.however this is perhaps colon or semicolon delimited, so maybe CM3_CONFIG_PATH.(In particular, I have nearly all my config files in m3-sys/cminstall/src/config-no-install,except NT386, which I'd really like to move, but will probably break something anddoesn't seem important).Reasonable ideas? Personally what I do is my Python scripts accept a target name anywhere on thecommand line, and if present, they set $M3CONFIG.So I have what I want via python already.You know, kind of a successful (imho) prototype, that should perhaps be elevatedinto the "real" stuff? You know, make it easier and easier to contruct cross-capable installations,where switching targets is changing environment variables and/or command lines,and not editing/copying files. If there isn't already, there should be a mode that doesn't run cm3cg.And possibly can still ship.That way /any/ system can do a bunch of cross-build "checking".And the file system layout for creating a "boot" archive becomesabout the same as the layout of a "real" system. Not like what I use -- I use one flat directory, since Modula-3 requires that every..basically ever .i3, .m3, .o file have a unique name. (.i3 and .m3 can clash with each other, once each, that's it). - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 8 04:50:54 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 8 Jan 2009 03:50:54 +0000 Subject: [M3devel] duplication between compiler, m3makefile, and libraries; cross build easing In-Reply-To: References: Message-ID: > I would hate for the compiler to inject a type for > something like jmpbuf which is an *internal* detail > of the exceptions implementation rather than a language-defined type The compiler and runtime are unavoidably somewhat interdependent on each other. You know, that the compiler generates calls to RTHooks.i3. If you want the ability to retarget the compiler to a slightly different runtime, then the runtime should inform the compiler, and not the other way around, but they remain interdepenent. There are similar issues here probably regarding RT0.i3 and RTBuiltin.c. I guess you don't want the compiler to clutter the global type/modulespace, as a communications channel, to share information. But I think language and library are somewhat murky. Is INTERFACE Word in the language or the library? Is LOCK language or library? These are both in-between. INTERFACE Word is in the "standard library", and I think it is only in the compiler as an implementation specific optimization. LOCK is necessarily in both. - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] duplication between compiler, m3makefile, and libraries; cross build easingDate: Thu, 8 Jan 2009 03:44:40 +0000 Is table-based exception handling close to being feasible on many targets?I figured it was mostly a lost cause but wouldn't mind being wrong.Perhaps the evolution of gcc has made it much easier these days?You know, what with Ada and C++ exception handling support being whatever it is? Imho target-specific information should be kept to a minimum kept to a minimum number of places/files perhaps kept to a minimum distance from other target-specific information (places/files) and like other information, not duplicated If jumpbuf wasn't used by the compiler, then my position weakens.However currently the size and alignment of jumpbuf is duplicated.And endianness is duplicated. And wordsize is duplicated.I wouldn't mind if jumpbuf was only, say, Csetjmp.i3, and wordsize was only in the config file.But duplication bugs me. > why context for exception handling vs. setjmp/longjmp. Just my ignorant questioning. If setjmp/longjmp suffice, ok.They are just similar and perhaps if switch one, switch the other.I realize that longjmp can only officially be called once per setjmp, and that contexts are "reusable" (can be swapped an arbitrary number of times). - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Thu, 8 Jan 2009 13:46:58 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] duplication between compiler, m3makefile, and libraries; cross build easingWhy would the compiler know anything about jmpbuf in general? (Yes, I know it is used for exception handling). I would prefer that we had table-based exception handling as on SOLgnu for all targets, but that depends on support for stack unwinding for each target. I would hate for the compiler to inject a type for something like jmpbuf which is an *internal* detail of the exceptions implementation rather than a language-defined type. Also, there are advantages in the current approach, which decouples communication of information amongst the tool-chain components. Why would you use setcontext, getcontext, etc. for exception handling. setjmp/longjmp are perfectly adequate to the task. setcontext/getcontext are intended for user-thread switching, etc. I think you'll find there already is a compiler mode that does not invoke cm3cg. 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 8 Jan 2009, at 00:36, Jay wrote: duplication between compiler, m3makefile, and libraries. I propose that there should be reduced or no duplicationamong the compiler, m3makefile, and libraries. I propose that the compiler reveal (some) of what it knows. For example, m3makefile shall not specify WORD_SIZE.The compiler should.Granted, this buys very little. m3makefile shall not contain tables identifiying endianness.Compiler shall defined TARGET_ENDIAN to "BIG" or "LITTLE",or perhaps "big" or "little".Granted, this buys very little. Libraries shall not define jumpbuf, in a sense.Compile shall define, something like: TARGET_JUMPBUF_ELEMENT = "INTEGER" or "LONGINT". aka jmpbuf alignment. TARGET_JUMPBUF_SIZE = a decimal integer.Leaving library to say: TYPE jmpbuf = ARRAY [1..size] OF elementwhich m3makefile shall produce. or perhaps even compiler shall inject the type itself,as it injects a few things like INTERFACE Word functions. or compiler shall define TARGET_JUMPBUF_ALIGN = 32 or 64,and TARGET_JUMPBUF_SIZE in bytesleaving m3makefile to map 32 to Ctypes.int and 64 to LONGINT itself. The jumpbuf size/align bothers me more than word size and endianness.Word size and endianness are more widely known to humans I think.Endianness and word size are usually fairly obvious, thoughnot 100%. I didn't know the endianness of e.g. 88k, vax, and the historicallyterse names don't make it obvious. However, let me not confuse "jumpbuf" with "Thread.State" or such.Assume user threads stops using setjmp/longjmp and modifyor generalize proposal accordingly.Wonder if exception handling should use set/get/make/swapcontext also??Assume jumpbuf might remain on some platforms? ?As well, one should be able to specify m3config on the command line.One should be able to specify target on the command line.Compiler shall take specified target and search /somehow/ for the right config file.Perhaps in path to cm3\..\config\target.Don't probe like crazy -- not like I have it coded in Quake currently.That really bites when there is more than one, and you edit the wrong one.Probably something like, probe for path to cm3\..\config\target.but if defined $CM3_CONFIG_DIRECTORY, search instead $CM3_CONFIG_DIRECTORY\target.however this is perhaps colon or semicolon delimited, so maybe CM3_CONFIG_PATH.(In particular, I have nearly all my config files in m3-sys/cminstall/src/config-no-install,except NT386, which I'd really like to move, but will probably break something anddoesn't seem important).Reasonable ideas? Personally what I do is my Python scripts accept a target name anywhere on thecommand line, and if present, they set $M3CONFIG.So I have what I want via python already.You know, kind of a successful (imho) prototype, that should perhaps be elevatedinto the "real" stuff? You know, make it easier and easier to contruct cross-capable installations,where switching targets is changing environment variables and/or command lines,and not editing/copying files. If there isn't already, there should be a mode that doesn't run cm3cg.And possibly can still ship.That way /any/ system can do a bunch of cross-build "checking".And the file system layout for creating a "boot" archive becomesabout the same as the layout of a "real" system. Not like what I use -- I use one flat directory, since Modula-3 requires that every..basically ever .i3, .m3, .o file have a unique name. (.i3 and .m3 can clash with each other, once each, that's it). - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jan 8 05:58:38 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 8 Jan 2009 15:58:38 +1100 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: References: <20090103011227.vgpfs347400088sg@mail.elegosoft.com> <44664E56-D816-4A94-AD2E-96A0DB383DDF@cs.purdue.edu> Message-ID: <234B3116-4C98-470B-9929-3E2AC72D67DC@cs.purdue.edu> On 8 Jan 2009, at 14:10, Jay wrote: > Olaf understood the point (I think). :) > > Some programs, people say, and I believe, run "better" (faster, > without running out of address space) with user threads instead of > kernel threads. Is this still true for modern kernel thread systems? > On systems that have both. > A good example might be a program that needs lots of threads and > therefore small stacks, and the kernel threads, due to code below > the Modula-3 runtime, might force fairly large stacks. (Such a > program might have to adjust thread size differently for different > threads, and only call into the underlying system on threads with > larger stacks.) In a systems programming language like Modula-3 shouldn't threads have a relationship to the system? > It might be nice for such programs to be able to mandate or request > (two slightly different things) that the user thread library be used > by them, even if the platform's default is to use kernel threads. This will need to be a link-time distinction. I would hate to have both kernel and user thread code live in the same compiled run-time system. > The only minor detail then is, how to express the request, and the > precise meaning. > It is a request or a mandate? I see no problem with factoring out the threads subsystem as a separate library and linking accordingly. > As well, if the issue is address space, sholud there a "built in" > way to only make the request on 32bit platforms, or should uses > manually say if equal (WORD_SIZE, "32BITS")? > > Is it a boolean or an enum? > Cygwin might conceivably get pthreads support (Cygwin has it, but > Modula-3/Cygwin does not). > Therefore, is the choice among "posix" threads, "pthreads" and "NT" > threads? > Or just user vs. kernel? I would argue for user vs. kernel. > I think the "important" part here is easy to implement. > But again.. And managing the state-space explosion that multiple choices might entail. I would like to avoid that. > The easier straightforward implementation always links both pieces > of code in and makes a choice early in startup as to which to use, > either setting a boolean, or an enum, or a pointer to a record of > function pointers. This means that people that don't care to ever > use user threads pay a small price, in code bloat and probably in a > few extra instructions per certain functions. This is probably ok. I am not so sure, since it would entail some fairly low-level and expensive decisions that would best instead be done at link-time. > However if that was not ok, the choice could be made at link time > and only be supported for standalone programs. Actually, for non-standalone (dynamically-linked) code we could make the choice at dynamic load time using the OS's support for dynamic library choice. I note that Solaris (but not Solaris Modula-3) currently lets dynamically linked C programs choose among 3 different threads implementations dynamically. > > > - Jay > > > > > CC: wagner at elegosoft.com; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] dynamic chose between user/kernel threads? > Date: Thu, 8 Jan 2009 13:51:15 +1100 > > > Jay, perhaps you can provide some context and motivation for your > proposals. I am unable to evaluate your proposals in the form of a > simple laundry-list. > > On 8 Jan 2009, at 01:34, Jay wrote: > > I looked into this a bit..and I think it's actually pretty easy. > It hardly churns the code even. > > > I have other things I want to do first. > > > In the meantime, specify the directive? > There are actually a large number of subtle options. > > > Can I ask for any of n libraries -- NT, pthreads, user threads? > setjmp vs. context? Or is it just a boolean, user vs. kernel? > > > Is the option to "favor" or "require" a certain library? > > > Can I set it on libraries or only programs? > What if the requests clash? > > > Is it "Favor" or "Require"? > Is it a function call or setting a global variable? > I favor function call, but TARGET, WORD_SIZE, BUILD_DIR establish > the other precedent, > and either can work. > > Is it flags in the moduleinfo like incgc, gengc, or separate data that > there is just one of in RTLinker? Probably separate data, unless it > is allowed in libraries. > > > What are the names of the libraries? > "posix" and "pthreads" ? > "user" and "kernel" ? > "true" and "false" (or vice versa) ? > > > Should NT implement user threads, using fibers? > > > Presumably it works with both standalone and shared/dynamic programs. > Presumably it is ok to always bloat up m3core.dll with both libraries. > Presumably it is ok to have everyone pay a teeny tiny perf. > That is, there is a microscopic dispatching layer, that everyone > ends up going through, not chosing to link in one library or the > other. > > > And as part of this, whenever it happens, can we bump up the minimum > bootstrap to a version that includes > SchedulerPosix.DoesWaitPidYield()? > Or does it become VAR Scheduler.UsingKerneThreads? > (no, it should be a function; but naming matter remains). > > > (ie. as I said, the decision currently is baked into m3core.dll, but > now it is also baked into sysutils.dll, but these should change > together; > m3core.dll should manage the knowledge). > > > - Jay > > > > Date: Sat, 3 Jan 2009 01:12:27 +0100 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] dynamic chose between user/kernel threads? > > > > An option to cm3 or a quake directive to use in the m3makefiles > > would suffice in my opinion (and be a great improvement). > > > > Olaf > > > > Quoting Jay : > > > > > > > > Should the user/kernel thread chose be available: > > > > > > > > > On the command line to a Modula-3 executable (or even an > executable > > > where main is in another language, but which static or dynamic > > > Modula-3 libs are used)? > > > > > > > > > Via a quake directive when building programs? > > > > > > > > > You know, imagine you have a bunch of Modula-3 programs and some > but > > > not all use a very large number of threads and benefit from > > > userthreads. > > > > > > > > > Currently the chose is locked into m3core when it is built. > > > > > > > > > - Jay > > > > > > -- > > Olaf > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jan 8 06:03:51 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 8 Jan 2009 16:03:51 +1100 Subject: [M3devel] duplication between compiler, m3makefile, and libraries; cross build easing In-Reply-To: References: Message-ID: <41260DC6-BBA1-4628-BAEE-8482D4531EFA@cs.purdue.edu> On 8 Jan 2009, at 14:44, Jay wrote: > Is table-based exception handling close to being feasible on many > targets? We could make use of libunwind (http://www.nongnu.org/libunwind/) to do the unwinding and use the table-based scheme. I note that gcc already comes with a version of libunwind for some targets. > I figured it was mostly a lost cause but wouldn't mind being wrong. I hope not, since setjmp/longjmp is needlessly expensive. > Perhaps the evolution of gcc has made it much easier these days? > You know, what with Ada and C++ exception handling support being > whatever it is? Indeed. > Imho target-specific information should be > kept to a minimum > kept to a minimum number of places/files > perhaps kept to a minimum distance from other target-specific > information (places/files) > and like other information, not duplicated Yes, a laudable goal. > If jumpbuf wasn't used by the compiler, then my position weakens. > However currently the size and alignment of jumpbuf is duplicated. > And endianness is duplicated. And wordsize is duplicated. > I wouldn't mind if jumpbuf was only, say, Csetjmp.i3, and wordsize > was only in the config file. > But duplication bugs me. Indeed. > > why context for exception handling vs. setjmp/longjmp. > > Just my ignorant questioning. If setjmp/longjmp suffice, ok. > They are just similar and perhaps if switch one, switch the other. > I realize that longjmp can only officially be called once per > setjmp, and that contexts are "reusable" (can be swapped an > arbitrary number of times). Yes, that is the distinction -- I expect that has some impact on the underlying implementation and efficiency. > > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Thu, 8 Jan 2009 13:46:58 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] duplication between compiler, m3makefile, and > libraries; cross build easing > > Why would the compiler know anything about jmpbuf in general? (Yes, > I know it is used for exception handling). I would prefer that we > had table-based exception handling as on SOLgnu for all targets, but > that depends on support for stack unwinding for each target. I > would hate for the compiler to inject a type for something like > jmpbuf which is an *internal* detail of the exceptions > implementation rather than a language-defined type. Also, there are > advantages in the current approach, which decouples communication of > information amongst the tool-chain components. > > Why would you use setcontext, getcontext, etc. for exception > handling. setjmp/longjmp are perfectly adequate to the task. > setcontext/getcontext are intended for user-thread switching, etc. > > I think you'll find there already is a compiler mode that does not > invoke cm3cg. > > 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 8 Jan 2009, at 00:36, Jay wrote: > > duplication between compiler, m3makefile, and libraries. > > > I propose that there should be reduced or no duplication > among the compiler, m3makefile, and libraries. > > > I propose that the compiler reveal (some) of what it knows. > > > For example, m3makefile shall not specify WORD_SIZE. > The compiler should. > Granted, this buys very little. > > > m3makefile shall not contain tables identifiying endianness. > Compiler shall defined TARGET_ENDIAN to "BIG" or "LITTLE", > or perhaps "big" or "little". > Granted, this buys very little. > > > Libraries shall not define jumpbuf, in a sense. > Compile shall define, something like: > TARGET_JUMPBUF_ELEMENT = "INTEGER" or "LONGINT". > aka jmpbuf alignment. > TARGET_JUMPBUF_SIZE = a decimal integer. > Leaving library to say: > TYPE jmpbuf = ARRAY [1..size] OF element > which m3makefile shall produce. > > > or perhaps even compiler shall inject the type itself, > as it injects a few things like INTERFACE Word functions. > > > or compiler shall define TARGET_JUMPBUF_ALIGN = 32 or 64, > and TARGET_JUMPBUF_SIZE in bytes > leaving m3makefile to map 32 to Ctypes.int and 64 to LONGINT itself. > > > The jumpbuf size/align bothers me more than word size and endianness. > Word size and endianness are more widely known to humans I think. > Endianness and word size are usually fairly obvious, though > not 100%. I didn't know the endianness of e.g. 88k, vax, and the > historically > terse names don't make it obvious. > > > However, let me not confuse "jumpbuf" with "Thread.State" or such. > Assume user threads stops using setjmp/longjmp and modify > or generalize proposal accordingly. > > Wonder if exception handling should use set/get/make/swapcontext > also?? > Assume jumpbuf might remain on some platforms? > > ? > > As well, one should be able to specify m3config on the command line. > One should be able to specify target on the command line. > Compiler shall take specified target and search /somehow/ for the > right config file. > Perhaps in path to cm3\..\config\target. > Don't probe like crazy -- not like I have it coded in Quake currently. > That really bites when there is more than one, and you edit the > wrong one. > > Probably something like, > probe for path to cm3\..\config\target. > > but if defined $CM3_CONFIG_DIRECTORY, search instead > $CM3_CONFIG_DIRECTORY\target. > however this is perhaps colon or semicolon delimited, so maybe > CM3_CONFIG_PATH. > (In particular, I have nearly all my config files in m3-sys/ > cminstall/src/config-no-install, > except NT386, which I'd really like to move, but will probably break > something and > doesn't seem important). > > Reasonable ideas? > > > Personally what I do is my Python scripts accept a target name > anywhere on the > command line, and if present, they set $M3CONFIG. > So I have what I want via python already. > You know, kind of a successful (imho) prototype, that should perhaps > be elevated > into the "real" stuff? > > > You know, make it easier and easier to contruct cross-capable > installations, > where switching targets is changing environment variables and/or > command lines, > and not editing/copying files. > > > If there isn't already, there should be a mode that doesn't run cm3cg. > And possibly can still ship. > That way /any/ system can do a bunch of cross-build "checking". > And the file system layout for creating a "boot" archive becomes > about the same as the layout of a "real" system. > Not like what I use -- I use one flat directory, since Modula-3 > requires that every..basically ever .i3, .m3, .o file have a unique > name. > (.i3 and .m3 can clash with each other, once each, that's it). > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jan 8 06:05:43 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 8 Jan 2009 16:05:43 +1100 Subject: [M3devel] duplication between compiler, m3makefile, and libraries; cross build easing In-Reply-To: References: Message-ID: On 8 Jan 2009, at 14:50, Jay wrote: > > I would hate for the compiler to inject a type for > > something like jmpbuf which is an *internal* detail > > of the exceptions implementation rather than a language-defined > type > > The compiler and runtime are unavoidably somewhat interdependent on > each other. > You know, that the compiler generates calls to RTHooks.i3. Yes, of course they are, but we want to keep the interface between them as narrow as possible. > If you want the ability to retarget the compiler to a slightly > different runtime, then the runtime should > inform the compiler, and not the other way around, but they remain > interdepenent. Not sure how you would achieve that. > There are similar issues here probably regarding RT0.i3 and > RTBuiltin.c. Here be dragons... > I guess you don't want the compiler to clutter the global type/ > modulespace, as a communications channel, to share information. Precisely. > But I think language and library are somewhat murky. True. Java has a simple core language, but lots of powerful libraries. > Is INTERFACE Word in the language or the library? > Is LOCK language or library? > These are both in-between. > INTERFACE Word is in the "standard library", and I think it is only > in the compiler as an implementation specific optimization. LOCK is > necessarily in both. > > - Jay > > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] duplication between compiler, m3makefile, and > libraries; cross build easing > Date: Thu, 8 Jan 2009 03:44:40 +0000 > > Is table-based exception handling close to being feasible on many > targets? > I figured it was mostly a lost cause but wouldn't mind being wrong. > Perhaps the evolution of gcc has made it much easier these days? > You know, what with Ada and C++ exception handling support being > whatever it is? > > Imho target-specific information should be > kept to a minimum > kept to a minimum number of places/files > perhaps kept to a minimum distance from other target-specific > information (places/files) > and like other information, not duplicated > > > If jumpbuf wasn't used by the compiler, then my position weakens. > However currently the size and alignment of jumpbuf is duplicated. > And endianness is duplicated. And wordsize is duplicated. > I wouldn't mind if jumpbuf was only, say, Csetjmp.i3, and wordsize > was only in the config file. > But duplication bugs me. > > > why context for exception handling vs. setjmp/longjmp. > > Just my ignorant questioning. If setjmp/longjmp suffice, ok. > They are just similar and perhaps if switch one, switch the other. > I realize that longjmp can only officially be called once per > setjmp, and that contexts are "reusable" (can be swapped an > arbitrary number of times). > > - Jay > > > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Thu, 8 Jan 2009 13:46:58 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] duplication between compiler, m3makefile, and > libraries; cross build easing > > Why would the compiler know anything about jmpbuf in general? (Yes, > I know it is used for exception handling). I would prefer that we > had table-based exception handling as on SOLgnu for all targets, but > that depends on support for stack unwinding for each target. I > would hate for the compiler to inject a type for something like > jmpbuf which is an *internal* detail of the exceptions > implementation rather than a language-defined type. Also, there are > advantages in the current approach, which decouples communication of > information amongst the tool-chain components. > > > Why would you use setcontext, getcontext, etc. for exception > handling. setjmp/longjmp are perfectly adequate to the task. > setcontext/getcontext are intended for user-thread switching, etc. > > I think you'll find there already is a compiler mode that does not > invoke cm3cg. > > 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 8 Jan 2009, at 00:36, Jay wrote: > > duplication between compiler, m3makefile, and libraries. > > > I propose that there should be reduced or no duplication > among the compiler, m3makefile, and libraries. > > > I propose that the compiler reveal (some) of what it knows. > > > For example, m3makefile shall not specify WORD_SIZE. > The compiler should. > Granted, this buys very little. > > > m3makefile shall not contain tables identifiying endianness. > Compiler shall defined TARGET_ENDIAN to "BIG" or "LITTLE", > or perhaps "big" or "little". > Granted, this buys very little. > > > Libraries shall not define jumpbuf, in a sense. > Compile shall define, something like: > TARGET_JUMPBUF_ELEMENT = "INTEGER" or "LONGINT". > aka jmpbuf alignment. > TARGET_JUMPBUF_SIZE = a decimal integer. > Leaving library to say: > TYPE jmpbuf = ARRAY [1..size] OF element > which m3makefile shall produce. > > > or perhaps even compiler shall inject the type itself, > as it injects a few things like INTERFACE Word functions. > > > or compiler shall define TARGET_JUMPBUF_ALIGN = 32 or 64, > and TARGET_JUMPBUF_SIZE in bytes > leaving m3makefile to map 32 to Ctypes.int and 64 to LONGINT itself. > > > The jumpbuf size/align bothers me more than word size and endianness. > Word size and endianness are more widely known to humans I think. > Endianness and word size are usually fairly obvious, though > not 100%. I didn't know the endianness of e.g. 88k, vax, and the > historically > terse names don't make it obvious. > > > However, let me not confuse "jumpbuf" with "Thread.State" or such. > Assume user threads stops using setjmp/longjmp and modify > or generalize proposal accordingly. > > Wonder if exception handling should use set/get/make/swapcontext > also?? > Assume jumpbuf might remain on some platforms? > > ? > > As well, one should be able to specify m3config on the command line. > One should be able to specify target on the command line. > Compiler shall take specified target and search /somehow/ for the > right config file. > Perhaps in path to cm3\..\config\target. > Don't probe like crazy -- not like I have it coded in Quake currently. > That really bites when there is more than one, and you edit the > wrong one. > > Probably something like, > probe for path to cm3\..\config\target. > > but if defined $CM3_CONFIG_DIRECTORY, search instead > $CM3_CONFIG_DIRECTORY\target. > however this is perhaps colon or semicolon delimited, so maybe > CM3_CONFIG_PATH. > (In particular, I have nearly all my config files in m3-sys/ > cminstall/src/config-no-install, > except NT386, which I'd really like to move, but will probably break > something and > doesn't seem important). > > Reasonable ideas? > > > Personally what I do is my Python scripts accept a target name > anywhere on the > command line, and if present, they set $M3CONFIG. > So I have what I want via python already. > You know, kind of a successful (imho) prototype, that should perhaps > be elevated > into the "real" stuff? > > > You know, make it easier and easier to contruct cross-capable > installations, > where switching targets is changing environment variables and/or > command lines, > and not editing/copying files. > > > If there isn't already, there should be a mode that doesn't run cm3cg. > And possibly can still ship. > That way /any/ system can do a bunch of cross-build "checking". > And the file system layout for creating a "boot" archive becomes > about the same as the layout of a "real" system. > Not like what I use -- I use one flat directory, since Modula-3 > requires that every..basically ever .i3, .m3, .o file have a unique > name. > (.i3 and .m3 can clash with each other, once each, that's it). > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 8 06:28:12 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 8 Jan 2009 05:28:12 +0000 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: <234B3116-4C98-470B-9929-3E2AC72D67DC@cs.purdue.edu> References: <20090103011227.vgpfs347400088sg@mail.elegosoft.com> <44664E56-D816-4A94-AD2E-96A0DB383DDF@cs.purdue.edu> <234B3116-4C98-470B-9929-3E2AC72D67DC@cs.purdue.edu> Message-ID: > [Jay] Some programs "better" with user threads > [Tony] Is this still true for modern kernel thread systems? I really don't know. Olaf /kind of/ indicated so (just in saying that it'd be a nice option to have). > [Jay] small stacks for many threads vs. larger stacks for calls to "the system" > [Tony] In a systems programming language like Modula-3 shouldn't threads have a relationship to the system? Some might just be doing computation? > This will need to be a link-time distinction. > I would hate to have both kernel and user thread code live in the same compiled run-time system. I understand the principle, and I don't have a working implementation to argue with, but I do find this surprising. In my mind, you take MODULE ThreadPThread EXPORTS Scheduler, Thread, etc. change it to MODULE ThreadPThread Exports SchedulerPThread, ThreadPThread, etc. and introduce MODULE Thread EXPORTS Scheduler, Thread, etc. PROCEDURE Fork()= BEGIN IF KernelThreads RETURN ThreadPThread.Fork(); ELSE RETURN ThreadPosix.Fork(); END; END Fork. And so on. The potential bloat would be, you get both copies of code, both copies of globals, possibly initialization (but this most likely be avoided) and if any of the types are transparent, such that caller can allocate them on the stack, you end up either with the larger of the two sizes, or using a heap allocation with a dynamically chosen size. It seems to be roughly one source file each of bloat. >[Tony]I see no problem with factoring out the threads subsystem as a separate library and linking accordingly. That would prevent the bloat, indeed. However, if you mean, like m3coreuserthreads.dll, m3corekernelthreads.dll, well, the vast bulk of each of those two files would be identical. You could maybe factor out m3kernelthreads.dll m3userthreads.dll out of m3core.dll and have m3core.dll dynamically chose one of them. That might be good. But personally..I'd like fewer .dlls, even if that means larger .dlls. >I would argue for user vs. kernel. I think you are right. Kind of like the NT386 platform argument. There are many real implementation choices, but they need not be all exposed to the user, esp. unless/until someone asks. If Cygwin pthreads made to work, and then if there are proponents of it over NT threads, and vice versa, add a switch, pick a default. In the meantime, I only made one of three options work. >And managing the state-space explosion that multiple choices might entail. I would like to avoid that. What do you mean? Growing types to the union? The globals and code bloat? Globals could all be pushed into a heap allocated pointer anyway, paying a perf cost that would unlikely be noticed. Again, I kind'a'thunk linking both in would be pretty ok, it's basically just one source file, but I haven't done it yet. Before I do this I need to be working on a platform with user threads, and then make them work, and then make them "switchable", and I want to bring up more platforms before I work on any user threads. AMD64_FREEBSD I think will be next. > I am not so sure, since it would entail some fairly low-level > and expensive decisions that would best instead be done at link-time. Again this doesn't agree with my /suspicion/ but I didn't do enough research/work to be all that informed.. > Actually, for non-standalone (dynamically-linked) code > we could make the choice at dynamic load time using the OS's support for dynamic library choice. I'd rather not use dlopen et. al. at least not until I understand various details of dynamic loading across more platforms. I always though Win32 did it all just about right, and then I find a surprising array of other implementation choices and options on other systems.. > I note that Solaris (but not Solaris Modula-3) currently lets > dynamically linked C programs choose among 3 different threads implementations dynamically. Too much of a good thing imho... At least in Windows, there are a lot of "in-process plugins", and often times, interoperating code has to agree on the same underlying pieces, so wherever there is a choice, is an opportunity to fail. For example, if I call malloc and give you the result to free, or I call fopen and give it to you to fwrite, we need to be using the same C runtime. Even Linux has a few to chose from -- glibc, dietlibc, uclibc, newlib, etc. If you push "plugins" out of process, things become usually easier. Then folks either interoperate through carefully formatted files / pipes, network protocols, or RPC, and not via function calls. I only knew of two threading libraries on Solaris, "pre-pthreads" and "pthreads". Oh, maybe "lwp" and "thr"? I was wondering -- these are all built on the same kernel threads, right? So if you use a mix of them in a process, you still get reasonable global scheduling, right? ie: There's no point in writing ThreadSolarisThis.m3 or ThreadSolarisThat.m3, ThreadPThread.m3 suffices plenty? Coming back to the bloat issue. If you make the transform I show, you could also have a variant of Thread.m3 that just calls ThreadPThread.m3 directly. That is, it should be easy (still not having done it) to alter the code to build both of m3coreboth.dll and m3corejustkernel.dll. They can both have the interface that accepts the request or mandate for user threads, and m3corejustkernel.dll could either ignore or error on it. Users could install one or the other .dll as m3core.dll. Of course you could alos build m3corejustuser.dll. (These are stupid names, I know.) I really need to try it and see, it's fairly hypothetical right now. It sounds like I might be missing something. But first some other things.. - Jay CC: wagner at elegosoft.com; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] dynamic chose between user/kernel threads?Date: Thu, 8 Jan 2009 13:51:15 +1100 Jay, perhaps you can provide some context and motivation for your proposals. I am unable to evaluate your proposals in the form of a simple laundry-list. On 8 Jan 2009, at 01:34, Jay wrote: I looked into this a bit..and I think it's actually pretty easy.It hardly churns the code even. I have other things I want to do first. In the meantime, specify the directive?There are actually a large number of subtle options. Can I ask for any of n libraries -- NT, pthreads, user threads? setjmp vs. context? Or is it just a boolean, user vs. kernel? Is the option to "favor" or "require" a certain library? Can I set it on libraries or only programs? What if the requests clash? Is it "Favor" or "Require"?Is it a function call or setting a global variable?I favor function call, but TARGET, WORD_SIZE, BUILD_DIR establish the other precedent,and either can work. Is it flags in the moduleinfo like incgc, gengc, or separate data thatthere is just one of in RTLinker? Probably separate data, unless it is allowed in libraries. What are the names of the libraries? "posix" and "pthreads" ? "user" and "kernel" ? "true" and "false" (or vice versa) ? Should NT implement user threads, using fibers? Presumably it works with both standalone and shared/dynamic programs.Presumably it is ok to always bloat up m3core.dll with both libraries.Presumably it is ok to have everyone pay a teeny tiny perf. That is, there is a microscopic dispatching layer, that everyone ends up going through, not chosing to link in one library or the other. And as part of this, whenever it happens, can we bump up the minimumbootstrap to a version that includes SchedulerPosix.DoesWaitPidYield()?Or does it become VAR Scheduler.UsingKerneThreads?(no, it should be a function; but naming matter remains). (ie. as I said, the decision currently is baked into m3core.dll, butnow it is also baked into sysutils.dll, but these should change together;m3core.dll should manage the knowledge). - Jay> Date: Sat, 3 Jan 2009 01:12:27 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] dynamic chose between user/kernel threads?> > An option to cm3 or a quake directive to use in the m3makefiles> would suffice in my opinion (and be a great improvement).> > Olaf> > Quoting Jay :> > >> > Should the user/kernel thread chose be available:> >> >> > On the command line to a Modula-3 executable (or even an executable > > where main is in another language, but which static or dynamic > > Modula-3 libs are used)?> >> >> > Via a quake directive when building programs?> >> >> > You know, imagine you have a bunch of Modula-3 programs and some but > > not all use a very large number of threads and benefit from > > userthreads.> >> >> > Currently the chose is locked into m3core when it is built.> >> >> > - Jay> > > -- > Olaf -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 8 07:36:44 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 8 Jan 2009 06:36:44 +0000 Subject: [M3devel] making Uerror "portable"? Message-ID: I've been thinking about "fixing" Uerrorto remove the system-dependentness of it. I have about given up. There are multiple easy options, but theyall have downsides that make me think itmight not be worth it. today it looks like: INTERFACE Uerror; CONST ENOFILE = 1; ENOMEM = 2; END Uerror; The values are intended the correct native values. There are a fair number of users. Fewer than 10 probably.They include switch/case statements, which requireconstants. The following are some of the possible changes,that make porting to basically any future systembe a no-op in this area, except for the occasional missing or possiblyequal errnos (if there is a switch in the C code; I ran into this case). - Change to VAR and initialize them in portable C code. disadvantages: more startup code possibly startup code runs too late more writable/written data (readonly data is best) slower to access not constant, not switchable, not source quite compatible You have to change the switch statements to "if ladders" (if/elseif/elseif/elseif). Compatible with most source, and incompatible source easily fixed. possible issues around "dynamic linking data" (not explained here, ask?) However not really a problem. More of a problem only on NT, and easily worked around just like is done for hand.obj. - change to VAR and const static initialize them in portable C "data" no additional startup code -- guaranteed initialized early enough no writable/written data slower to access not constant, not switchable, not source compatible (same as previous) same non-issue around dynamic linking of data - change to functions GetENOFILE(), GetENOMEM(), etc. slower to access definitely no problem dynamic linking easier to write the C code/data, no matter, the above are easy enough not constant, not switchable, not source compatible (similar to previous) - "translation"; introduce our own arbitrary values for any errno the system uses; change Cerrno.GetErrno to have a switch and translate from the native values to ours. This is fully source compatible, dynamic link compatible, in-between perf wise (slower to GetErrnor, but then constant and just as comparable/switchable), no initialization cost. Question then though what does any raised exception look like? Do the values get translated back? Or translated to strings? SetErrno translates back? Translation is at first simple and is unique among portable solutions in its source compatibility, but I am leary of it. I would rather a solution that traffics in unmodified native errnos values, but I don't that is viable with both constness and portability. To a large extent, translation is ok. If you look at SocketPosix.i3, it uses the errno very briefly to determine the next step to take. I don't think it ever returns or RAISEs it (or an exception containing it). But other parts of the system Fmt.Int(errno) and raise that, thus these become values that move through more of the system and therefore disagreement with the underlying system might show through. There is also question of how to chose "Max". Set it large, like 200? Set it "correctly"? Probably a better option is to make the cache that is currently Max-sized be instead small and fixed-size (e.g. 64), and "search" it quickly instead of "indexing" it very quickly, and always kick out the least recently used. I also have to check what the contents actually are, perhaps they are constant-initializable. Thoughts? I was somewhat keen to do something here, but have pretty much given up and will just generate Uerror.i3 for Solaris, NetBSD, FreeBSD, AIX, Irix, HP-UX, etc.. I might still be able to remove the Usignal and Ustat system-dependentness in m3core/src/unix, but Uerror will probably stand asis (in linux-common, openbsd-common, cygwin). In particular, I was putting off any more ports till I got the amount of work needed to port reduced to my satisfaction. I think I'm nearly there. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Thu Jan 8 09:19:26 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 08 Jan 2009 00:19:26 -0800 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: Your message of "Thu, 08 Jan 2009 05:28:12 GMT." Message-ID: <200901080819.n088JQtJ021157@camembert.async.caltech.edu> Jay writes: >--_659eacae-e435-4dfa-807c-8eaabce063a9_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > ... >PROCEDURE Fork()=3D >BEGIN IF KernelThreads > RETURN ThreadPThread.Fork()=3B > ELSE > RETURN ThreadPosix.Fork()=3B > END=3B > END Fork. ... If it's implemented properly, on many architectures LOCK should be at most a couple of instructions. I think adding a couple of branches to it may make a significant difference. On those architectures it really ought to be inlined, too... Here's the "quick path" for LockMutex under user threads: INC (inCritical); IF m.holder = NIL THEN <* ASSERT self # NIL *> m.holder := self; DEC (inCritical); RETURN; END; Mika From jay.krell at cornell.edu Thu Jan 8 10:46:28 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 8 Jan 2009 09:46:28 +0000 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: <200901080819.n088JQtJ021157@camembert.async.caltech.edu> References: Your message of "Thu, 08 Jan 2009 05:28:12 GMT." <200901080819.n088JQtJ021157@camembert.async.caltech.edu> Message-ID: Ok, then make it function pointers. That is a little more work. It won't likely be inlined, but I doubt it ever is currently anyway. A good implementation will have that be zero or one instructions, but it might impede the processor reading ahead in the instruction stream. Zero instructions if the interfaces are actually exposed as function pointers, one instruction if they remain functions that just jump through a pointer. One instruction being much easier to implement probably. (Actually conditional branches better preserve inlinability, but it takes a sophisticated compiler to benefit). > at most a couple of instructions It's pretty hard to do anything in 2 instructions..esp. without inlining.. call, return, budget gone. Here's the uncontended non-recursive EnterCriticalSection for comparison, not as an example of exactly what Modula-3 does, but as what is surely an example of a fairly well implemented lock (albeit the data structure is on the large size, and does support recursion). 0:000> u ntdll!RtlEnterCriticalSectionntdll!RtlEnterCriticalSection:00000000`76d87850 fff3 push rbx00000000`76d87852 4883ec20 sub rsp,20h00000000`76d87856 f00fba710800 lock btr dword ptr [rcx+8],000000000`76d8785c 488bd1 mov rdx,rcx00000000`76d8785f 0f832c58ffff jae 00000000`76d7d091 contention or recursion presumably 00000000`76d87865 65488b042530000000 mov rax,qword ptr gs:[30h]00000000`76d8786e 488b4848 mov rcx,qword ptr [rax+48h]00000000`76d87872 c7420c01000000 mov dword ptr [rdx+0Ch],100000000`76d87879 33c0 xor eax,eax00000000`76d8787b 48894a10 mov qword ptr [rdx+10h],rcx00000000`76d8787f 4883c420 add rsp,20h00000000`76d87883 5b pop rbx00000000`76d87884 c3 ret and then let's follow the contended/recursive path: 0:000> u 76d7d09100000000`76d7d091 65488b042530000000 mov rax,qword ptr gs:[30h]00000000`76d7d09a 488bd9 mov rbx,rcx00000000`76d7d09d 488b5048 mov rdx,qword ptr [rax+48h] Presumably this is a check to see if this thread already has the critical section.00000000`76d7d0a1 48395110 cmp qword ptr [rcx+10h],rdx00000000`76d7d0a5 0f851413feff jne 00000000`76d5e3bf if not wait for other guy00000000`76d7d0ab 83410c01 add dword ptr [rcx+0Ch],1 if so, increment recursion count and done00000000`76d7d0af 33c0 xor eax,eax00000000`76d7d0b1 4883c420 add rsp,20h00000000`76d7d0b5 5b pop rbx00000000`76d7d0b6 c3 ret contended path not shown. So that's 13 instructions for initial entry, 15 instructions for recursive entry. 0:000> u ntdll!RtlLeaveCriticalSectionntdll!RtlLeaveCriticalSection:00000000`76d87800 4883ec28 sub rsp,28h00000000`76d87804 83410cff add dword ptr [rcx+0Ch],0FFFFFFFFh00000000`76d87808 7535 jne ntdll!RtlLeaveCriticalSection+0x3f (00000000`76d8783f)00000000`76d8780a 48895c2430 mov qword ptr [rsp+30h],rbx00000000`76d8780f 48897c2420 mov qword ptr [rsp+20h],rdi00000000`76d87814 48c7411000000000 mov qword ptr [rcx+10h],000000000`76d8781c bf01000000 mov edi,100000000`76d87821 488bd9 mov rbx,rcx00000000`76d87824 f00fc17908 lock xadd dword ptr [rcx+8],edi00000000`76d87829 83c701 add edi,100000000`76d8782c 83ffff cmp edi,0FFFFFFFFh00000000`76d8782f 0f854380fdff jne 00000000`76d5f87800000000`76d87835 488b5c2430 mov rbx,qword ptr [rsp+30h]00000000`76d8783a 488b7c2420 mov rdi,qword ptr [rsp+20h]00000000`76d8783f 33c0 xor eax,eax00000000`76d87841 4883c428 add rsp,28h00000000`76d87845 c3 ret 6 instructions for recursive exit. 17 instructions for last exit..I assume the conditional branch is to wake waiters. x86: 0:000> u ntdll!RtlEnterCriticalSectionntdll!RtlEnterCriticalSection:76f03580 8bff mov edi,edi76f03582 55 push ebp76f03583 8bec mov ebp,esp76f03585 83ec0c sub esp,0Ch76f03588 56 push esi76f03589 57 push edi76f0358a 8b7d08 mov edi,dword ptr [ebp+8]76f0358d 8d7704 lea esi,[edi+4]76f03590 8bc6 mov eax,esi76f03592 f00fba3000 lock btr dword ptr [eax],076f03597 0f83bec60000 jae (76f0fc5b)76f0359d 64a118000000 mov eax,dword ptr fs:[00000018h]76f035a3 8b4824 mov ecx,dword ptr [eax+24h]76f035a6 894f0c mov dword ptr [edi+0Ch],ecx76f035a9 c7470801000000 mov dword ptr [edi+8],176f035b0 5f pop edi76f035b1 33c0 xor eax,eax76f035b3 5e pop esi76f035b4 8be5 mov esp,ebp76f035b6 5d pop ebp76f035b7 c20400 ret 4 21 instructions for initial entry 0:000> u 76f0fc5b76f0fc5b 648b0d18000000 mov ecx,dword ptr fs:[18h]76f0fc62 8b570c mov edx,dword ptr [edi+0Ch]76f0fc65 3b5124 cmp edx,dword ptr [ecx+24h]76f0fc68 0f8584de0000 jne 76f1daf276f0fc6e 83470801 add dword ptr [edi+8],176f0fc72 5f pop edi76f0fc73 33c0 xor eax,eax76f0fc75 5e pop esi76f0fc76 8be5 mov esp,ebp76f0fc78 5d pop ebp76f0fc79 c20400 ret 4 22 for recursive entry. ntdll!RtlLeaveCriticalSection:76f035c0 8bff mov edi,edi76f035c2 55 push ebp76f035c3 8bec mov ebp,esp76f035c5 56 push esi76f035c6 8b7508 mov esi,dword ptr [ebp+8]76f035c9 834608ff add dword ptr [esi+8],0FFFFFFFFh76f035cd 7525 jne ntdll!RtlLeaveCriticalSection+0x34 (76f035f4)76f035cf 53 push ebx76f035d0 57 push edi76f035d1 8d7e04 lea edi,[esi+4]76f035d4 c7460c00000000 mov dword ptr [esi+0Ch],076f035db bb01000000 mov ebx,176f035e0 8bc7 mov eax,edi76f035e2 f00fc118 lock xadd dword ptr [eax],ebx76f035e6 83c301 add ebx,176f035e9 83fbff cmp ebx,0FFFFFFFFh76f035ec 0f85d8a50100 jne 76f1dbca76f035f2 5f pop edi76f035f3 5b pop ebx76f035f4 33c0 xor eax,eax76f035f6 5e pop esi76f035f7 5d pop ebp76f035f8 c20400 ret 4 11 instructions for recursive exit.23 instructions for last exit, I guess, without waiters. - Jay> To: jay.krell at cornell.edu> Date: Thu, 8 Jan 2009 00:19:26 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] dynamic chose between user/kernel threads?> > Jay writes:> >--_659eacae-e435-4dfa-807c-8eaabce063a9_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> ...> >PROCEDURE Fork()=3D> >BEGIN IF KernelThreads> > RETURN ThreadPThread.Fork()=3B> > ELSE> > RETURN ThreadPosix.Fork()=3B> > END=3B> > END Fork.> ...> > If it's implemented properly, on many architectures LOCK should be> at most a couple of instructions. I think adding a couple of> branches to it may make a significant difference. On those> architectures it really ought to be inlined, too...> > Here's the "quick path" for LockMutex under user threads:> > INC (inCritical);> IF m.holder = NIL THEN> <* ASSERT self # NIL *>> m.holder := self;> DEC (inCritical);> RETURN;> END;> > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jan 8 14:38:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 08 Jan 2009 14:38:25 +0100 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: <234B3116-4C98-470B-9929-3E2AC72D67DC@cs.purdue.edu> References: <20090103011227.vgpfs347400088sg@mail.elegosoft.com> <44664E56-D816-4A94-AD2E-96A0DB383DDF@cs.purdue.edu> <234B3116-4C98-470B-9929-3E2AC72D67DC@cs.purdue.edu> Message-ID: <20090108143825.2rggu3h0xkwgws80@mail.elegosoft.com> As I noted earlier, I think that a link-time choice between (M3) user and system (kernel/p) threads would be completely satisfactory. Default could be pthreads/system threads, and cm3 -uthreads or cm3 -m3threads could substitute the old but efficient M3 implementation (with proper getcontext/makecontext for all target platforms ;-). Olaf Quoting Tony Hosking : > On 8 Jan 2009, at 14:10, Jay wrote: > >> Olaf understood the point (I think). :) >> >> Some programs, people say, and I believe, run "better" (faster, >> without running out of address space) with user threads instead of >> kernel threads. > > Is this still true for modern kernel thread systems? > >> On systems that have both. >> A good example might be a program that needs lots of threads and >> therefore small stacks, and the kernel threads, due to code below >> the Modula-3 runtime, might force fairly large stacks. (Such a >> program might have to adjust thread size differently for different >> threads, and only call into the underlying system on threads with >> larger stacks.) > > In a systems programming language like Modula-3 shouldn't threads have > a relationship to the system? > >> It might be nice for such programs to be able to mandate or request >> (two slightly different things) that the user thread library be >> used by them, even if the platform's default is to use kernel >> threads. > > This will need to be a link-time distinction. I would hate to have > both kernel and user thread code live in the same compiled run-time > system. > >> The only minor detail then is, how to express the request, and the >> precise meaning. >> It is a request or a mandate? > > I see no problem with factoring out the threads subsystem as a > separate library and linking accordingly. > >> As well, if the issue is address space, sholud there a "built in" >> way to only make the request on 32bit platforms, or should uses >> manually say if equal (WORD_SIZE, "32BITS")? >> >> Is it a boolean or an enum? >> Cygwin might conceivably get pthreads support (Cygwin has it, but >> Modula-3/Cygwin does not). >> Therefore, is the choice among "posix" threads, "pthreads" and "NT" >> threads? >> Or just user vs. kernel? > > I would argue for user vs. kernel. > >> I think the "important" part here is easy to implement. >> But again.. > > And managing the state-space explosion that multiple choices might > entail. I would like to avoid that. > >> The easier straightforward implementation always links both pieces >> of code in and makes a choice early in startup as to which to use, >> either setting a boolean, or an enum, or a pointer to a record of >> function pointers. This means that people that don't care to ever >> use user threads pay a small price, in code bloat and probably in >> a few extra instructions per certain functions. This is probably >> ok. > > I am not so sure, since it would entail some fairly low-level and > expensive decisions that would best instead be done at link-time. > >> However if that was not ok, the choice could be made at link time >> and only be supported for standalone programs. > > Actually, for non-standalone (dynamically-linked) code we could make > the choice at dynamic load time using the OS's support for dynamic > library choice. > > I note that Solaris (but not Solaris Modula-3) currently lets > dynamically linked C programs choose among 3 different threads > implementations dynamically. > >> >> >> - Jay >> >> >> >> >> CC: wagner at elegosoft.com; m3devel at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Subject: Re: [M3devel] dynamic chose between user/kernel threads? >> Date: Thu, 8 Jan 2009 13:51:15 +1100 >> >> >> Jay, perhaps you can provide some context and motivation for your >> proposals. I am unable to evaluate your proposals in the form of a >> simple laundry-list. >> >> On 8 Jan 2009, at 01:34, Jay wrote: >> >> I looked into this a bit..and I think it's actually pretty easy. >> It hardly churns the code even. >> >> >> I have other things I want to do first. >> >> >> In the meantime, specify the directive? >> There are actually a large number of subtle options. >> >> >> Can I ask for any of n libraries -- NT, pthreads, user threads? >> setjmp vs. context? Or is it just a boolean, user vs. kernel? >> >> >> Is the option to "favor" or "require" a certain library? >> >> >> Can I set it on libraries or only programs? >> What if the requests clash? >> >> >> Is it "Favor" or "Require"? >> Is it a function call or setting a global variable? >> I favor function call, but TARGET, WORD_SIZE, BUILD_DIR establish >> the other precedent, >> and either can work. >> >> Is it flags in the moduleinfo like incgc, gengc, or separate data that >> there is just one of in RTLinker? Probably separate data, unless it >> is allowed in libraries. >> >> >> What are the names of the libraries? >> "posix" and "pthreads" ? >> "user" and "kernel" ? >> "true" and "false" (or vice versa) ? >> >> >> Should NT implement user threads, using fibers? >> >> >> Presumably it works with both standalone and shared/dynamic programs. >> Presumably it is ok to always bloat up m3core.dll with both libraries. >> Presumably it is ok to have everyone pay a teeny tiny perf. >> That is, there is a microscopic dispatching layer, that everyone >> ends up going through, not chosing to link in one library or the other. >> >> >> And as part of this, whenever it happens, can we bump up the minimum >> bootstrap to a version that includes SchedulerPosix.DoesWaitPidYield()? >> Or does it become VAR Scheduler.UsingKerneThreads? >> (no, it should be a function; but naming matter remains). >> >> >> (ie. as I said, the decision currently is baked into m3core.dll, but >> now it is also baked into sysutils.dll, but these should change together; >> m3core.dll should manage the knowledge). >> >> >> - Jay >> >> >>> Date: Sat, 3 Jan 2009 01:12:27 +0100 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] dynamic chose between user/kernel threads? >>> >>> An option to cm3 or a quake directive to use in the m3makefiles >>> would suffice in my opinion (and be a great improvement). >>> >>> Olaf >>> >>> Quoting Jay : >>> >>> > >>> > Should the user/kernel thread chose be available: >>> > >>> > >>> > On the command line to a Modula-3 executable (or even an executable >>> > where main is in another language, but which static or dynamic >>> > Modula-3 libs are used)? >>> > >>> > >>> > Via a quake directive when building programs? >>> > >>> > >>> > You know, imagine you have a bunch of Modula-3 programs and some but >>> > not all use a very large number of threads and benefit from >>> > userthreads. >>> > >>> > >>> > Currently the chose is locked into m3core when it is built. >>> > >>> > >>> > - Jay >>> >>> >>> -- >>> Olaf >> >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jan 8 15:51:05 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 8 Jan 2009 14:51:05 +0000 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: <20090108143825.2rggu3h0xkwgws80@mail.elegosoft.com> References: <20090103011227.vgpfs347400088sg@mail.elegosoft.com> <44664E56-D816-4A94-AD2E-96A0DB383DDF@cs.purdue.edu> <234B3116-4C98-470B-9929-3E2AC72D67DC@cs.purdue.edu> <20090108143825.2rggu3h0xkwgws80@mail.elegosoft.com> Message-ID: I think you didn't realize some of what I was lumping into "link time". It could mean "constructing main to pass a parameter to RTLinker". Or setting a flag in the Main module (like how gengc/incgc flags are set in all modules, but this is a more difficult and likely wasteful change, no need to burn a bit in all modules, just the main module). I still think function pointers would suffice, costing zero or one instruction per function call.. But I haven't tried it yet. Systems with "build variants" tend to get "explosive" -- combinatorial explosions of "configurations". Boost is good (bad) example of this. - Jay> Date: Thu, 8 Jan 2009 14:38:25 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] dynamic chose between user/kernel threads?> > As I noted earlier, I think that a link-time choice between> (M3) user and system (kernel/p) threads would be completely> satisfactory. Default could be pthreads/system threads, and> cm3 -uthreads or cm3 -m3threads could substitute the old but> efficient M3 implementation (with proper getcontext/makecontext> for all target platforms ;-).> > Olaf> > Quoting Tony Hosking :> > > On 8 Jan 2009, at 14:10, Jay wrote:> >> >> Olaf understood the point (I think). :)> >>> >> Some programs, people say, and I believe, run "better" (faster, > >> without running out of address space) with user threads instead of > >> kernel threads.> >> > Is this still true for modern kernel thread systems?> >> >> On systems that have both.> >> A good example might be a program that needs lots of threads and > >> therefore small stacks, and the kernel threads, due to code below > >> the Modula-3 runtime, might force fairly large stacks. (Such a > >> program might have to adjust thread size differently for different > >> threads, and only call into the underlying system on threads with > >> larger stacks.)> >> > In a systems programming language like Modula-3 shouldn't threads have> > a relationship to the system?> >> >> It might be nice for such programs to be able to mandate or request > >> (two slightly different things) that the user thread library be > >> used by them, even if the platform's default is to use kernel > >> threads.> >> > This will need to be a link-time distinction. I would hate to have> > both kernel and user thread code live in the same compiled run-time> > system.> >> >> The only minor detail then is, how to express the request, and the > >> precise meaning.> >> It is a request or a mandate?> >> > I see no problem with factoring out the threads subsystem as a> > separate library and linking accordingly.> >> >> As well, if the issue is address space, sholud there a "built in" > >> way to only make the request on 32bit platforms, or should uses > >> manually say if equal (WORD_SIZE, "32BITS")?> >>> >> Is it a boolean or an enum?> >> Cygwin might conceivably get pthreads support (Cygwin has it, but > >> Modula-3/Cygwin does not).> >> Therefore, is the choice among "posix" threads, "pthreads" and "NT" > >> threads?> >> Or just user vs. kernel?> >> > I would argue for user vs. kernel.> >> >> I think the "important" part here is easy to implement.> >> But again..> >> > And managing the state-space explosion that multiple choices might> > entail. I would like to avoid that.> >> >> The easier straightforward implementation always links both pieces > >> of code in and makes a choice early in startup as to which to use, > >> either setting a boolean, or an enum, or a pointer to a record of > >> function pointers. This means that people that don't care to ever > >> use user threads pay a small price, in code bloat and probably in > >> a few extra instructions per certain functions. This is probably > >> ok.> >> > I am not so sure, since it would entail some fairly low-level and> > expensive decisions that would best instead be done at link-time.> >> >> However if that was not ok, the choice could be made at link time > >> and only be supported for standalone programs.> >> > Actually, for non-standalone (dynamically-linked) code we could make> > the choice at dynamic load time using the OS's support for dynamic> > library choice.> >> > I note that Solaris (but not Solaris Modula-3) currently lets> > dynamically linked C programs choose among 3 different threads> > implementations dynamically.> >> >>> >>> >> - Jay> >>> >>> >>> >>> >> CC: wagner at elegosoft.com; m3devel at elegosoft.com> >> From: hosking at cs.purdue.edu> >> To: jay.krell at cornell.edu> >> Subject: Re: [M3devel] dynamic chose between user/kernel threads?> >> Date: Thu, 8 Jan 2009 13:51:15 +1100> >>> >>> >> Jay, perhaps you can provide some context and motivation for your > >> proposals. I am unable to evaluate your proposals in the form of a > >> simple laundry-list.> >>> >> On 8 Jan 2009, at 01:34, Jay wrote:> >>> >> I looked into this a bit..and I think it's actually pretty easy.> >> It hardly churns the code even.> >>> >>> >> I have other things I want to do first.> >>> >>> >> In the meantime, specify the directive?> >> There are actually a large number of subtle options.> >>> >>> >> Can I ask for any of n libraries -- NT, pthreads, user threads?> >> setjmp vs. context? Or is it just a boolean, user vs. kernel?> >>> >>> >> Is the option to "favor" or "require" a certain library?> >>> >>> >> Can I set it on libraries or only programs?> >> What if the requests clash?> >>> >>> >> Is it "Favor" or "Require"?> >> Is it a function call or setting a global variable?> >> I favor function call, but TARGET, WORD_SIZE, BUILD_DIR establish > >> the other precedent,> >> and either can work.> >>> >> Is it flags in the moduleinfo like incgc, gengc, or separate data that> >> there is just one of in RTLinker? Probably separate data, unless it > >> is allowed in libraries.> >>> >>> >> What are the names of the libraries?> >> "posix" and "pthreads" ?> >> "user" and "kernel" ?> >> "true" and "false" (or vice versa) ?> >>> >>> >> Should NT implement user threads, using fibers?> >>> >>> >> Presumably it works with both standalone and shared/dynamic programs.> >> Presumably it is ok to always bloat up m3core.dll with both libraries.> >> Presumably it is ok to have everyone pay a teeny tiny perf.> >> That is, there is a microscopic dispatching layer, that everyone> >> ends up going through, not chosing to link in one library or the other.> >>> >>> >> And as part of this, whenever it happens, can we bump up the minimum> >> bootstrap to a version that includes SchedulerPosix.DoesWaitPidYield()?> >> Or does it become VAR Scheduler.UsingKerneThreads?> >> (no, it should be a function; but naming matter remains).> >>> >>> >> (ie. as I said, the decision currently is baked into m3core.dll, but> >> now it is also baked into sysutils.dll, but these should change together;> >> m3core.dll should manage the knowledge).> >>> >>> >> - Jay> >>> >>> >>> Date: Sat, 3 Jan 2009 01:12:27 +0100> >>> From: wagner at elegosoft.com> >>> To: m3devel at elegosoft.com> >>> Subject: Re: [M3devel] dynamic chose between user/kernel threads?> >>>> >>> An option to cm3 or a quake directive to use in the m3makefiles> >>> would suffice in my opinion (and be a great improvement).> >>>> >>> Olaf> >>>> >>> Quoting Jay :> >>>> >>> >> >>> > Should the user/kernel thread chose be available:> >>> >> >>> >> >>> > On the command line to a Modula-3 executable (or even an executable> >>> > where main is in another language, but which static or dynamic> >>> > Modula-3 libs are used)?> >>> >> >>> >> >>> > Via a quake directive when building programs?> >>> >> >>> >> >>> > You know, imagine you have a bunch of Modula-3 programs and some but> >>> > not all use a very large number of threads and benefit from> >>> > userthreads.> >>> >> >>> >> >>> > Currently the chose is locked into m3core when it is built.> >>> >> >>> >> >>> > - Jay> >>>> >>>> >>> --> >>> Olaf> >>> >>> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Jan 9 01:01:26 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 9 Jan 2009 11:01:26 +1100 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: <20090108143825.2rggu3h0xkwgws80@mail.elegosoft.com> References: <20090103011227.vgpfs347400088sg@mail.elegosoft.com> <44664E56-D816-4A94-AD2E-96A0DB383DDF@cs.purdue.edu> <234B3116-4C98-470B-9929-3E2AC72D67DC@cs.purdue.edu> <20090108143825.2rggu3h0xkwgws80@mail.elegosoft.com> Message-ID: I err on the side of simplicity, until there is an obvious need for adding complexity. In this case, I concur with Olaf that the most we would need is a simple link-time switch. 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 9 Jan 2009, at 00:38, Olaf Wagner wrote: > As I noted earlier, I think that a link-time choice between > (M3) user and system (kernel/p) threads would be completely > satisfactory. Default could be pthreads/system threads, and > cm3 -uthreads or cm3 -m3threads could substitute the old but > efficient M3 implementation (with proper getcontext/makecontext > for all target platforms ;-). > > Olaf > > Quoting Tony Hosking : > >> On 8 Jan 2009, at 14:10, Jay wrote: >> >>> Olaf understood the point (I think). :) >>> >>> Some programs, people say, and I believe, run "better" (faster, >>> without running out of address space) with user threads instead >>> of kernel threads. >> >> Is this still true for modern kernel thread systems? >> >>> On systems that have both. >>> A good example might be a program that needs lots of threads and >>> therefore small stacks, and the kernel threads, due to code >>> below the Modula-3 runtime, might force fairly large stacks. >>> (Such a program might have to adjust thread size differently for >>> different threads, and only call into the underlying system on >>> threads with larger stacks.) >> >> In a systems programming language like Modula-3 shouldn't threads >> have >> a relationship to the system? >> >>> It might be nice for such programs to be able to mandate or >>> request (two slightly different things) that the user thread >>> library be used by them, even if the platform's default is to >>> use kernel threads. >> >> This will need to be a link-time distinction. I would hate to have >> both kernel and user thread code live in the same compiled run-time >> system. >> >>> The only minor detail then is, how to express the request, and >>> the precise meaning. >>> It is a request or a mandate? >> >> I see no problem with factoring out the threads subsystem as a >> separate library and linking accordingly. >> >>> As well, if the issue is address space, sholud there a "built >>> in" way to only make the request on 32bit platforms, or should >>> uses manually say if equal (WORD_SIZE, "32BITS")? >>> >>> Is it a boolean or an enum? >>> Cygwin might conceivably get pthreads support (Cygwin has it, >>> but Modula-3/Cygwin does not). >>> Therefore, is the choice among "posix" threads, "pthreads" and >>> "NT" threads? >>> Or just user vs. kernel? >> >> I would argue for user vs. kernel. >> >>> I think the "important" part here is easy to implement. >>> But again.. >> >> And managing the state-space explosion that multiple choices might >> entail. I would like to avoid that. >> >>> The easier straightforward implementation always links both >>> pieces of code in and makes a choice early in startup as to >>> which to use, either setting a boolean, or an enum, or a pointer >>> to a record of function pointers. This means that people that >>> don't care to ever use user threads pay a small price, in code >>> bloat and probably in a few extra instructions per certain >>> functions. This is probably ok. >> >> I am not so sure, since it would entail some fairly low-level and >> expensive decisions that would best instead be done at link-time. >> >>> However if that was not ok, the choice could be made at link >>> time and only be supported for standalone programs. >> >> Actually, for non-standalone (dynamically-linked) code we could make >> the choice at dynamic load time using the OS's support for dynamic >> library choice. >> >> I note that Solaris (but not Solaris Modula-3) currently lets >> dynamically linked C programs choose among 3 different threads >> implementations dynamically. >> >>> >>> >>> - Jay >>> >>> >>> >>> >>> CC: wagner at elegosoft.com; m3devel at elegosoft.com >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Subject: Re: [M3devel] dynamic chose between user/kernel threads? >>> Date: Thu, 8 Jan 2009 13:51:15 +1100 >>> >>> >>> Jay, perhaps you can provide some context and motivation for >>> your proposals. I am unable to evaluate your proposals in the >>> form of a simple laundry-list. >>> >>> On 8 Jan 2009, at 01:34, Jay wrote: >>> >>> I looked into this a bit..and I think it's actually pretty easy. >>> It hardly churns the code even. >>> >>> >>> I have other things I want to do first. >>> >>> >>> In the meantime, specify the directive? >>> There are actually a large number of subtle options. >>> >>> >>> Can I ask for any of n libraries -- NT, pthreads, user threads? >>> setjmp vs. context? Or is it just a boolean, user vs. kernel? >>> >>> >>> Is the option to "favor" or "require" a certain library? >>> >>> >>> Can I set it on libraries or only programs? >>> What if the requests clash? >>> >>> >>> Is it "Favor" or "Require"? >>> Is it a function call or setting a global variable? >>> I favor function call, but TARGET, WORD_SIZE, BUILD_DIR >>> establish the other precedent, >>> and either can work. >>> >>> Is it flags in the moduleinfo like incgc, gengc, or separate data >>> that >>> there is just one of in RTLinker? Probably separate data, unless >>> it is allowed in libraries. >>> >>> >>> What are the names of the libraries? >>> "posix" and "pthreads" ? >>> "user" and "kernel" ? >>> "true" and "false" (or vice versa) ? >>> >>> >>> Should NT implement user threads, using fibers? >>> >>> >>> Presumably it works with both standalone and shared/dynamic >>> programs. >>> Presumably it is ok to always bloat up m3core.dll with both >>> libraries. >>> Presumably it is ok to have everyone pay a teeny tiny perf. >>> That is, there is a microscopic dispatching layer, that everyone >>> ends up going through, not chosing to link in one library or the >>> other. >>> >>> >>> And as part of this, whenever it happens, can we bump up the minimum >>> bootstrap to a version that includes >>> SchedulerPosix.DoesWaitPidYield()? >>> Or does it become VAR Scheduler.UsingKerneThreads? >>> (no, it should be a function; but naming matter remains). >>> >>> >>> (ie. as I said, the decision currently is baked into m3core.dll, but >>> now it is also baked into sysutils.dll, but these should change >>> together; >>> m3core.dll should manage the knowledge). >>> >>> >>> - Jay >>> >>> >>>> Date: Sat, 3 Jan 2009 01:12:27 +0100 >>>> From: wagner at elegosoft.com >>>> To: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] dynamic chose between user/kernel threads? >>>> >>>> An option to cm3 or a quake directive to use in the m3makefiles >>>> would suffice in my opinion (and be a great improvement). >>>> >>>> Olaf >>>> >>>> Quoting Jay : >>>> >>>> > >>>> > Should the user/kernel thread chose be available: >>>> > >>>> > >>>> > On the command line to a Modula-3 executable (or even an >>>> executable >>>> > where main is in another language, but which static or dynamic >>>> > Modula-3 libs are used)? >>>> > >>>> > >>>> > Via a quake directive when building programs? >>>> > >>>> > >>>> > You know, imagine you have a bunch of Modula-3 programs and >>>> some but >>>> > not all use a very large number of threads and benefit from >>>> > userthreads. >>>> > >>>> > >>>> > Currently the chose is locked into m3core when it is built. >>>> > >>>> > >>>> > - Jay >>>> >>>> >>>> -- >>>> Olaf >>> >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 11 04:02:41 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Jan 2009 03:02:41 +0000 Subject: [M3devel] fw: alignment greater than longint? In-Reply-To: <20090111004447.5014E10D535B@birch.elegosoft.com> References: <20090111004447.5014E10D535B@birch.elegosoft.com> Message-ID: Well, I'm not a fan of cloning headers..and in this case it doesn't matter anyway, and I'm actively uncloning them, but a way to be explicit about alignment might be good..? PPC_LINUX setjmp.h declares jmpbuf to be aligned to 16, though the comments say that 4 aligned suffices. I made it have an array of LONGINT to get as close as I could. - Jay> Date: Sun, 11 Jan 2009 01:44:47 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > 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> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 11 09:58:55 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Jan 2009 08:58:55 +0000 Subject: [M3devel] making Uerror "portable"? Message-ID: I still find pushing the system dependencies and cloned headers out of the system very tempting. To reduce what it takes to port to other systems, to raise the confidence of the correctness of any port, to keep ports correct in the face of possible underlying change. I think I'll change the case statements to if/else ladders and the consts to vars, that are actually statically initialized in C. This treatment is reasonable for other constants that remain in the cloned headers, system dependent or otherwise. - Jay From: jay.krell at cornell.eduTo: m3devel at elegosoft.comSubject: making Uerror "portable"?Date: Thu, 8 Jan 2009 06:36:44 +0000 I've been thinking about "fixing" Uerrorto remove the system-dependentness of it. I have about given up. There are multiple easy options, but theyall have downsides that make me think itmight not be worth it. today it looks like: INTERFACE Uerror;CONST ENOFILE = 1; ENOMEM = 2;END Uerror; The values are intended the correct native values.There are a fair number of users.Fewer than 10 probably.They include switch/case statements, which requireconstants. The following are some of the possible changes,that make porting to basically any future systembe a no-op in this area, except for the occasional missing or possiblyequal errnos (if there is a switch in the C code; I ran into this case). - Change to VAR and initialize them in portable C code. disadvantages: more startup code possibly startup code runs too late more writable/written data (readonly data is best) slower to access not constant, not switchable, not source quite compatible You have to change the switch statements to "if ladders" (if/elseif/elseif/elseif). Compatible with most source, and incompatible source easily fixed. possible issues around "dynamic linking data" (not explained here, ask?) However not really a problem. More of a problem only on NT, and easily worked around just like is done for hand.obj. - change to VAR and const static initialize them in portable C "data" no additional startup code -- guaranteed initialized early enough no writable/written data slower to access not constant, not switchable, not source compatible (same as previous) same non-issue around dynamic linking of data - change to functions GetENOFILE(), GetENOMEM(), etc. slower to access definitely no problem dynamic linking easier to write the C code/data, no matter, the above are easy enough not constant, not switchable, not source compatible (similar to previous) - "translation"; introduce our own arbitrary values for any errno the system uses; change Cerrno.GetErrno to have a switch and translate from the native values to ours. This is fully source compatible, dynamic link compatible, in-between perf wise (slower to GetErrnor, but then constant and just as comparable/switchable), no initialization cost. Question then though what does any raised exception look like? Do the values get translated back? Or translated to strings? SetErrno translates back? Translation is at first simple and is unique among portable solutions in its source compatibility, but I am leary of it. I would rather a solution that traffics in unmodified native errnos values, but I don't that is viable with both constness and portability. To a large extent, translation is ok. If you look at SocketPosix.i3, it uses the errno very briefly to determine the next step to take. I don't think it ever returns or RAISEs it (or an exception containing it). But other parts of the system Fmt.Int(errno) and raise that, thus these become values that move through more of the system and therefore disagreement with the underlying system might show through. There is also question of how to chose "Max". Set it large, like 200? Set it "correctly"? Probably a better option is to make the cache that is currently Max-sized be instead small and fixed-size (e.g. 64), and "search" it quickly instead of "indexing" it very quickly, and always kick out the least recently used. I also have to check what the contents actually are, perhaps they are constant-initializable. Thoughts? I was somewhat keen to do something here, but have pretty much given up and will just generate Uerror.i3 for Solaris, NetBSD, FreeBSD, AIX, Irix, HP-UX, etc.. I might still be able to remove the Usignal and Ustat system-dependentness in m3core/src/unix, but Uerror will probably stand asis (in linux-common, openbsd-common, cygwin). In particular, I was putting off any more ports till I got the amount of work neededto port reduced to my satisfaction. I think I'm nearly there. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 11 13:57:13 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Jan 2009 12:57:13 +0000 Subject: [M3devel] Juno (X) networking problem on AMD64_FREEBSD Message-ID: Hi. Unix network programming question.. AMD64_FREEBSD: $DISPLAY is set to point back to Cygwin host.It works for PPC_LINUX. [jay at fbsdamd64a /cm3/bin]$ ./Juno ****** runtime error:*** Exception "IPError.FatalError" not in RAISES list*** file "../src/common/IPError.m3", line 27*** Abort trap: 6 (core dumped)[jay at fbsdamd64a /cm3/bin]$ IP.m3: PROCEDURE GetHostAddr(): Address = VAR hname: ARRAY [0..255] OF CHAR; BEGIN LOCK mu DO IF Unix.gethostname(ADR(hname[0]), BYTESIZE(hname)) # 0 THEN IPError.Die (); END; VAR h := Unetdb.gethostbyname(ADR(hname[0])); BEGIN IF h = NIL THEN IPError.Die(); END; RETURN GetAddress(h); END; END; END GetHostAddr; PROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Address = VAR ua: Uin.struct_in_addr; BEGIN <* ASSERT ent.h_length <= BYTESIZE(Address) *> ua := LOOPHOLE(ent.h_addr_list, UNTRACED REF UNTRACED REF Uin.struct_in_addr)^^; RETURN LOOPHOLE(ua.s_addr, Address); END GetAddress; gethostbyname is failing. Analogous C code also fails: [jay at fbsdamd64a /cm3/bin]$ cat ~/5.c#include #include #include #include typedef struct hostent hostent_t; int main(){ char hostname[200]; hostent_t* h; int i; i = gethostname(hostname, 200); assert(i == 0); printf("hostname: %s\n", hostname); h = gethostbyname(hostname); herror("foo"); printf("%p %d %d\n", h, errno, h_errno); assert(h); return 0;} herror says "unknown host". Stack is: at ../src/runtime/ex_frame/RTExFrame.m3:58#13 0x0000000801a7f2b3 in RTHooks__Raise (M3_AJWxb1_ex=Error accessing memory address 0x8000ffffd278: Bad address.) at ../src/runtime/common/RTHooks.m3:79#14 0x000000080169c8d3 in IPError__Die () at ../src/common/IPError.m3:27#15 0x0000000801698a3e in IP__GetHostAddr (M3_BCxjPn__result=Error accessing memory address 0x8000ffffd338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x00000008012133d0 in XSharedMem__SameHost (M3_AQuuui_trsl=Error accessing memory address 0x8000ffffd4d8: Bad address.) at ../src/xvbt/XSharedMem.m3:96#17 0x0000000801212ab7 in XSharedMem__InitXClient (M3_AQuuui_v=Error accessing memory address 0x8000ffffd648: Bad address.) at ../src/xvbt/XSharedMem.m3:29#18 0x0000000801211819 in XExtensions__InitXClient (M3_AQuuui_xclient=Error accessing memory address 0x8000ffffd7f8: Bad address.) at ../src/xvbt/XExtensions.m3:14#19 0x00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst=0x1879b, M3_AQuuui_trsl=0x6) at ../src/xvbt/XClientF.m3:583---Type to continue, or q to quit---(More stack frames follow...)(gdb) (* return TRUE if server and client are on same host *)PROCEDURE SameHost (trsl: XClient.T): BOOLEAN = VAR display := DisplayHost(trsl); displayAddr: IP.Address; BEGIN IF display = NIL THEN RETURN TRUE; END; TRY IF NOT IP.GetHostByName(display, displayAddr) THEN RETURN FALSE; END; RETURN displayAddr = IP.GetHostAddr(); EXCEPT | IP.Error => RETURN FALSE; END; END SameHost; Thoughts? Perhaps my network isn't setup well, like I should add the local machine to /etc/hosts.I think this can be made to fail gracefully though.It seems like it has nothing to do with AMD64_FREEBSD, but could have to do with FreeBSD. Seems like SocketPosix has nearly the exact same code but appearsmore forgiving.. IOError instead of Fatal? SocketPosix.m3: PROCEDURE GetHostAddr (): Address RAISES {OSError.E} = VAR host : ARRAY [0..255] OF CHAR; info : Unetdb.struct_hostent_star; ua : Uin.struct_in_addr; BEGIN IF Unix.gethostname (ADR (host[0]), BYTESIZE (host)) # 0 THEN IOError (Unexpected); END; info := Unetdb.gethostbyname (ADR (host[0])); IF info = NIL THEN IOError (Unexpected); END; <* ASSERT info.h_length <= BYTESIZE (Address) *> ua := LOOPHOLE(info.h_addr_list, UNTRACED REF UNTRACED REF Uin.struct_in_addr)^^; RETURN LOOPHOLE (ua.s_addr, Address); END GetHostAddr; It is again disappointing to see such code duplication. I guess SameHost can duplicate the logic to predict the error state and return false upon error? Duplicating the logic for a third time. :( - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 11 14:37:37 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Jan 2009 13:37:37 +0000 Subject: [M3devel] Juno (X) networking problem on AMD64_FREEBSD In-Reply-To: References: Message-ID: I commited a workaround here, that introduces essentially a third copy of relevant code. Anyone have further ideas? (* This is a clone of IP.GetHostAddr that returns TRUE if IP.GetHostAddr is likely to succeed and FALSE if IP.GetHostAddr is likely to fail. *) VAR mu := NEW(MUTEX); PROCEDURE PredictIPGetHostAddrSuccess(): BOOLEAN = VAR hname: ARRAY [0..255] OF CHAR; BEGIN LOCK mu DO RETURN (Unix.gethostname(ADR(hname[0]), BYTESIZE(hname)) = 0) AND (Unetdb.gethostbyname(ADR(hname[0])) # NIL); END; END PredictIPGetHostAddrSuccess; (* return TRUE if server and client are on same host *) PROCEDURE SameHost (trsl: XClient.T): BOOLEAN = VAR display := DisplayHost(trsl); displayAddr: IP.Address; BEGIN IF display = NIL THEN RETURN TRUE; END; TRY IF NOT IP.GetHostByName(display, displayAddr) THEN RETURN FALSE; END; (* IP.GetHostAddr can return a fatal exception; try to avoid that by predicting its success. *) IF NOT PredictIPGetHostAddrSuccess() THEN RETURN FALSE; END; RETURN displayAddr = IP.GetHostAddr(); EXCEPT | IP.Error => RETURN FALSE; END; END SameHost; - Jay From: jay.krell at cornell.eduTo: m3devel at elegosoft.comDate: Sun, 11 Jan 2009 12:57:13 +0000Subject: [M3devel] Juno (X) networking problem on AMD64_FREEBSD Hi. Unix network programming question..AMD64_FREEBSD:$DISPLAY is set to point back to Cygwin host.It works for PPC_LINUX.[jay at fbsdamd64a /cm3/bin]$ ./Juno****** runtime error:*** Exception "IPError.FatalError" not in RAISES list*** file "../src/common/IPError.m3", line 27***Abort trap: 6 (core dumped)[jay at fbsdamd64a /cm3/bin]$IP.m3: PROCEDURE GetHostAddr(): Address = VAR hname: ARRAY [0..255] OF CHAR; BEGIN LOCK mu DO IF Unix.gethostname(ADR(hname[0]), BYTESIZE(hname)) # 0 THEN IPError.Die (); END; VAR h := Unetdb.gethostbyname(ADR(hname[0])); BEGIN IF h = NIL THEN IPError.Die(); END; RETURN GetAddress(h); END; END; END GetHostAddr;PROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Address = VAR ua: Uin.struct_in_addr; BEGIN <* ASSERT ent.h_length <= BYTESIZE(Address) *> ua := LOOPHOLE(ent.h_addr_list, UNTRACED REF UNTRACED REF Uin.struct_in_addr)^^; RETURN LOOPHOLE(ua.s_addr, Address); END GetAddress; gethostbyname is failing. Analogous C code also fails: [jay at fbsdamd64a /cm3/bin]$ cat ~/5.c#include #include #include #include typedef struct hostent hostent_t; int main(){ char hostname[200]; hostent_t* h; int i; i = gethostname(hostname, 200); assert(i == 0); printf("hostname: %s\n", hostname); h = gethostbyname(hostname); herror("foo"); printf("%p %d %d\n", h, errno, h_errno); assert(h); return 0;} herror says "unknown host".Stack is: at ../src/runtime/ex_frame/RTExFrame.m3:58#13 0x0000000801a7f2b3 in RTHooks__Raise (M3_AJWxb1_ex=Error accessing memory address 0x8000ffffd278: Bad address.) at ../src/runtime/common/RTHooks.m3:79#14 0x000000080169c8d3 in IPError__Die () at ../src/common/IPError.m3:27#15 0x0000000801698a3e in IP__GetHostAddr (M3_BCxjPn__result=Error accessing memory address 0x8000ffffd338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x00000008012133d0 in XSharedMem__SameHost (M3_AQuuui_trsl=Error accessing memory address 0x8000ffffd4d8: Bad address.) at ../src/xvbt/XSharedMem.m3:96#17 0x0000000801212ab7 in XSharedMem__InitXClient (M3_AQuuui_v=Error accessing memory address 0x8000ffffd648: Bad address.) at ../src/xvbt/XSharedMem.m3:29#18 0x0000000801211819 in XExtensions__InitXClient (M3_AQuuui_xclient=Error accessing memory address 0x8000ffffd7f8: Bad address.) at ../src/xvbt/XExtensions.m3:14#19 0x00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst=0x1879b, M3_AQuuui_trsl=0x6) at ../src/xvbt/XClientF.m3:583---Type to continue, or q to quit---(More stack frames follow...)(gdb)(* return TRUE if server and client are on same host *)PROCEDURE SameHost (trsl: XClient.T): BOOLEAN = VAR display := DisplayHost(trsl); displayAddr: IP.Address; BEGIN IF display = NIL THEN RETURN TRUE; END; TRY IF NOT IP.GetHostByName(display, displayAddr) THEN RETURN FALSE; END; RETURN displayAddr = IP.GetHostAddr(); EXCEPT | IP.Error => RETURN FALSE; END; END SameHost; Thoughts? Perhaps my network isn't setup well, like I should add the local machine to /etc/hosts.I think this can be made to fail gracefully though.It seems like it has nothing to do with AMD64_FREEBSD, but could have to do with FreeBSD. Seems like SocketPosix has nearly the exact same code but appearsmore forgiving.. IOError instead of Fatal? SocketPosix.m3: PROCEDURE GetHostAddr (): Address RAISES {OSError.E} = VAR host : ARRAY [0..255] OF CHAR; info : Unetdb.struct_hostent_star; ua : Uin.struct_in_addr; BEGIN IF Unix.gethostname (ADR (host[0]), BYTESIZE (host)) # 0 THEN IOError (Unexpected); END; info := Unetdb.gethostbyname (ADR (host[0])); IF info = NIL THEN IOError (Unexpected); END; <* ASSERT info.h_length <= BYTESIZE (Address) *> ua := LOOPHOLE(info.h_addr_list, UNTRACED REF UNTRACED REF Uin.struct_in_addr)^^; RETURN LOOPHOLE (ua.s_addr, Address); END GetHostAddr; It is again disappointing to see such code duplication. I guess SameHost can duplicate the logic to predict the error state and return false upon error?Duplicating the logic for a third time. :( - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 11 15:44:14 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Jan 2009 14:44:14 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? Message-ID: Is there a way in Modula-3 to declare that a type exists, and there are <*external*> instances of it, without "fully" declaring it, so that no Modula-3 can instantiate it? I have done this for sigset_t and sem_t, but they could erroneously be instantiated by Modula-3 and I'd like to remove that ability to mess up so easily. (* This type is not declared correctly. It is only instantiated in C code. *) sigset_t = RECORD END; (* This type is not declared correctly. It is only instantiated in C code. *) sem_t = RECORD END; In C I believe you can do this, like: typedef struct foo foo_t; extern foo_t foo; void UseFoo(foo_t*); foo_t* GetFoo(void); Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Jan 11 17:02:18 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 11 Jan 2009 08:02:18 -0800 Subject: [M3devel] Juno (X) networking problem on AMD64_FREEBSD In-Reply-To: Your message of "Sun, 11 Jan 2009 12:57:13 GMT." Message-ID: <200901111602.n0BG2IUG047813@camembert.async.caltech.edu> This is a screwy thing in Modula-3. A bug I would call it. I've noticed a lot of networking M3 programs don't work right unless the return value of Unix's "hostname" maps to a real IP address via gethostbyname. I accomplish it in practice by adding my hostname to /etc/hosts. This is obviously not the right way to fix it... Mika Jay writes: >--_9e67232c-a064-417d-879e-227a77e310f9_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Hi. Unix network programming question.. >AMD64_FREEBSD: >$DISPLAY is set to point back to Cygwin host.It works for PPC_LINUX. >[jay at fbsdamd64a /cm3/bin]$ ./Juno >****** runtime error:*** Exception "IPError.FatalError" not in RAISES li= >st*** file "../src/common/IPError.m3"=2C line 27*** >Abort trap: 6 (core dumped)[jay at fbsdamd64a /cm3/bin]$ >IP.m3: >=20 >PROCEDURE GetHostAddr(): Address =3D VAR hname: ARRAY [0..255] OF CHAR=3B = > BEGIN LOCK mu DO IF Unix.gethostname(ADR(hname[0])=2C BYTESIZE(hna= >me)) # 0 THEN IPError.Die ()=3B END=3B VAR h :=3D Unetdb.g= >ethostbyname(ADR(hname[0]))=3B BEGIN IF h =3D NIL THEN IPError.Die()= >=3B END=3B RETURN GetAddress(h)=3B END=3B END=3B END GetHos= >tAddr=3B >PROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Address =3D VAR ua= >: Uin.struct_in_addr=3B BEGIN <* ASSERT ent.h_length <=3D BYTESIZE(Addr= >ess) *> ua :=3D LOOPHOLE(ent.h_addr_list=2C UNTRACED = >REF UNTRACED REF Uin.struct_in_addr)^^=3B RETURN LOOPHOLE(ua.s_addr=2C A= >ddress)=3B END GetAddress=3B >=20 >gethostbyname is failing. >=20 >Analogous C code also fails: >=20 >[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c#include #include #i= >nclude #include typedef struct hostent hostent_t=3B >=20 >int main(){ char hostname[200]=3B hostent_t* h=3B int i=3B > i =3D gethostname(hostname=2C 200)=3B assert(i =3D=3D 0)=3B printf("hostna= >me: %s\n"=2C hostname)=3B h =3D gethostbyname(hostname)=3B herror("foo")=3B= > printf("%p %d %d\n"=2C h=2C errno=2C h_errno)=3B assert(h)=3B return 0=3B} >=20 >herror says "unknown host". >Stack is: > at ../src/runtime/ex_frame/RTExFrame.m3:58#13 0x0000000801a7f2b3 in RTH= >ooks__Raise (M3_AJWxb1_ex=3DError accessing memory address 0x8000ffffd278: = >Bad address.) at ../src/runtime/common/RTHooks.m3:79#14 0x000000080169c8= >d3 in IPError__Die () at ../src/common/IPError.m3:27#15 0x0000000801698a3e = >in IP__GetHostAddr (M3_BCxjPn__result=3DError accessing memory address 0x80= >00ffffd338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x00000008012133d0= > in XSharedMem__SameHost (M3_AQuuui_trsl=3DError accessing memory address 0= >x8000ffffd4d8: Bad address.) at ../src/xvbt/XSharedMem.m3:96#17 0x000000= >0801212ab7 in XSharedMem__InitXClient (M3_AQuuui_v=3DError accessing memory= > address 0x8000ffffd648: Bad address.) at ../src/xvbt/XSharedMem.m3:29#1= >8 0x0000000801211819 in XExtensions__InitXClient (M3_AQuuui_xclient=3DError= > accessing memory address 0x8000ffffd7f8: Bad address.) at ../src/xvbt/X= >Extensions.m3:14#19 0x00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst= >=3D0x1879b=2C M3_AQuuui_trsl=3D0x6) at ../src/xvbt/XClientF.m3:583---Typ= >e to continue=2C or q to quit---(More stack frames follow= >...)(gdb) >(* return TRUE if server and client are on same host *)PROCEDURE SameHost (= >trsl: XClient.T): BOOLEAN =3D VAR display :=3D DisplayH= >ost(trsl)=3B displayAddr: IP.Address=3B BEGIN IF display =3D NIL THE= >N RETURN TRUE=3B END=3B > TRY IF NOT IP.GetHostByName(display=2C displayAddr) THEN RETURN FA= >LSE=3B END=3B RETURN displayAddr =3D IP.GetHostAddr()=3B EXCEPT = >| IP.Error =3D> RETURN FALSE=3B END=3B END SameHost=3B >=20 >Thoughts? >=20 >Perhaps my network isn't setup well=2C like I should add the local machine = >to /etc/hosts.I think this can be made to fail gracefully though.It seems l= >ike it has nothing to do with AMD64_FREEBSD=2C but could have to do with Fr= >eeBSD. >=20 >Seems like SocketPosix has nearly the exact same code but appearsmore forgi= >ving.. IOError instead of Fatal? >=20 >SocketPosix.m3: >=20 >PROCEDURE GetHostAddr (): Address RAISES {OSError.E} =3D VAR host : AR= >RAY [0..255] OF CHAR=3B info : Unetdb.struct_hostent_star=3B ua : U= >in.struct_in_addr=3B BEGIN IF Unix.gethostname (ADR (host[0])=2C BYTESI= >ZE (host)) # 0 THEN IOError (Unexpected)=3B END=3B > info :=3D Unetdb.gethostbyname (ADR (host[0]))=3B IF info =3D NIL TH= >EN IOError (Unexpected)=3B END=3B <* ASSERT info.h_length <=3D BYTESIZE = >(Address) *> > ua :=3D LOOPHOLE(info.h_addr_list=2C UNTRACED REF UNT= >RACED REF Uin.struct_in_addr)^^=3B RETURN LOOPHOLE (ua.s_addr=2C Address= >)=3B END GetHostAddr=3B >=20 >=20 >It is again disappointing to see such code duplication. >=20 >=20 >I guess SameHost can duplicate the logic to predict the error state and ret= >urn false upon error? >Duplicating the logic for a third time. :( >=20 > - Jay= > >--_9e67232c-a064-417d-879e-227a77e310f9_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Hi. Unix network programming question..
>
AMD64_FREEBSD:
>
$DISPLAY is set to point back to Cygwin host.
It works for PPC_LINUX= >.
>
[jay at fbsdamd64a /cm3/bin]$ ./Juno
>
***
*** runtime error:
*** =3B =3B =3B Exception "IPE= >rror.FatalError" not in RAISES list
*** =3B =3B =3B file "..= >/src/common/IPError.m3"=2C line 27
***
>
Abort trap: 6 (core dumped)
[jay at fbsdamd64a /cm3/bin]$
>
IP.m3:
> =3B
>PROCEDURE GetHostAddr(): Address =3D
 =3B VAR hname: ARRAY [0..255] = OF CHAR=3B
 =3B BEGIN
 =3B =3B =3B LOCK mu DO
&nbs= >p=3B =3B =3B =3B =3B IF Unix.gethostname(ADR(hname[0])=2C B= >YTESIZE(hname)) # 0 THEN
 =3B =3B =3B =3B =3B = >=3B =3B IPError.Die ()=3B
 =3B =3B =3B =3B =3B E= >ND=3B
 =3B =3B =3B =3B =3B VAR h :=3D Unetdb.gethost= >byname(ADR(hname[0]))=3B BEGIN
 =3B =3B =3B =3B =3B&= >nbsp=3B =3B IF h =3D NIL THEN IPError.Die()=3B END=3B
 =3B = >=3B =3B =3B =3B =3B =3B RETURN GetAddress(h)=3B
&nbs= >p=3B =3B =3B =3B =3B END=3B
 =3B =3B =3B END= >=3B
 =3B END GetHostAddr=3B
>
PROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Address =3D
= > =3B VAR ua: Uin.struct_in_addr=3B
 =3B BEGIN
 =3B = >=3B =3B <=3B* ASSERT ent.h_length <=3B=3D BYTESIZE(Address) *>=3B= >
 =3B =3B =3B ua :=3D LOOPHOLE(ent.h_addr_list=2C
 = >=3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= > =3B =3B =3B =3B =3B =3B =3B =3B =3B UN= >TRACED REF UNTRACED REF Uin.struct_in_addr)^^=3B
 =3B =3B = >=3B RETURN LOOPHOLE(ua.s_addr=2C Address)=3B
 =3B END GetAddress=3B<= >BR> > =3B
>gethostbyname is failing.
>
 =3B
>Analogous C code also fails:
> =3B
>
[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c
#include <=3Bassert.h>=3BR>#include <=3Bnetdb.h>=3B
#include <=3Bstdio.h>=3B
#include = ><=3Berrno.h>=3B
typedef struct hostent hostent_t=3B
> =3B
>int main()
{
 =3Bchar hostname[200]=3B
 =3Bhostent_t* h=3B= >
 =3Bint i=3B
> =3Bi =3D gethostname(hostname=2C 200)=3B
 =3Bassert(i =3D=3D 0)= >=3B
 =3Bprintf("hostname: %s\n"=2C hostname)=3B
 =3Bh =3D get= >hostbyname(hostname)=3B
 =3Bherror("foo")=3B
 =3Bprintf("%p %= >d %d\n"=2C h=2C errno=2C h_errno)=3B
 =3Bassert(h)=3B
 =3Bret= >urn 0=3B
}
> =3B
>herror says "unknown host".
>
Stack is:
> =3B =3B =3B at ../src/runtime/ex_frame/RTExFrame.m3:58
#13 = >0x0000000801a7f2b3 in RTHooks__Raise (M3_AJWxb1_ex=3DError accessing memory= > ad
dress 0x8000ffffd278: Bad address.
)
 =3B =3B =3B = >at ../src/runtime/common/RTHooks.m3:79
#14 0x000000080169c8d3 in IPError= >__Die () at ../src/common/IPError.m3:27
#15 0x0000000801698a3e in IP__Ge= >tHostAddr (M3_BCxjPn__result=3DError accessing mem
ory address 0x8000fff= >fd338: Bad address.
)
 =3B =3B =3B at ../src/POSIX/IP.m3:= >82
#16 0x00000008012133d0 in XSharedMem__SameHost (M3_AQuuui_trsl=3DErro= >r accessing m
emory address 0x8000ffffd4d8: Bad address.
)
 = >=3B =3B =3B at ../src/xvbt/XSharedMem.m3:96
#17 0x0000000801212a= >b7 in XSharedMem__InitXClient (M3_AQuuui_v=3DError accessing m
emory add= >ress 0x8000ffffd648: Bad address.
)
 =3B =3B =3B at ../sr= >c/xvbt/XSharedMem.m3:29
#18 0x0000000801211819 in XExtensions__InitXClie= >nt (M3_AQuuui_xclient=3DError acce
ssing memory address 0x8000ffffd7f8: = >Bad address.
)
 =3B =3B =3B at ../src/xvbt/XExtensions.m3= >:14
#19 0x00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst=3D0x1879= >b=2C
 =3B =3B =3B M3_AQuuui_trsl=3D0x6) at ../src/xvbt/XClie= >ntF.m3:583
---Type <=3Breturn>=3B to continue=2C or q <=3Breturn&g= >t=3B to quit---
(More stack frames follow...)
(gdb)
>
(* return TRUE if server and client are on same host *)
PROCEDURE Sa= >meHost (trsl: XClient.T): BOOLEAN =3D
 =3B VAR
 =3B =3B&n= >bsp=3B display =3B =3B =3B =3B =3B =3B =3B = >=3B =3B =3B =3B =3B =3B =3B =3B =3B :=3D Di= >splayHost(trsl)=3B
 =3B =3B =3B displayAddr: IP.Address=3BR> =3B BEGIN
 =3B =3B =3B IF display =3D NIL THEN RETURN= > TRUE=3B END=3B
> =3B =3B =3B TRY
 =3B =3B =3B =3B =3B IF= > NOT IP.GetHostByName(display=2C displayAddr) THEN RETURN FALSE=3B END=3BR> =3B =3B =3B =3B =3B RETURN displayAddr =3D IP.GetHos= >tAddr()=3B
 =3B =3B =3B EXCEPT
 =3B =3B =3B |= > IP.Error =3D>=3B RETURN FALSE=3B
 =3B =3B =3B END=3B
&= >nbsp=3B END SameHost=3B
> =3B
>Thoughts?
> =3B
>
Perhaps my network isn't setup well=2C like I should add the local mach= >ine to /etc/hosts.
I think this can be made to fail gracefully though.R>It seems like it has nothing to do with AMD64_FREEBSD=2C but could have t= >o do with FreeBSD.
>
 =3B
>Seems like SocketPosix has nearly the exact same code but appears
more f= >orgiving.. IOError instead of Fatal?
> =3B
>
SocketPosix.m3:
> =3B
>
PROCEDURE GetHostAddr (): Address
 =3B RAISES {OSError.E} =3D> =3B VAR
 =3B =3B =3B host : ARRAY [0..255] OF CHAR=3B<= >BR> =3B =3B =3B info : Unetdb.struct_hostent_star=3B
 = >=3B =3B =3B ua =3B =3B : Uin.struct_in_addr=3B
 =3B = >BEGIN
 =3B =3B =3B IF Unix.gethostname (ADR (host[0])=2C BYT= >ESIZE (host)) # 0 THEN
 =3B =3B =3B =3B =3B IOError = >(Unexpected)=3B
 =3B =3B =3B END=3B
> =3B =3B =3B info :=3D Unetdb.gethostbyname (ADR (host[0]))=3B<= >BR> =3B =3B =3B IF info =3D NIL THEN IOError (Unexpected)=3B EN= >D=3B
 =3B =3B =3B <=3B* ASSERT info.h_length <=3B=3D BYT= >ESIZE (Address) *>=3B
> =3B =3B =3B ua :=3D LOOPHOLE(info.h_addr_list=2C
 =3B&n= >bsp=3B =3B =3B =3B =3B =3B =3B =3B =3B = >=3B =3B =3B =3B =3B =3B =3B =3B UNTRACED REF UN= >TRACED REF Uin.struct_in_addr)^^=3B
 =3B =3B =3B RETURN LOOP= >HOLE (ua.s_addr=2C Address)=3B
 =3B END GetHostAddr=3B
> =3B
> =3B
>It is again disappointing to see such code duplication.
> =3B
> =3B
>I guess =3BSameHost can duplicate the logic to predict the error state = >and return false =3Bupon error?
>Duplicating the logic for a third time. :(
> =3B
>
 =3B- Jay

>= > >--_9e67232c-a064-417d-879e-227a77e310f9_-- From jay.krell at cornell.edu Sun Jan 11 23:02:18 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Jan 2009 22:02:18 +0000 Subject: [M3devel] Juno (X) networking problem on AMD64_FREEBSD In-Reply-To: <200901111602.n0BG2IUG047813@camembert.async.caltech.edu> References: Your message of "Sun, 11 Jan 2009 12:57:13 GMT." <200901111602.n0BG2IUG047813@camembert.async.caltech.edu> Message-ID: Do you know the right way? PPC_LINUX "just worked", and I can check Solaris and Darwin. I don't want to edit /etc/hosts -- I use DHCP. Though DHCP has been bothering me -- only for some of my machines do names resolve, so I end using IP addresses, which change sometimes, and I loop over them running ssh to all of them and "see what I get", not ideal. - Jay> To: jay.krell at cornell.edu> Date: Sun, 11 Jan 2009 08:02:18 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Juno (X) networking problem on AMD64_FREEBSD> > This is a screwy thing in Modula-3. A bug I would call it.> > I've noticed a lot of networking M3 programs don't work right unless> the return value of Unix's "hostname" maps to a real IP address via> gethostbyname. I accomplish it in practice by adding my hostname> to /etc/hosts.> > This is obviously not the right way to fix it... > > Mika> > Jay writes:> >--_9e67232c-a064-417d-879e-227a77e310f9_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >Hi. Unix network programming question..> >AMD64_FREEBSD:> >$DISPLAY is set to point back to Cygwin host.It works for PPC_LINUX.> >[jay at fbsdamd64a /cm3/bin]$ ./Juno> >****** runtime error:*** Exception "IPError.FatalError" not in RAISES li=> >st*** file "../src/common/IPError.m3"=2C line 27***> >Abort trap: 6 (core dumped)[jay at fbsdamd64a /cm3/bin]$> >IP.m3:> >=20> >PROCEDURE GetHostAddr(): Address =3D VAR hname: ARRAY [0..255] OF CHAR=3B => > BEGIN LOCK mu DO IF Unix.gethostname(ADR(hname[0])=2C BYTESIZE(hna=> >me)) # 0 THEN IPError.Die ()=3B END=3B VAR h :=3D Unetdb.g=> >ethostbyname(ADR(hname[0]))=3B BEGIN IF h =3D NIL THEN IPError.Die()=> >=3B END=3B RETURN GetAddress(h)=3B END=3B END=3B END GetHos=> >tAddr=3B> >PROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Address =3D VAR ua=> >: Uin.struct_in_addr=3B BEGIN <* ASSERT ent.h_length <=3D BYTESIZE(Addr=> >ess) *> ua :=3D LOOPHOLE(ent.h_addr_list=2C UNTRACED => >REF UNTRACED REF Uin.struct_in_addr)^^=3B RETURN LOOPHOLE(ua.s_addr=2C A=> >ddress)=3B END GetAddress=3B> >=20> >gethostbyname is failing.> >=20> >Analogous C code also fails:> >=20> >[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c#include #include #i=> >nclude #include typedef struct hostent hostent_t=3B> >=20> >int main(){ char hostname[200]=3B hostent_t* h=3B int i=3B> > i =3D gethostname(hostname=2C 200)=3B assert(i =3D=3D 0)=3B printf("hostna=> >me: %s\n"=2C hostname)=3B h =3D gethostbyname(hostname)=3B herror("foo")=3B=> > printf("%p %d %d\n"=2C h=2C errno=2C h_errno)=3B assert(h)=3B return 0=3B}> >=20> >herror says "unknown host".> >Stack is:> > at ../src/runtime/ex_frame/RTExFrame.m3:58#13 0x0000000801a7f2b3 in RTH=> >ooks__Raise (M3_AJWxb1_ex=3DError accessing memory address 0x8000ffffd278: => >Bad address.) at ../src/runtime/common/RTHooks.m3:79#14 0x000000080169c8=> >d3 in IPError__Die () at ../src/common/IPError.m3:27#15 0x0000000801698a3e => >in IP__GetHostAddr (M3_BCxjPn__result=3DError accessing memory address 0x80=> >00ffffd338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x00000008012133d0=> > in XSharedMem__SameHost (M3_AQuuui_trsl=3DError accessing memory address 0=> >x8000ffffd4d8: Bad address.) at ../src/xvbt/XSharedMem.m3:96#17 0x000000=> >0801212ab7 in XSharedMem__InitXClient (M3_AQuuui_v=3DError accessing memory=> > address 0x8000ffffd648: Bad address.) at ../src/xvbt/XSharedMem.m3:29#1=> >8 0x0000000801211819 in XExtensions__InitXClient (M3_AQuuui_xclient=3DError=> > accessing memory address 0x8000ffffd7f8: Bad address.) at ../src/xvbt/X=> >Extensions.m3:14#19 0x00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst=> >=3D0x1879b=2C M3_AQuuui_trsl=3D0x6) at ../src/xvbt/XClientF.m3:583---Typ=> >e to continue=2C or q to quit---(More stack frames follow=> >...)(gdb)> >(* return TRUE if server and client are on same host *)PROCEDURE SameHost (=> >trsl: XClient.T): BOOLEAN =3D VAR display :=3D DisplayH=> >ost(trsl)=3B displayAddr: IP.Address=3B BEGIN IF display =3D NIL THE=> >N RETURN TRUE=3B END=3B> > TRY IF NOT IP.GetHostByName(display=2C displayAddr) THEN RETURN FA=> >LSE=3B END=3B RETURN displayAddr =3D IP.GetHostAddr()=3B EXCEPT => >| IP.Error =3D> RETURN FALSE=3B END=3B END SameHost=3B> >=20> >Thoughts?> >=20> >Perhaps my network isn't setup well=2C like I should add the local machine => >to /etc/hosts.I think this can be made to fail gracefully though.It seems l=> >ike it has nothing to do with AMD64_FREEBSD=2C but could have to do with Fr=> >eeBSD.> >=20> >Seems like SocketPosix has nearly the exact same code but appearsmore forgi=> >ving.. IOError instead of Fatal?> >=20> >SocketPosix.m3:> >=20> >PROCEDURE GetHostAddr (): Address RAISES {OSError.E} =3D VAR host : AR=> >RAY [0..255] OF CHAR=3B info : Unetdb.struct_hostent_star=3B ua : U=> >in.struct_in_addr=3B BEGIN IF Unix.gethostname (ADR (host[0])=2C BYTESI=> >ZE (host)) # 0 THEN IOError (Unexpected)=3B END=3B> > info :=3D Unetdb.gethostbyname (ADR (host[0]))=3B IF info =3D NIL TH=> >EN IOError (Unexpected)=3B END=3B <* ASSERT info.h_length <=3D BYTESIZE => >(Address) *>> > ua :=3D LOOPHOLE(info.h_addr_list=2C UNTRACED REF UNT=> >RACED REF Uin.struct_in_addr)^^=3B RETURN LOOPHOLE (ua.s_addr=2C Address=> >)=3B END GetHostAddr=3B> >=20> >=20> >It is again disappointing to see such code duplication.> >=20> >=20> >I guess SameHost can duplicate the logic to predict the error state and ret=> >urn false upon error?> >Duplicating the logic for a third time. :(> >=20> > - Jay=> >> >--_9e67232c-a064-417d-879e-227a77e310f9_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >> >Hi. Unix network programming question..
> >
AMD64_FREEBSD:
> >
$DISPLAY is set to point back to Cygwin host.
It works for PPC_LINUX=> >.
> >
[jay at fbsdamd64a /cm3/bin]$ ./Juno
> >
***
*** runtime error:
*** =3B =3B =3B Exception "IPE=> >rror.FatalError" not in RAISES list
*** =3B =3B =3B file "..=> >/src/common/IPError.m3"=2C line 27
***
> >
Abort trap: 6 (core dumped)
[jay at fbsdamd64a /cm3/bin]$
> >
IP.m3:
> > =3B
> >PROCEDURE GetHostAddr(): Address =3D
 =3B VAR hname: ARRAY [0..255] => OF CHAR=3B
 =3B BEGIN
 =3B =3B =3B LOCK mu DO
&nbs=> >p=3B =3B =3B =3B =3B IF Unix.gethostname(ADR(hname[0])=2C B=> >YTESIZE(hname)) # 0 THEN
 =3B =3B =3B =3B =3B => >=3B =3B IPError.Die ()=3B
 =3B =3B =3B =3B =3B E=> >ND=3B
 =3B =3B =3B =3B =3B VAR h :=3D Unetdb.gethost=> >byname(ADR(hname[0]))=3B BEGIN
 =3B =3B =3B =3B =3B&=> >nbsp=3B =3B IF h =3D NIL THEN IPError.Die()=3B END=3B
 =3B => >=3B =3B =3B =3B =3B =3B RETURN GetAddress(h)=3B
&nbs=> >p=3B =3B =3B =3B =3B END=3B
 =3B =3B =3B END=> >=3B
 =3B END GetHostAddr=3B
> >
PROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Address =3D
=> > =3B VAR ua: Uin.struct_in_addr=3B
 =3B BEGIN
 =3B => >=3B =3B <=3B* ASSERT ent.h_length <=3B=3D BYTESIZE(Address) *>=3B=> >
 =3B =3B =3B ua :=3D LOOPHOLE(ent.h_addr_list=2C
 => >=3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=> > =3B =3B =3B =3B =3B =3B =3B =3B =3B UN=> >TRACED REF UNTRACED REF Uin.struct_in_addr)^^=3B
 =3B =3B => >=3B RETURN LOOPHOLE(ua.s_addr=2C Address)=3B
 =3B END GetAddress=3B<=> >BR>> > =3B
> >gethostbyname is failing.
> >
 =3B
> >Analogous C code also fails:
> > =3B
> >
[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c
#include <=3Bassert.h>=3B >R>#include <=3Bnetdb.h>=3B
#include <=3Bstdio.h>=3B
#include => ><=3Berrno.h>=3B
typedef struct hostent hostent_t=3B
> > =3B
> >int main()
{
 =3Bchar hostname[200]=3B
 =3Bhostent_t* h=3B=> >
 =3Bint i=3B
> > =3Bi =3D gethostname(hostname=2C 200)=3B
 =3Bassert(i =3D=3D 0)=> >=3B
 =3Bprintf("hostname: %s\n"=2C hostname)=3B
 =3Bh =3D get=> >hostbyname(hostname)=3B
 =3Bherror("foo")=3B
 =3Bprintf("%p %=> >d %d\n"=2C h=2C errno=2C h_errno)=3B
 =3Bassert(h)=3B
 =3Bret=> >urn 0=3B
}
> > =3B
> >herror says "unknown host".
> >
Stack is:
> > =3B =3B =3B at ../src/runtime/ex_frame/RTExFrame.m3:58
#13 => >0x0000000801a7f2b3 in RTHooks__Raise (M3_AJWxb1_ex=3DError accessing memory=> > ad
dress 0x8000ffffd278: Bad address.
)
 =3B =3B =3B => >at ../src/runtime/common/RTHooks.m3:79
#14 0x000000080169c8d3 in IPError=> >__Die () at ../src/common/IPError.m3:27
#15 0x0000000801698a3e in IP__Ge=> >tHostAddr (M3_BCxjPn__result=3DError accessing mem
ory address 0x8000fff=> >fd338: Bad address.
)
 =3B =3B =3B at ../src/POSIX/IP.m3:=> >82
#16 0x00000008012133d0 in XSharedMem__SameHost (M3_AQuuui_trsl=3DErro=> >r accessing m
emory address 0x8000ffffd4d8: Bad address.
)
 => >=3B =3B =3B at ../src/xvbt/XSharedMem.m3:96
#17 0x0000000801212a=> >b7 in XSharedMem__InitXClient (M3_AQuuui_v=3DError accessing m
emory add=> >ress 0x8000ffffd648: Bad address.
)
 =3B =3B =3B at ../sr=> >c/xvbt/XSharedMem.m3:29
#18 0x0000000801211819 in XExtensions__InitXClie=> >nt (M3_AQuuui_xclient=3DError acce
ssing memory address 0x8000ffffd7f8: => >Bad address.
)
 =3B =3B =3B at ../src/xvbt/XExtensions.m3=> >:14
#19 0x00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst=3D0x1879=> >b=2C
 =3B =3B =3B M3_AQuuui_trsl=3D0x6) at ../src/xvbt/XClie=> >ntF.m3:583
---Type <=3Breturn>=3B to continue=2C or q <=3Breturn&g=> >t=3B to quit---
(More stack frames follow...)
(gdb)
> >
(* return TRUE if server and client are on same host *)
PROCEDURE Sa=> >meHost (trsl: XClient.T): BOOLEAN =3D
 =3B VAR
 =3B =3B&n=> >bsp=3B display =3B =3B =3B =3B =3B =3B =3B => >=3B =3B =3B =3B =3B =3B =3B =3B =3B :=3D Di=> >splayHost(trsl)=3B
 =3B =3B =3B displayAddr: IP.Address=3B >R> =3B BEGIN
 =3B =3B =3B IF display =3D NIL THEN RETURN=> > TRUE=3B END=3B
> > =3B =3B =3B TRY
 =3B =3B =3B =3B =3B IF=> > NOT IP.GetHostByName(display=2C displayAddr) THEN RETURN FALSE=3B END=3B >R> =3B =3B =3B =3B =3B RETURN displayAddr =3D IP.GetHos=> >tAddr()=3B
 =3B =3B =3B EXCEPT
 =3B =3B =3B |=> > IP.Error =3D>=3B RETURN FALSE=3B
 =3B =3B =3B END=3B
&=> >nbsp=3B END SameHost=3B
> > =3B
> >Thoughts?
> > =3B
> >
Perhaps my network isn't setup well=2C like I should add the local mach=> >ine to /etc/hosts.
I think this can be made to fail gracefully though. >R>It seems like it has nothing to do with AMD64_FREEBSD=2C but could have t=> >o do with FreeBSD.
> >
 =3B
> >Seems like SocketPosix has nearly the exact same code but appears
more f=> >orgiving.. IOError instead of Fatal?
> > =3B
> >
SocketPosix.m3:
> > =3B
> >
PROCEDURE GetHostAddr (): Address
 =3B RAISES {OSError.E} =3D >> =3B VAR
 =3B =3B =3B host : ARRAY [0..255] OF CHAR=3B<=> >BR> =3B =3B =3B info : Unetdb.struct_hostent_star=3B
 => >=3B =3B =3B ua =3B =3B : Uin.struct_in_addr=3B
 =3B => >BEGIN
 =3B =3B =3B IF Unix.gethostname (ADR (host[0])=2C BYT=> >ESIZE (host)) # 0 THEN
 =3B =3B =3B =3B =3B IOError => >(Unexpected)=3B
 =3B =3B =3B END=3B
> > =3B =3B =3B info :=3D Unetdb.gethostbyname (ADR (host[0]))=3B<=> >BR> =3B =3B =3B IF info =3D NIL THEN IOError (Unexpected)=3B EN=> >D=3B
 =3B =3B =3B <=3B* ASSERT info.h_length <=3B=3D BYT=> >ESIZE (Address) *>=3B
> > =3B =3B =3B ua :=3D LOOPHOLE(info.h_addr_list=2C
 =3B&n=> >bsp=3B =3B =3B =3B =3B =3B =3B =3B =3B => >=3B =3B =3B =3B =3B =3B =3B =3B UNTRACED REF UN=> >TRACED REF Uin.struct_in_addr)^^=3B
 =3B =3B =3B RETURN LOOP=> >HOLE (ua.s_addr=2C Address)=3B
 =3B END GetHostAddr=3B
> > =3B
> > =3B
> >It is again disappointing to see such code duplication.
> > =3B
> > =3B
> >I guess =3BSameHost can duplicate the logic to predict the error state => >and return false =3Bupon error?
> >Duplicating the logic for a third time. :(
> > =3B
> >
 =3B- Jay

> >=> >> >--_9e67232c-a064-417d-879e-227a77e310f9_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 11 23:28:08 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Jan 2009 22:28:08 +0000 Subject: [M3devel] registers and garbage collector? Message-ID: Is this a safe assumption? PROCEDURE ProcessOther (act: Activation; p: PROCEDURE (start, stop: ADDRESS)) =... IF RTMachine.GetState # NIL THEN (* process explicit state *) sp := RTMachine.GetState(act.handle, state); ELSE (* assume registers are saved in suspended thread's stack *) sp := act.sp; END; As I understand..insert question marks a bunch here: The threads are all sitting waiting in their signal handler, with a ucontext pointer...which could be in a register and not on the stack..which contains a pointer to the registers...which could be to a thread local..and not on the stack..and not in the Modula-3 heap..would be a simple matter to strengthen this..be sure to store the ucontext in a thread local (no, actually)..or somehow be sure to get it on the stack (might as well skip the ucontext and use the gregs or whatever is in it)? Storing the ucontext in a thread local doesn't work, because you can't access thread locals that aren't yours. Instead a global array would likely be needed, that the signal handlers would all store into. I'd suggest, like, storing the ucontext/gregs into a local, or maybe a volatile local in C, maybe a struct/record, but I don't think there's any guaranteeing these aren't registers, I think a global array would be the way. I guess the assumption is fairly safe, but I'm not 100% sure. No, I'm not suspecting any problem here. I was just remembering that I'd seen platform specific stuff for some platforms (Darwin) that I'd managed to avoid, somehow, and went and looked closer, see if I was legitimately avoiding it. Most platforms do avoid it. ?? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 00:22:39 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Jan 2009 23:22:39 +0000 Subject: [M3devel] AMD64_FREEBSD available Message-ID: AMD64_FREEBSD is available now at: http://modula3.elegosoft.com/cm3/uploaded-archives built native, from a clean source checkout, on the recently released 7.1 (which might not be compatible with 6.x). You'll want to maybe update cm3cfg.common from current source to remove the use of the "ROOT" variable, which isn't always defined. The system builds itself and Juno comes up (remoted to Cygwin/X). Also new LINUXLIBC6 there (they are also built regularly by the Tinderbox). SPARC32_LINUX maybe later today (the "boot" archive that is there I think is broken, but current source tree is much better, related to struct dirent). - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 00:27:34 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Jan 2009 23:27:34 +0000 Subject: [M3devel] AMD64_FREEBSD available Message-ID: (oops, I think that was on a beta or RC, I need to reinstall..should be ok though) From: jay.krell at cornell.eduTo: m3devel at elegosoft.comSubject: AMD64_FREEBSD availableDate: Sun, 11 Jan 2009 23:22:39 +0000 AMD64_FREEBSD is available now at: http://modula3.elegosoft.com/cm3/uploaded-archives built native, from a clean source checkout, on the recently released 7.1 (which might not be compatible with 6.x). You'll want to maybe update cm3cfg.common from current source to remove the use of the "ROOT" variable, which isn't always defined. The system builds itself and Juno comes up (remoted to Cygwin/X). Also new LINUXLIBC6 there (they are also built regularly by the Tinderbox).SPARC32_LINUX maybe later today (the "boot" archive that is there I think is broken, but current source tree is much better, related to struct dirent). - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 01:01:16 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 11:01:16 +1100 Subject: [M3devel] making Uerror "portable"? In-Reply-To: References: Message-ID: <3D81B7DE-436C-4893-9129-EAA4E0551534@cs.purdue.edu> CONST is faster than VAR since the compiler can optimize them. Why would you want VAR? On 11 Jan 2009, at 19:58, Jay wrote: > I still find pushing the system dependencies and cloned headers out > of the system very tempting. > To reduce what it takes to port to other systems, to raise the > confidence of the correctness of any port, to keep ports correct in > the face of possible underlying change. > > I think I'll change the case statements to if/else ladders and the > consts to vars, that are actually statically initialized in C. This > treatment is reasonable for other constants that remain in the > cloned headers, system dependent or otherwise. > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: making Uerror "portable"? > Date: Thu, 8 Jan 2009 06:36:44 +0000 > > I've been thinking about "fixing" Uerror > to remove the system-dependentness of it. > > > I have about given up. > > > There are multiple easy options, but they > all have downsides that make me think it > might not be worth it. > > > today it looks like: > > > INTERFACE Uerror; > CONST > ENOFILE = 1; > ENOMEM = 2; > END Uerror; > > > The values are intended the correct native values. > There are a fair number of users. > Fewer than 10 probably. > They include switch/case statements, which require > constants. > > > The following are some of the possible changes, > that make porting to basically any future system > be a no-op in this area, except for the occasional missing or possibly > equal errnos (if there is a switch in the C code; I ran into this > case). > > > - Change to VAR and initialize them in portable C code. > disadvantages: > more startup code > possibly startup code runs too late > more writable/written data (readonly data is best) > slower to access > not constant, not switchable, not source quite compatible > You have to change the switch statements to "if ladders" (if/ > elseif/elseif/elseif). > Compatible with most source, and incompatible source easily > fixed. > possible issues around "dynamic linking data" (not explained > here, ask?) > However not really a problem. More of a problem only on NT, and > easily worked > around just like is done for hand.obj. > > > - change to VAR and const static initialize them in portable C "data" > no additional startup code -- guaranteed initialized early enough > no writable/written data > slower to access > not constant, not switchable, not source compatible (same as > previous) > same non-issue around dynamic linking of data > > > - change to functions GetENOFILE(), GetENOMEM(), etc. > slower to access > definitely no problem dynamic linking > easier to write the C code/data, no matter, the above > are easy enough > not constant, not switchable, not source compatible (similar to > previous) > > > - "translation"; introduce our own arbitrary values for > any errno the system uses; change Cerrno.GetErrno to have > a switch and translate from the native values to ours. > > > This is fully source compatible, dynamic link compatible, > in-between perf wise (slower to GetErrnor, but then constant > and just as comparable/switchable), no initialization cost. > > > Question then though what does any raised exception look like? > Do the values get translated back? Or translated to strings? > SetErrno translates back? > > > Translation is at first simple and is unique among portable > solutions > in its source compatibility, but I am leary of it. I would > rather a solution that traffics in unmodified native errnos > values, but > I don't that is viable with both constness and portability. > > > To a large extent, translation is ok. If you look at > SocketPosix.i3, it > uses the errno very briefly to determine the next step to take. > I don't think > it ever returns or RAISEs it (or an exception containing it). > > But other parts of the system Fmt.Int(errno) and raise that, thus > these become values that move through more of the system and > therefore > disagreement with the underlying system might show through. > > > There is also question of how to chose "Max". Set it large, like > 200? > Set it "correctly"? Probably a better option is to make the cache > that is currently Max-sized be instead small and fixed-size (e.g. > 64), > and "search" it quickly instead of "indexing" it very quickly, and > always > kick out the least recently used. I also have to check what the > contents actually are, perhaps they are constant-initializable. > > > Thoughts? > > > I was somewhat keen to do something here, but have pretty much > given up and > will just generate Uerror.i3 for Solaris, NetBSD, FreeBSD, AIX, > Irix, HP-UX, etc.. > I might still be able to remove the Usignal and Ustat system- > dependentness > in m3core/src/unix, but Uerror will probably stand asis (in linux- > common, > openbsd-common, cygwin). > > > In particular, I was putting off any more ports till I got the > amount of work needed > to port reduced to my satisfaction. I think I'm nearly there. > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 01:03:33 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 11:03:33 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> Message-ID: <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> Jay, Can you remind me again why Cygwin was unable to use pthreads? It seems you have introduced a bunch of hair into the PTHREADS implementation to deal with broken Cygwin pthreads. As many of us have already pointed out, Cygwin should be a port that tries as much as possible to be like a standard POSIX platform (pthread-based) as opposed to a weird Windows/POSIX hybrid. I have a bunch of code that will be going into the PTHREADS base that I am now at a loss to integrate with the changes you have made. Help! -- Tony From hosking at cs.purdue.edu Mon Jan 12 01:12:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 11:12:36 +1100 Subject: [M3devel] ThreadPThread (PTHREAD) In-Reply-To: <20090111233442.57DE510D5FB1@birch.elegosoft.com> References: <20090111233442.57DE510D5FB1@birch.elegosoft.com> Message-ID: <23468C51-9108-4131-9B12-6BDA68AA648E@cs.purdue.edu> Jay, can you give me a sense of what the purpose of your recent changes to the pthread-based threading code are intended to achieve? I haven't been able to follow too closely all the changes you are making, and I would like some sort of high-level rationale to help me understand. Also, if sysutils has thread-dependent stuff in it then I suggest sysutils should be rewritten to call the thread code rather than re-implement. m3core is a library that is always linked, so sysutils could easily depend on it. What's the problem? From hosking at cs.purdue.edu Mon Jan 12 01:13:00 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 11:13:00 +1100 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: References: Message-ID: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> What's wrong with using ADDRESS for references to opaque values? If sigset_t is never instantiated in Modula-3, then why do you need it declared there? 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 01:44, Jay wrote: > Is there a way in Modula-3 to declare that a type exists, and there > are <*external*> instances of it, without "fully" declaring it, so > that no Modula-3 can instantiate it? > > I have done this for sigset_t and sem_t, but they could erroneously > be instantiated by Modula-3 and I'd like to remove that ability to > mess up so easily. > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sigset_t = RECORD END; > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sem_t = RECORD END; > > In C I believe you can do this, like: > typedef struct foo foo_t; > extern foo_t foo; > > void UseFoo(foo_t*); > foo_t* GetFoo(void); > > Thanks, > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 01:55:16 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 00:55:16 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> Message-ID: I considered ADDRESS. However I think it still doesn't satisfy. I want to be able to do this: TYPE Foo_t = something; <* EXTERNAL *> VAR Foo1, Foo2:Foo_t; <* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); (* Modula-3, not external *) PROCEDURE x()= BEGIN UseFoo(Foo1); UseFoo(Foo2); END x; AND I want any use of: VAR Foo3:Foo3_t; (* Modula-3, not external *) to error. This is sem_t and sigset_t in particular. Possibly renaming is the thing. They used to be declared in Modula-3, system-dependently, but I moved them to portable C. I could remove the types entirely and change UseFoo to take an address, and declare mask and ackSem to be integers or I guess. <*EXTERNAL> VAR ackSem : RECORD END; That would satisfy but I thought it might be nicer to still provide the named types to refer to the external variables. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?What's wrong with using ADDRESS for references to opaque values? If sigset_t is never instantiated in Modula-3, then why do you need it declared there? 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 01:44, Jay wrote: Is there a way in Modula-3 to declare that a type exists, and there are <*external*> instances of it, without "fully" declaring it, so that no Modula-3 can instantiate it? I have done this for sigset_t and sem_t, but they could erroneously be instantiated by Modula-3 and I'd like to remove that ability to mess up so easily. (* This type is not declared correctly. It is only instantiated in C code. *) sigset_t = RECORD END;(* This type is not declared correctly. It is only instantiated in C code. *) sem_t = RECORD END;In C I believe you can do this, like: typedef struct foo foo_t; extern foo_t foo; void UseFoo(foo_t*); foo_t* GetFoo(void); Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 01:13:10 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 11:13:10 +1100 Subject: [M3devel] registers and garbage collector? In-Reply-To: References: Message-ID: <60C81864-8A4F-4A5F-B4FC-434FAB9F8919@cs.purdue.edu> Yes, this is safe. Some platforms require that we account for the red- zone, but generally the registers have been saved on the stack in the signal handler frame. I do not want to go the global array route that you suggest -- no need and very slow! On 12 Jan 2009, at 09:28, Jay wrote: > Is this a safe assumption? > > > PROCEDURE ProcessOther (act: Activation; p: PROCEDURE (start, stop: > ADDRESS)) = > ... > IF RTMachine.GetState # NIL THEN > (* process explicit state *) > sp := RTMachine.GetState(act.handle, state); > ELSE > (* assume registers are saved in suspended thread's stack *) > sp := act.sp; > END; > > > As I understand..insert question marks a bunch here: > > > The threads are all sitting waiting in their signal handler, with a > ucontext pointer...which could be in a register and not on the > stack..which contains a pointer to the registers...which could be to > a thread local..and not on the stack..and not in the Modula-3 > heap..would be a simple matter to strengthen this..be sure to store > the ucontext in a thread local (no, actually)..or somehow be sure to > get it on the stack (might as well skip the ucontext and use the > gregs or whatever is in it)? > Storing the ucontext in a thread local doesn't work, because you > can't access thread locals that aren't yours. Instead a global array > would likely be needed, that the signal handlers would all store > into. I'd suggest, like, storing the ucontext/gregs into a local, or > maybe a volatile local in C, maybe a struct/record, but I don't > think there's any guaranteeing these aren't registers, I think a > global array would be the way. > I guess the assumption is fairly safe, but I'm not 100% sure. > No, I'm not suspecting any problem here. I was just remembering that > I'd seen platform specific stuff for some platforms (Darwin) that > I'd managed to avoid, somehow, and went and looked closer, see if I > was legitimately avoiding it. Most platforms do avoid it. > > ?? > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 02:04:12 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 01:04:12 +0000 Subject: [M3devel] ThreadPThread (PTHREAD) In-Reply-To: <23468C51-9108-4131-9B12-6BDA68AA648E@cs.purdue.edu> References: <20090111233442.57DE510D5FB1@birch.elegosoft.com> <23468C51-9108-4131-9B12-6BDA68AA648E@cs.purdue.edu> Message-ID: Yes I can explain mostly. I was not able to get Cygwin/pthreads to work. I don't know why. I could try another round of debugging. It was a while ago, like a year ago. I did debug it on some depth, rebuilding cygwin1.dll, and such. I was inclined to give up. Consensus at the time was people didn't really care. As long as they had forward slashes (which are abstracted from code, but not from the user..and slow fork..), and Modula-3 abstracted threads, no matter how the Modula-3 threads were impelented. So Cygwin uses Win32 threads. More recently..well, it bothered me slightly that the "wait" code was duplicated, but that's very little code. In looking at it though, I realized that Cygwin didn't have a proper SchedulerPosix, which I think is an abstraction of select(). What I did is move the SchedulerPosix code out of ThreadPThread. This way it can be reused against ThreadPThread or ThreadWin32. It is a fairly mechanical change, with no real semantic change. I realize that movement of code from one file to another is hard to track though using simple text methods. The stuff around "WaitPidYields" is what got me looking here and has some value, but I think giving Cygwin a proper SchedulerPosix is more valuable. WaitPidYields is contorted because sysutils bootstraps against old m3core, and I strongly suspect that sysutils exposes essentially a different variant of m3core's abstractions, and cannot be implemented on top of it. That m3core hides too much for sysutils. If we bump up the minimum m3core that we build from, the contortions can go away. "contortions" == "quake generating Modula-3 code, with different names per client". Make sense? - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:12:36 +1100> CC: m3devel at elegosoft.com> Subject: [M3devel] ThreadPThread (PTHREAD)> > Jay, can you give me a sense of what the purpose of your recent > changes to the pthread-based threading code are intended to achieve? > I haven't been able to follow too closely all the changes you are > making, and I would like some sort of high-level rationale to help me > understand. Also, if sysutils has thread-dependent stuff in it then I > suggest sysutils should be rewritten to call the thread code rather > than re-implement. m3core is a library that is always linked, so > sysutils could easily depend on it. What's the problem?> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 02:09:52 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 01:09:52 +0000 Subject: [M3devel] making Uerror "portable"? In-Reply-To: <118F7713-A9E8-441C-90EF-8D255C386078@cs.purdue.edu> References: <118F7713-A9E8-441C-90EF-8D255C386078@cs.purdue.edu> Message-ID: Understood. So I can remove Uerror's system-dependentness. in place of CONST EFOO =1, EBAR = 2; I want: <*EXTERNAL*> (*const*) VAR EFOO, EBAR:int; UerrorC.c: #include enum { eEFOO = EFOO, eEBAR = EBAR }; const Max = sizeof(union { char a[EFOO]; char b[EBAR]; }); #undef EFOO #undef EBAR const EFOO = eEFOO; const EBAR = eEBAR; Very much like that. ok? I was probably going to do this tonight for cygwin/openbsd/amd64. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] making Uerror "portable"?Date: Mon, 12 Jan 2009 11:13:16 +1100 CONST is faster than VAR since the compiler can optimize them. Why would you want VAR? On 11 Jan 2009, at 19:58, Jay wrote: I still find pushing the system dependencies and cloned headers out of the system very tempting. To reduce what it takes to port to other systems, to raise the confidence of the correctness of any port, to keep ports correct in the face of possible underlying change. I think I'll change the case statements to if/else ladders and the consts to vars, that are actually statically initialized in C. This treatment is reasonable for other constants that remain in the cloned headers, system dependent or otherwise. - Jay From: jay.krell at cornell.eduTo: m3devel at elegosoft.comSubject: making Uerror "portable"?Date: Thu, 8 Jan 2009 06:36:44 +0000I've been thinking about "fixing" Uerrorto remove the system-dependentness of it. I have about given up. There are multiple easy options, but theyall have downsides that make me think itmight not be worth it. today it looks like: INTERFACE Uerror;CONST ENOFILE = 1; ENOMEM = 2;END Uerror; The values are intended the correct native values.There are a fair number of users.Fewer than 10 probably.They include switch/case statements, which requireconstants. The following are some of the possible changes,that make porting to basically any future systembe a no-op in this area, except for the occasional missing or possiblyequal errnos (if there is a switch in the C code; I ran into this case). - Change to VAR and initialize them in portable C code. disadvantages: more startup code possibly startup code runs too late more writable/written data (readonly data is best) slower to access not constant, not switchable, not source quite compatible You have to change the switch statements to "if ladders" (if/elseif/elseif/elseif). Compatible with most source, and incompatible source easily fixed. possible issues around "dynamic linking data" (not explained here, ask?) However not really a problem. More of a problem only on NT, and easily worked around just like is done for hand.obj. - change to VAR and const static initialize them in portable C "data" no additional startup code -- guaranteed initialized early enough no writable/written data slower to access not constant, not switchable, not source compatible (same as previous) same non-issue around dynamic linking of data - change to functions GetENOFILE(), GetENOMEM(), etc. slower to access definitely no problem dynamic linking easier to write the C code/data, no matter, the above are easy enough not constant, not switchable, not source compatible (similar to previous) - "translation"; introduce our own arbitrary values for any errno the system uses; change Cerrno.GetErrno to have a switch and translate from the native values to ours. This is fully source compatible, dynamic link compatible, in-between perf wise (slower to GetErrnor, but then constant and just as comparable/switchable), no initialization cost. Question then though what does any raised exception look like? Do the values get translated back? Or translated to strings? SetErrno translates back? Translation is at first simple and is unique among portable solutions in its source compatibility, but I am leary of it. I would rather a solution that traffics in unmodified native errnos values, but I don't that is viable with both constness and portability. To a large extent, translation is ok. If you look at SocketPosix.i3, it uses the errno very briefly to determine the next step to take. I don't think it ever returns or RAISEs it (or an exception containing it). But other parts of the system Fmt.Int(errno) and raise that, thus these become values that move through more of the system and therefore disagreement with the underlying system might show through. There is also question of how to chose "Max". Set it large, like 200? Set it "correctly"? Probably a better option is to make the cache that is currently Max-sized be instead small and fixed-size (e.g. 64), and "search" it quickly instead of "indexing" it very quickly, and always kick out the least recently used. I also have to check what the contents actually are, perhaps they are constant-initializable. Thoughts? I was somewhat keen to do something here, but have pretty much given up and will just generate Uerror.i3 for Solaris, NetBSD, FreeBSD, AIX, Irix, HP-UX, etc.. I might still be able to remove the Usignal and Ustat system-dependentness in m3core/src/unix, but Uerror will probably stand asis (in linux-common, openbsd-common, cygwin). In particular, I was putting off any more ports till I got the amount of work neededto port reduced to my satisfaction. I think I'm nearly there. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 02:19:35 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 01:19:35 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> Message-ID: btw, I don't think it's that hairy, I merely split it into two or three files, and added interfaces so they can reuse code with each other. Movement between files is hard to track though (depending on version control, but with all I've used). The SchedulerPosix implementation moved to ThreadPScheduler.m3. What is shared between it and ThreadPThread/Win32.m3 is ThreadInternal.i3, which maybe should be in ThreadF.i3, though that's exposed outside m3core, and ThreadInternal.i3 includes a variable. I can try again to debug Cygwin pthreads though. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:03:33 +1100> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Jay,> > Can you remind me again why Cygwin was unable to use pthreads? It > seems you have introduced a bunch of hair into the PTHREADS > implementation to deal with broken Cygwin pthreads. As many of us > have already pointed out, Cygwin should be a port that tries as much > as possible to be like a standard POSIX platform (pthread-based) as > opposed to a weird Windows/POSIX hybrid.> > I have a bunch of code that will be going into the PTHREADS base that > I am now at a loss to integrate with the changes you have made.> > Help!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 02:35:32 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 12:35:32 +1100 Subject: [M3devel] making Uerror "portable"? In-Reply-To: References: <118F7713-A9E8-441C-90EF-8D255C386078@cs.purdue.edu> Message-ID: On 12 Jan 2009, at 12:09, Jay wrote: > Understood. > So I can remove Uerror's system-dependentness. > > > in place of > CONST EFOO =1, EBAR = 2; > > I want: > > <*EXTERNAL*> (*const*) VAR EFOO, EBAR:int; This is gross. Again, if they are constants in C they should be constants in Modula-3. To reiterate: I think your contortions to eliminate C-header-file cloning are distorting the Modula-3 code in ways that make it much less transparent. Can we please revert some of these bad design decisions? > UerrorC.c: > #include > enum { eEFOO = EFOO, eEBAR = EBAR }; > const Max = sizeof(union { char a[EFOO]; char b[EBAR]; }); > #undef EFOO > #undef EBAR > const EFOO = eEFOO; > const EBAR = eEBAR; > > Very much like that. > ok? I was probably going to do this tonight for cygwin/openbsd/amd64. > > - Jay > > > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] making Uerror "portable"? > Date: Mon, 12 Jan 2009 11:13:16 +1100 > > > CONST is faster than VAR since the compiler can optimize them. Why > would you want VAR? > > On 11 Jan 2009, at 19:58, Jay wrote: > > I still find pushing the system dependencies and cloned headers out > of the system very tempting. > To reduce what it takes to port to other systems, to raise the > confidence of the correctness of any port, to keep ports correct in > the face of possible underlying change. > > I think I'll change the case statements to if/else ladders and the > consts to vars, that are actually statically initialized in C. This > treatment is reasonable for other constants that remain in the > cloned headers, system dependent or otherwise. > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: making Uerror "portable"? > Date: Thu, 8 Jan 2009 06:36:44 +0000 > > I've been thinking about "fixing" Uerror > to remove the system-dependentness of it. > > > I have about given up. > > > There are multiple easy options, but they > all have downsides that make me think it > might not be worth it. > > > today it looks like: > > > INTERFACE Uerror; > CONST > ENOFILE = 1; > ENOMEM = 2; > END Uerror; > > > The values are intended the correct native values. > There are a fair number of users. > Fewer than 10 probably. > They include switch/case statements, which require > constants. > > > The following are some of the possible changes, > that make porting to basically any future system > be a no-op in this area, except for the occasional missing or possibly > equal errnos (if there is a switch in the C code; I ran into this > case). > > > - Change to VAR and initialize them in portable C code. > disadvantages: > more startup code > possibly startup code runs too late > more writable/written data (readonly data is best) > slower to access > not constant, not switchable, not source quite compatible > You have to change the switch statements to "if ladders" (if/ > elseif/elseif/elseif). > Compatible with most source, and incompatible source easily > fixed. > possible issues around "dynamic linking data" (not explained > here, ask?) > However not really a problem. More of a problem only on NT, and > easily worked > around just like is done for hand.obj. > > > - change to VAR and const static initialize them in portable C "data" > no additional startup code -- guaranteed initialized early enough > no writable/written data > slower to access > not constant, not switchable, not source compatible (same as > previous) > same non-issue around dynamic linking of data > > > - change to functions GetENOFILE(), GetENOMEM(), etc. > slower to access > definitely no problem dynamic linking > easier to write the C code/data, no matter, the above > are easy enough > not constant, not switchable, not source compatible (similar to > previous) > > > - "translation"; introduce our own arbitrary values for > any errno the system uses; change Cerrno.GetErrno to have > a switch and translate from the native values to ours. > > > This is fully source compatible, dynamic link compatible, > in-between perf wise (slower to GetErrnor, but then constant > and just as comparable/switchable), no initialization cost. > > > Question then though what does any raised exception look like? > Do the values get translated back? Or translated to strings? > SetErrno translates back? > > > Translation is at first simple and is unique among portable > solutions > in its source compatibility, but I am leary of it. I would > rather a solution that traffics in unmodified native errnos > values, but > I don't that is viable with both constness and portability. > > > To a large extent, translation is ok. If you look at > SocketPosix.i3, it > uses the errno very briefly to determine the next step to take. > I don't think > it ever returns or RAISEs it (or an exception containing it). > > But other parts of the system Fmt.Int(errno) and raise that, thus > these become values that move through more of the system and > therefore > disagreement with the underlying system might show through. > > > There is also question of how to chose "Max". Set it large, like > 200? > Set it "correctly"? Probably a better option is to make the cache > that is currently Max-sized be instead small and fixed-size (e.g. > 64), > and "search" it quickly instead of "indexing" it very quickly, and > always > kick out the least recently used. I also have to check what the > contents actually are, perhaps they are constant-initializable. > > > Thoughts? > > > I was somewhat keen to do something here, but have pretty much > given up and > will just generate Uerror.i3 for Solaris, NetBSD, FreeBSD, AIX, > Irix, HP-UX, etc.. > I might still be able to remove the Usignal and Ustat system- > dependentness > in m3core/src/unix, but Uerror will probably stand asis (in linux- > common, > openbsd-common, cygwin). > > > In particular, I was putting off any more ports till I got the > amount of work needed > to port reduced to my satisfaction. I think I'm nearly there. > > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 02:32:15 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 12:32:15 +1100 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> Message-ID: <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> Jay, I really think you are bending over backwards too far just to be able to shoe-horn things into C. I *like* having the transpar of C header files expressed in Modula-3, *particularly* for system calls, where you might even be trying to build on a system that does not have the C header files installed, even though the libraries exist and can be linked to. Fundamentally, I think anytime the Modula-3 code is made less transparent you should think hard about what you are doing. The same with the change of constants to variables. I am getting very nervous that the changes you are making are destroying the clarity of the Modula-3 run-time code. In this particular case, you are wanting to use a Modula-3 parameter passing mechanism on something that is not declared in Modula-3. Seems kind of dubious to me. Also, I really don't like the idea of accessing external variables in C. -- Tony On 12 Jan 2009, at 11:55, Jay wrote: > I considered ADDRESS. > However I think it still doesn't satisfy. > > I want to be able to do this: > > TYPE Foo_t = something; > <* EXTERNAL *> VAR Foo1, Foo2:Foo_t; > <* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); > > (* Modula-3, not external *) > PROCEDURE x()= > BEGIN > UseFoo(Foo1); > UseFoo(Foo2); > END x; > > AND I want any use of: > VAR Foo3:Foo3_t; (* Modula-3, not external *) > > to error. This is sem_t and sigset_t in particular. > > Possibly renaming is the thing. > They used to be declared in Modula-3, system-dependently, but > I moved them to portable C. > > I could remove the types entirely and change UseFoo to take an > address, > and declare mask and ackSem to be integers or I guess. > <*EXTERNAL> VAR ackSem : RECORD END; > > That would satisfy but I thought it might be nicer to still provide > the named > types to refer to the external variables. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 11:13:00 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > > What's wrong with using ADDRESS for references to opaque values? If > sigset_t is never instantiated in Modula-3, then why do you need it > declared there? > > 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 01:44, Jay wrote: > > Is there a way in Modula-3 to declare that a type exists, and there > are <*external*> instances of it, without "fully" declaring it, so > that no Modula-3 can instantiate it? > > I have done this for sigset_t and sem_t, but they could erroneously > be instantiated by Modula-3 and I'd like to remove that ability to > mess up so easily. > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sigset_t = RECORD END; > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sem_t = RECORD END; > > In C I believe you can do this, like: > typedef struct foo foo_t; > extern foo_t foo; > > void UseFoo(foo_t*); > foo_t* GetFoo(void); > > Thanks, > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 02:42:39 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 12:42:39 +1100 Subject: [M3devel] ThreadPThread (PTHREAD) In-Reply-To: References: <20090111233442.57DE510D5FB1@birch.elegosoft.com> <23468C51-9108-4131-9B12-6BDA68AA648E@cs.purdue.edu> Message-ID: <45DAF3DE-F1E6-47C5-A113-BD94776197F9@cs.purdue.edu> On 12 Jan 2009, at 12:04, Jay wrote: > Yes I can explain mostly. > > > I was not able to get Cygwin/pthreads to work. > I don't know why. I could try another round of debugging. > It was a while ago, like a year ago. > I did debug it on some depth, rebuilding cygwin1.dll, and such. > I was inclined to give up. But now you are distorting the whole threads subsystem to work around a bug. Sounds screwy to me. > Consensus at the time was people didn't really care. > As long as they had forward slashes (which are abstracted > from code, but not from the user..and slow fork..), > and Modula-3 abstracted threads, > no matter how the Modula-3 threads were impelented. I care if the threads system becomes a tangled mess. > So Cygwin uses Win32 threads. Fine insofar as the implementation is hidden. But then you go on and try to impose POSIX thread semantics (for waitpid and friends) [as far as I understand things] onto a Win32 threads implementation. Weird. > More recently..well, it bothered me slightly that the "wait" code was > duplicated, but that's very little code. In looking at it though, I > realized > that Cygwin didn't have a proper SchedulerPosix, which I think is > an abstraction of select(). > > > What I did is move the SchedulerPosix code out of ThreadPThread. > This way it can be reused against ThreadPThread or ThreadWin32. Does this even make sense? > It is a fairly mechanical change, with no real semantic change. > I realize that movement of code from one file to another is hard to > track though > using simple text methods. > > > The stuff around "WaitPidYields" is what got me looking here and > has some value, but I think giving Cygwin a proper SchedulerPosix > is more valuable. I don't know what this comment refers to. Can you give a high-level overview? > WaitPidYields is contorted because sysutils bootstraps against old > m3core, > and I strongly suspect that sysutils exposes essentially a different > variant of m3core's abstractions, and cannot be implemented on top > of it. > That m3core hides too much for sysutils. sysutils is a *hack* that needs to be fixed so as not to expose m3core abstractions. It is only used in a very few places, and we would be much better situated if we figured out what functionality is needed by clients of sysutils rather than breaking m3core to let sysutils in on things. > If we bump up the minimum m3core that we build from, the contortions > can go away. "contortions" == "quake generating Modula-3 code, > with different names per client". What do you propose? What is the "minimum m3core"? What do we need to add to it? > > > > Make sense? > > - Jay > > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:12:36 +1100 > > CC: m3devel at elegosoft.com > > Subject: [M3devel] ThreadPThread (PTHREAD) > > > > Jay, can you give me a sense of what the purpose of your recent > > changes to the pthread-based threading code are intended to achieve? > > I haven't been able to follow too closely all the changes you are > > making, and I would like some sort of high-level rationale to help > me > > understand. Also, if sysutils has thread-dependent stuff in it > then I > > suggest sysutils should be rewritten to call the thread code rather > > than re-implement. m3core is a library that is always linked, so > > sysutils could easily depend on it. What's the problem? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 02:46:54 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 12:46:54 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> Message-ID: <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> You are smearing implementation details across multiple files and directories. Up until now, ThreadPThread has been nicely self- contained, and captured all the basic pieces of the thread implementation. Also, how does all of this fit with the ThreadPosix implementation? On 12 Jan 2009, at 12:19, Jay wrote: > btw, I don't think it's that hairy, I merely split it into two or > three files, and added interfaces so they can reuse code with each > other. Movement between files is hard to track though (depending on > version control, but with all I've used). > > The SchedulerPosix implementation moved to ThreadPScheduler.m3. > What is shared between it and ThreadPThread/Win32.m3 is > ThreadInternal.i3, which maybe should be in ThreadF.i3, though > that's exposed outside m3core, and ThreadInternal.i3 includes a > variable. > > I can try again to debug Cygwin pthreads though. > > - Jay > > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:03:33 +1100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay, > > > > Can you remind me again why Cygwin was unable to use pthreads? It > > seems you have introduced a bunch of hair into the PTHREADS > > implementation to deal with broken Cygwin pthreads. As many of us > > have already pointed out, Cygwin should be a port that tries as much > > as possible to be like a standard POSIX platform (pthread-based) as > > opposed to a weird Windows/POSIX hybrid. > > > > I have a bunch of code that will be going into the PTHREADS base > that > > I am now at a loss to integrate with the changes you have made. > > > > Help! > > > > -- Tony > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 01:13:16 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 11:13:16 +1100 Subject: [M3devel] making Uerror "portable"? In-Reply-To: References: Message-ID: <118F7713-A9E8-441C-90EF-8D255C386078@cs.purdue.edu> CONST is faster than VAR since the compiler can optimize them. Why would you want VAR? On 11 Jan 2009, at 19:58, Jay wrote: > I still find pushing the system dependencies and cloned headers out > of the system very tempting. > To reduce what it takes to port to other systems, to raise the > confidence of the correctness of any port, to keep ports correct in > the face of possible underlying change. > > I think I'll change the case statements to if/else ladders and the > consts to vars, that are actually statically initialized in C. This > treatment is reasonable for other constants that remain in the > cloned headers, system dependent or otherwise. > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: making Uerror "portable"? > Date: Thu, 8 Jan 2009 06:36:44 +0000 > > I've been thinking about "fixing" Uerror > to remove the system-dependentness of it. > > > I have about given up. > > > There are multiple easy options, but they > all have downsides that make me think it > might not be worth it. > > > today it looks like: > > > INTERFACE Uerror; > CONST > ENOFILE = 1; > ENOMEM = 2; > END Uerror; > > > The values are intended the correct native values. > There are a fair number of users. > Fewer than 10 probably. > They include switch/case statements, which require > constants. > > > The following are some of the possible changes, > that make porting to basically any future system > be a no-op in this area, except for the occasional missing or possibly > equal errnos (if there is a switch in the C code; I ran into this > case). > > > - Change to VAR and initialize them in portable C code. > disadvantages: > more startup code > possibly startup code runs too late > more writable/written data (readonly data is best) > slower to access > not constant, not switchable, not source quite compatible > You have to change the switch statements to "if ladders" (if/ > elseif/elseif/elseif). > Compatible with most source, and incompatible source easily > fixed. > possible issues around "dynamic linking data" (not explained > here, ask?) > However not really a problem. More of a problem only on NT, and > easily worked > around just like is done for hand.obj. > > > - change to VAR and const static initialize them in portable C "data" > no additional startup code -- guaranteed initialized early enough > no writable/written data > slower to access > not constant, not switchable, not source compatible (same as > previous) > same non-issue around dynamic linking of data > > > - change to functions GetENOFILE(), GetENOMEM(), etc. > slower to access > definitely no problem dynamic linking > easier to write the C code/data, no matter, the above > are easy enough > not constant, not switchable, not source compatible (similar to > previous) > > > - "translation"; introduce our own arbitrary values for > any errno the system uses; change Cerrno.GetErrno to have > a switch and translate from the native values to ours. > > > This is fully source compatible, dynamic link compatible, > in-between perf wise (slower to GetErrnor, but then constant > and just as comparable/switchable), no initialization cost. > > > Question then though what does any raised exception look like? > Do the values get translated back? Or translated to strings? > SetErrno translates back? > > > Translation is at first simple and is unique among portable > solutions > in its source compatibility, but I am leary of it. I would > rather a solution that traffics in unmodified native errnos > values, but > I don't that is viable with both constness and portability. > > > To a large extent, translation is ok. If you look at > SocketPosix.i3, it > uses the errno very briefly to determine the next step to take. > I don't think > it ever returns or RAISEs it (or an exception containing it). > > But other parts of the system Fmt.Int(errno) and raise that, thus > these become values that move through more of the system and > therefore > disagreement with the underlying system might show through. > > > There is also question of how to chose "Max". Set it large, like > 200? > Set it "correctly"? Probably a better option is to make the cache > that is currently Max-sized be instead small and fixed-size (e.g. > 64), > and "search" it quickly instead of "indexing" it very quickly, and > always > kick out the least recently used. I also have to check what the > contents actually are, perhaps they are constant-initializable. > > > Thoughts? > > > I was somewhat keen to do something here, but have pretty much > given up and > will just generate Uerror.i3 for Solaris, NetBSD, FreeBSD, AIX, > Irix, HP-UX, etc.. > I might still be able to remove the Usignal and Ustat system- > dependentness > in m3core/src/unix, but Uerror will probably stand asis (in linux- > common, > openbsd-common, cygwin). > > > In particular, I was putting off any more ports till I got the > amount of work needed > to port reduced to my satisfaction. I think I'm nearly there. > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: [M3devel] [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 hosking at cs.purdue.edu Mon Jan 12 05:27:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 15:27:07 +1100 Subject: [M3devel] waitpid contortions Message-ID: <055997B8-7083-4DF6-A373-D2BF3E4351BC@cs.purdue.edu> Jay, To avoid your contortions surrounding usage of waitpid in sysutils, I propose the following. Implement ThreadPosix.WaitProcess as a thing wrapper over waitpid: PROCEDURE WaitProcess (pid: int; VAR status: int): int = (* ThreadPThread.m3 and ThreadPosix.m3 are very similar. *) BEGIN LOOP WITH r = Uexec.waitpid(pid, ADR(status), 0) DO <*ASSERT r # 0*> IF r > 0 THEN RETURN r END; IF Cerrno.GetErrno() # Uerror.EINTR THEN RETURN r END; END; END; END WaitProcess; Implement Process.Wait as it used to be originally, calling SchedulerPosix.WaitProcess instead of waitpid. Implement SystemPosix.Wait using SchedulerPosix.Wait to throw exceptions as defined in the original code. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 05:46:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 15:46:34 +1100 Subject: [M3devel] waitpid Message-ID: Does anyone know why the SchedulerPosix.Wait code (which originally came from ProcessPosix.m3 and is similar in SystemPosix.m3) was doing strange unpacking of the status word returned from waitpid? It seems to be unnecessary when waitpid is typed as: int waitpid (pid_t pid, int *status, int options) From jay.krell at cornell.edu Mon Jan 12 07:39:26 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 06:39:26 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: ThreadPosix is basically unaffected -- I never provided user threads on Cygwin. I guess it got a slight reduction regarding DoesWaitPidYield, but its SchedulerPosix implementation was unchanged. The code in ThreadPosix is similar to but different than ThreadPThread. It is possible they could be merged but it wasn't trivial so I left ThreadPosix alone. > You are smearing implementation details across multiple files and directories You really think it is bad to have SchedulerPosix implemented in a small separate file? On top of what happens to be common implementation details of ThreadPThread.m3 and ThreadWin32.m3? ThreadPScheduler.m3 is just basically three functions: IOWait, IOAlertWait, XIOWait Plus the little internal utility, UTimeFromTime, the one liner DoesWaitPidYield, and non-trivial functions nested in XIOWait: TestFDS, CallSelect. I mean, you know, an alternative is to copy out very large chunks of ThreadWin32.m3 and ThreadPThread.m3 and merge them into ThreadCygwin.m3. That would be worse imho. "Directories" hardly. Or I can try debugging cygwin pthreads again. - Jay CC: jkrell at elego.de; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 12:46:54 +1100You are smearing implementation details across multiple files and directories. Up until now, ThreadPThread has been nicely self-contained, and captured all the basic pieces of the thread implementation. Also, how does all of this fit with the ThreadPosix implementation? On 12 Jan 2009, at 12:19, Jay wrote: btw, I don't think it's that hairy, I merely split it into two or three files, and added interfaces so they can reuse code with each other. Movement between files is hard to track though (depending on version control, but with all I've used). The SchedulerPosix implementation moved to ThreadPScheduler.m3.What is shared between it and ThreadPThread/Win32.m3 is ThreadInternal.i3, which maybe should be in ThreadF.i3, though that's exposed outside m3core, and ThreadInternal.i3 includes a variable. I can try again to debug Cygwin pthreads though. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:03:33 +1100> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Jay,> > Can you remind me again why Cygwin was unable to use pthreads? It > seems you have introduced a bunch of hair into the PTHREADS > implementation to deal with broken Cygwin pthreads. As many of us > have already pointed out, Cygwin should be a port that tries as much > as possible to be like a standard POSIX platform (pthread-based) as > opposed to a weird Windows/POSIX hybrid.> > I have a bunch of code that will be going into the PTHREADS base that > I am now at a loss to integrate with the changes you have made.> > Help!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: [M3devel] [M3commit] 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: [M3devel] [M3commit] 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 hosking at cs.purdue.edu Mon Jan 12 07:53:02 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 17:53:02 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: Why does sysutils need to be compatible with both old and new versions of m3core? On 12 Jan 2009, at 17:39, Jay wrote: > ThreadPosix is basically unaffected -- I never provided user threads > on Cygwin. > I guess it got a slight reduction regarding DoesWaitPidYield, but > its SchedulerPosix implementation was unchanged. > > The code in ThreadPosix is similar to but different than > ThreadPThread. > It is possible they could be merged but it wasn't trivial so I left > ThreadPosix alone. > > > You are smearing implementation details across multiple files and > directories > > You really think it is bad to have SchedulerPosix implemented in a > small separate file? > On top of what happens to be common implementation details of > ThreadPThread.m3 and ThreadWin32.m3? > > ThreadPScheduler.m3 is just basically three functions: IOWait, > IOAlertWait, XIOWait > Plus the little internal utility, UTimeFromTime, the one liner > DoesWaitPidYield, and non-trivial functions nested in XIOWait: > TestFDS, CallSelect. > > I mean, you know, an alternative is to copy out very large chunks of > ThreadWin32.m3 and ThreadPThread.m3 and merge them into > ThreadCygwin.m3. That would be worse imho. > > "Directories" hardly. > > Or I can try debugging cygwin pthreads again. > > - Jay > > > CC: jkrell at elego.de; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Mon, 12 Jan 2009 12:46:54 +1100 > > You are smearing implementation details across multiple files and > directories. Up until now, ThreadPThread has been nicely self- > contained, and captured all the basic pieces of the thread > implementation. Also, how does all of this fit with the ThreadPosix > implementation? > > On 12 Jan 2009, at 12:19, Jay wrote: > > btw, I don't think it's that hairy, I merely split it into two or > three files, and added interfaces so they can reuse code with each > other. Movement between files is hard to track though (depending on > version control, but with all I've used). > > The SchedulerPosix implementation moved to ThreadPScheduler.m3. > What is shared between it and ThreadPThread/Win32.m3 is > ThreadInternal.i3, which maybe should be in ThreadF.i3, though > that's exposed outside m3core, and ThreadInternal.i3 includes a > variable. > > I can try again to debug Cygwin pthreads though. > > - Jay > > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:03:33 +1100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay, > > > > Can you remind me again why Cygwin was unable to use pthreads? It > > seems you have introduced a bunch of hair into the PTHREADS > > implementation to deal with broken Cygwin pthreads. As many of us > > have already pointed out, Cygwin should be a port that tries as much > > as possible to be like a standard POSIX platform (pthread-based) as > > opposed to a weird Windows/POSIX hybrid. > > > > I have a bunch of code that will be going into the PTHREADS base > that > > I am now at a loss to integrate with the changes you have made. > > > > Help! > > > > -- Tony > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 07:58:00 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 06:58:00 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> Message-ID: We have conflicting goals. Keeping things as fast as possible and with as little C as possible, vs. keeping things more portable, more easily ported, more obviously correct. I want to drastically reduce the header cloning, or, the work of porting. It is already reduced, but I want to keep going. I think having to make any changes at all in m3-libs/m3core/src/unix can be removed, other than adding the platform to the list of platforms that uses the "portable" stuff. Porting would devolve to: update the lists of platforms -- including some in m3makefiles update Target.m3 clone/edit Csetjmp.i3 add the GNU platform to m3cc/src/makefile and maybe nothing else. It is likely even that the IR is now portable, for "Posix" systems. Pick word size, pick endian, generate 4 versions of IR, pick the right one for your platform. Except for the OSConfigPosix that sometimes returns the platform name and cm3's defining "HOST". A variable isn't great, but it is faster and more source compatible than a function call, at least. And the C variable really will generally be read only. Writes to it should fault. > In this particular case, you are wanting to use a Modula-3 parameter > passing mechanism on something that is not declared in Modula-3. Isn't this just a variation on what is done all the time? -- having Modula-3 call C and sometimes vice versa? C code calls Modula-3 signal handlers, with data created in the C code. The Modula-3 code can then pass them on. I don't see the line really. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 12:32:15 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it? Jay, I really think you are bending over backwards too far just to be able to shoe-horn things into C. I *like* having the transpar of C header files expressed in Modula-3, *particularly* for system calls, where you might even be trying to build on a system that does not have the C header files installed, even though the libraries exist and can be linked to. Fundamentally, I think anytime the Modula-3 code is made less transparent you should think hard about what you are doing. The same with the change of constants to variables. I am getting very nervous that the changes you are making are destroying the clarity of the Modula-3 run-time code. In this particular case, you are wanting to use a Modula-3 parameter passing mechanism on something that is not declared in Modula-3. Seems kind of dubious to me. Also, I really don't like the idea of accessing external variables in C. -- Tony On 12 Jan 2009, at 11:55, Jay wrote: I considered ADDRESS.However I think it still doesn't satisfy. I want to be able to do this: TYPE Foo_t = something;<* EXTERNAL *> VAR Foo1, Foo2:Foo_t;<* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); (* Modula-3, not external *)PROCEDURE x()=BEGIN UseFoo(Foo1); UseFoo(Foo2);END x; AND I want any use of:VAR Foo3:Foo3_t; (* Modula-3, not external *)to error. This is sem_t and sigset_t in particular. Possibly renaming is the thing.They used to be declared in Modula-3, system-dependently, butI moved them to portable C. I could remove the types entirely and change UseFoo to take an address,and declare mask and ackSem to be integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END; That would satisfy but I thought it might be nicer to still provide the namedtypes to refer to the external variables. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?What's wrong with using ADDRESS for references to opaque values? If sigset_t is never instantiated in Modula-3, then why do you need it declared there? 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 01:44, Jay wrote: Is there a way in Modula-3 to declare that a type exists, and there are <*external*> instances of it, without "fully" declaring it, so that no Modula-3 can instantiate it? I have done this for sigset_t and sem_t, but they could erroneously be instantiated by Modula-3 and I'd like to remove that ability to mess up so easily. (* This type is not declared correctly. It is only instantiated in C code. *) sigset_t = RECORD END;(* This type is not declared correctly. It is only instantiated in C code. *) sem_t = RECORD END;In C I believe you can do this, like: typedef struct foo foo_t; extern foo_t foo; void UseFoo(foo_t*); foo_t* GetFoo(void); Thanks, - Jay -------------- 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: [M3devel] [M3commit] 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 jay.krell at cornell.edu Mon Jan 12 07:58:44 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 06:58:44 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: To bootstrap I believe. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 17:53:02 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3Why does sysutils need to be compatible with both old and new versions of m3core? On 12 Jan 2009, at 17:39, Jay wrote: ThreadPosix is basically unaffected -- I never provided user threads on Cygwin. I guess it got a slight reduction regarding DoesWaitPidYield, but its SchedulerPosix implementation was unchanged. The code in ThreadPosix is similar to but different than ThreadPThread.It is possible they could be merged but it wasn't trivial so I left ThreadPosix alone. > You are smearing implementation details across multiple files and directories You really think it is bad to have SchedulerPosix implemented in a small separate file?On top of what happens to be common implementation details of ThreadPThread.m3 and ThreadWin32.m3? ThreadPScheduler.m3 is just basically three functions: IOWait, IOAlertWait, XIOWaitPlus the little internal utility, UTimeFromTime, the one liner DoesWaitPidYield, and non-trivial functions nested in XIOWait: TestFDS, CallSelect. I mean, you know, an alternative is to copy out very large chunks of ThreadWin32.m3 and ThreadPThread.m3 and merge them into ThreadCygwin.m3. That would be worse imho. "Directories" hardly. Or I can try debugging cygwin pthreads again. - Jay CC: jkrell at elego.de; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 12:46:54 +1100You are smearing implementation details across multiple files and directories. Up until now, ThreadPThread has been nicely self-contained, and captured all the basic pieces of the thread implementation. Also, how does all of this fit with the ThreadPosix implementation? On 12 Jan 2009, at 12:19, Jay wrote: btw, I don't think it's that hairy, I merely split it into two or three files, and added interfaces so they can reuse code with each other. Movement between files is hard to track though (depending on version control, but with all I've used). The SchedulerPosix implementation moved to ThreadPScheduler.m3.What is shared between it and ThreadPThread/Win32.m3 is ThreadInternal.i3, which maybe should be in ThreadF.i3, though that's exposed outside m3core, and ThreadInternal.i3 includes a variable. I can try again to debug Cygwin pthreads though. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:03:33 +1100> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Jay,> > Can you remind me again why Cygwin was unable to use pthreads? It > seems you have introduced a bunch of hair into the PTHREADS > implementation to deal with broken Cygwin pthreads. As many of us > have already pointed out, Cygwin should be a port that tries as much > as possible to be like a standard POSIX platform (pthread-based) as > opposed to a weird Windows/POSIX hybrid.> > I have a bunch of code that will be going into the PTHREADS base that > I am now at a loss to integrate with the changes you have made.> > Help!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 08:04:46 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 18:04:46 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: Jay, Your changes are occurring way too fast for us to keep up with you, and some of them are distorting the code base unnecessarily. When you make these sorts of drastic reorgs it is important that the primary developers are in consensus. Right now I am most distressed by the damage that seems to have been done to m3core/src/thread -- I haven't had time to look over the other things you've been doing closely enough to know. For now, I am going to go in and change the source code head to reflect what I believe the solution for waitpid should look like. On 12 Jan 2009, at 17:53, Tony Hosking wrote: > Why does sysutils need to be compatible with both old and new > versions of m3core? > > On 12 Jan 2009, at 17:39, Jay wrote: > >> ThreadPosix is basically unaffected -- I never provided user >> threads on Cygwin. >> I guess it got a slight reduction regarding DoesWaitPidYield, but >> its SchedulerPosix implementation was unchanged. >> >> The code in ThreadPosix is similar to but different than >> ThreadPThread. >> It is possible they could be merged but it wasn't trivial so I left >> ThreadPosix alone. >> >> > You are smearing implementation details across multiple files >> and directories >> >> You really think it is bad to have SchedulerPosix implemented in a >> small separate file? >> On top of what happens to be common implementation details of >> ThreadPThread.m3 and ThreadWin32.m3? >> >> ThreadPScheduler.m3 is just basically three functions: IOWait, >> IOAlertWait, XIOWait >> Plus the little internal utility, UTimeFromTime, the one liner >> DoesWaitPidYield, and non-trivial functions nested in XIOWait: >> TestFDS, CallSelect. >> >> I mean, you know, an alternative is to copy out very large chunks >> of ThreadWin32.m3 and ThreadPThread.m3 and merge them into >> ThreadCygwin.m3. That would be worse imho. >> >> "Directories" hardly. >> >> Or I can try debugging cygwin pthreads again. >> >> - Jay >> >> >> CC: jkrell at elego.de; m3devel at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Subject: Re: [M3devel] [M3commit] CVS Update: cm3 >> Date: Mon, 12 Jan 2009 12:46:54 +1100 >> >> You are smearing implementation details across multiple files and >> directories. Up until now, ThreadPThread has been nicely self- >> contained, and captured all the basic pieces of the thread >> implementation. Also, how does all of this fit with the >> ThreadPosix implementation? >> >> On 12 Jan 2009, at 12:19, Jay wrote: >> >> btw, I don't think it's that hairy, I merely split it into two or >> three files, and added interfaces so they can reuse code with each >> other. Movement between files is hard to track though (depending on >> version control, but with all I've used). >> >> The SchedulerPosix implementation moved to ThreadPScheduler.m3. >> What is shared between it and ThreadPThread/Win32.m3 is >> ThreadInternal.i3, which maybe should be in ThreadF.i3, though >> that's exposed outside m3core, and ThreadInternal.i3 includes a >> variable. >> >> I can try again to debug Cygwin pthreads though. >> >> - Jay >> >> >> > From: hosking at cs.purdue.edu >> > To: jkrell at elego.de >> > Date: Mon, 12 Jan 2009 11:03:33 +1100 >> > CC: m3devel at elegosoft.com >> > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 >> > >> > Jay, >> > >> > Can you remind me again why Cygwin was unable to use pthreads? It >> > seems you have introduced a bunch of hair into the PTHREADS >> > implementation to deal with broken Cygwin pthreads. As many of us >> > have already pointed out, Cygwin should be a port that tries as >> much >> > as possible to be like a standard POSIX platform (pthread-based) as >> > opposed to a weird Windows/POSIX hybrid. >> > >> > I have a bunch of code that will be going into the PTHREADS base >> that >> > I am now at a loss to integrate with the changes you have made. >> > >> > Help! >> > >> > -- 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: [M3devel] [M3commit] 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: [M3devel] [M3commit] 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: [M3devel] [M3commit] 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: [M3devel] [M3commit] 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 hosking at cs.purdue.edu Mon Jan 12 08:19:55 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 18:19:55 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: Not true. sysutils should be built against the m3core with which it will be linked. I don't think this is correct. On 12 Jan 2009, at 17:58, Jay wrote: > To bootstrap I believe. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 17:53:02 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Why does sysutils need to be compatible with both old and new > versions of m3core? > > On 12 Jan 2009, at 17:39, Jay wrote: > > ThreadPosix is basically unaffected -- I never provided user threads > on Cygwin. > I guess it got a slight reduction regarding DoesWaitPidYield, but > its SchedulerPosix implementation was unchanged. > > The code in ThreadPosix is similar to but different than > ThreadPThread. > It is possible they could be merged but it wasn't trivial so I left > ThreadPosix alone. > > > You are smearing implementation details across multiple files and > directories > > You really think it is bad to have SchedulerPosix implemented in a > small separate file? > On top of what happens to be common implementation details of > ThreadPThread.m3 and ThreadWin32.m3? > > ThreadPScheduler.m3 is just basically three functions: IOWait, > IOAlertWait, XIOWait > Plus the little internal utility, UTimeFromTime, the one liner > DoesWaitPidYield, and non-trivial functions nested in XIOWait: > TestFDS, CallSelect. > > I mean, you know, an alternative is to copy out very large chunks of > ThreadWin32.m3 and ThreadPThread.m3 and merge them into > ThreadCygwin.m3. That would be worse imho. > > "Directories" hardly. > > Or I can try debugging cygwin pthreads again. > > - Jay > > > CC: jkrell at elego.de; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Mon, 12 Jan 2009 12:46:54 +1100 > > You are smearing implementation details across multiple files and > directories. Up until now, ThreadPThread has been nicely self- > contained, and captured all the basic pieces of the thread > implementation. Also, how does all of this fit with the ThreadPosix > implementation? > > On 12 Jan 2009, at 12:19, Jay wrote: > > btw, I don't think it's that hairy, I merely split it into two or > three files, and added interfaces so they can reuse code with each > other. Movement between files is hard to track though (depending on > version control, but with all I've used). > > The SchedulerPosix implementation moved to ThreadPScheduler.m3. > What is shared between it and ThreadPThread/Win32.m3 is > ThreadInternal.i3, which maybe should be in ThreadF.i3, though > that's exposed outside m3core, and ThreadInternal.i3 includes a > variable. > > I can try again to debug Cygwin pthreads though. > > - Jay > > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:03:33 +1100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay, > > > > Can you remind me again why Cygwin was unable to use pthreads? It > > seems you have introduced a bunch of hair into the PTHREADS > > implementation to deal with broken Cygwin pthreads. As many of us > > have already pointed out, Cygwin should be a port that tries as much > > as possible to be like a standard POSIX platform (pthread-based) as > > opposed to a weird Windows/POSIX hybrid. > > > > I have a bunch of code that will be going into the PTHREADS base > that > > I am now at a loss to integrate with the changes you have made. > > > > Help! > > > > -- 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: [M3devel] [M3commit] 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 hosking at cs.purdue.edu Mon Jan 12 08:24:43 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 18:24:43 +1100 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> Message-ID: Jay, What the hell is the ROOT variable supposed to do now. I can't build m3core with a compiler that doesn't define ROOT. And why does the m3makefile that includes Uwaitpid.quake expect a hardwired cm3 directory hierarchy. Surely, I should be able to build m3core as a separate package, regardless of the structure in which it appears. You are doing damage to the package structures here too, by hardwiring these paths into the m3makefile. -- Tony On 12 Jan 2009, at 17:58, Jay wrote: > We have conflicting goals. > > Keeping things as fast as possible and with as little C as possible, > vs. keeping things more portable, more easily ported, more obviously > correct. > > I want to drastically reduce the header cloning, or, the work of > porting. > It is already reduced, but I want to keep going. > I think having to make any changes at all in m3-libs/m3core/src/ > unix can be removed, other than adding the platform to the list of > platforms that uses the "portable" stuff. > Porting would devolve to: > update the lists of platforms -- including some in m3makefiles > update Target.m3 > clone/edit Csetjmp.i3 > add the GNU platform to m3cc/src/makefile > > and maybe nothing else. > > It is likely even that the IR is now portable, for "Posix" systems. > Pick word size, pick endian, generate 4 versions of IR, pick the > right one for your platform. > Except for the OSConfigPosix that sometimes returns the platform > name and cm3's defining "HOST". > > A variable isn't great, but it is faster and more source compatible > than a function call, at least. > And the C variable really will generally be read only. Writes to it > should fault. > > > In this particular case, you are wanting to use a Modula-3 > parameter > > passing mechanism on something that is not declared in Modula-3. > > Isn't this just a variation on what is done all the time? -- having > Modula-3 call C and sometimes vice versa? > C code calls Modula-3 signal handlers, with data created in the C > code. The Modula-3 code can then pass them on. I don't see the line > really. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 12:32:15 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > > > Jay, I really think you are bending over backwards too far just to > be able to shoe-horn things into C. I *like* having the transpar of > C header files expressed in Modula-3, *particularly* for system > calls, where you might even be trying to build on a system that does > not have the C header files installed, even though the libraries > exist and can be linked to. Fundamentally, I think anytime the > Modula-3 code is made less transparent you should think hard about > what you are doing. The same with the change of constants to > variables. > > I am getting very nervous that the changes you are making are > destroying the clarity of the Modula-3 run-time code. > > In this particular case, you are wanting to use a Modula-3 parameter > passing mechanism on something that is not declared in Modula-3. > Seems kind of dubious to me. Also, I really don't like the idea of > accessing external variables in C. > > -- Tony > > On 12 Jan 2009, at 11:55, Jay wrote: > > I considered ADDRESS. > However I think it still doesn't satisfy. > > I want to be able to do this: > > TYPE Foo_t = something; > <* EXTERNAL *> VAR Foo1, Foo2:Foo_t; > <* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); > > (* Modula-3, not external *) > PROCEDURE x()= > BEGIN > UseFoo(Foo1); > UseFoo(Foo2); > END x; > > AND I want any use of: > VAR Foo3:Foo3_t; (* Modula-3, not external *) > > to error. This is sem_t and sigset_t in particular. > > Possibly renaming is the thing. > They used to be declared in Modula-3, system-dependently, but > I moved them to portable C. > > I could remove the types entirely and change UseFoo to take an > address, > and declare mask and ackSem to be integers or I guess. > <*EXTERNAL> VAR ackSem : RECORD END; > > That would satisfy but I thought it might be nicer to still provide > the named > types to refer to the external variables. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 11:13:00 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > > What's wrong with using ADDRESS for references to opaque values? If > sigset_t is never instantiated in Modula-3, then why do you need it > declared there? > > 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 01:44, Jay wrote: > > Is there a way in Modula-3 to declare that a type exists, and there > are <*external*> instances of it, without "fully" declaring it, so > that no Modula-3 can instantiate it? > > I have done this for sigset_t and sem_t, but they could erroneously > be instantiated by Modula-3 and I'd like to remove that ability to > mess up so easily. > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sigset_t = RECORD END; > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sem_t = RECORD END; > > In C I believe you can do this, like: > typedef struct foo foo_t; > extern foo_t foo; > > void UseFoo(foo_t*); > foo_t* GetFoo(void); > > Thanks, > - Jay > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 08:25:03 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 07:25:03 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: The compiler uses sysutils. The first pass builds against an old package store, which might not have sysutils at all, if it is that old. Again, once new m3core is around, no problem. I could/should have put in the m3core change and just waited on the sysutils change, rather than go ahead and do the quake stuff, and we can do that now (or your change that moots it, which I haven't looked into yet). I was browsing the docs and it appears there is an "import_pkg" directive for like, copying in a package contents, instead of linking. That might also solve this. I found that relatively late and never looked into it. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:19:55 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3Not true. sysutils should be built against the m3core with which it will be linked. I don't think this is correct. On 12 Jan 2009, at 17:58, Jay wrote: To bootstrap I believe. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 17:53:02 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3Why does sysutils need to be compatible with both old and new versions of m3core? On 12 Jan 2009, at 17:39, Jay wrote: ThreadPosix is basically unaffected -- I never provided user threads on Cygwin. I guess it got a slight reduction regarding DoesWaitPidYield, but its SchedulerPosix implementation was unchanged. The code in ThreadPosix is similar to but different than ThreadPThread.It is possible they could be merged but it wasn't trivial so I left ThreadPosix alone. > You are smearing implementation details across multiple files and directories You really think it is bad to have SchedulerPosix implemented in a small separate file?On top of what happens to be common implementation details of ThreadPThread.m3 and ThreadWin32.m3? ThreadPScheduler.m3 is just basically three functions: IOWait, IOAlertWait, XIOWaitPlus the little internal utility, UTimeFromTime, the one liner DoesWaitPidYield, and non-trivial functions nested in XIOWait: TestFDS, CallSelect. I mean, you know, an alternative is to copy out very large chunks of ThreadWin32.m3 and ThreadPThread.m3 and merge them into ThreadCygwin.m3. That would be worse imho. "Directories" hardly. Or I can try debugging cygwin pthreads again. - Jay CC: jkrell at elego.de; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 12:46:54 +1100You are smearing implementation details across multiple files and directories. Up until now, ThreadPThread has been nicely self-contained, and captured all the basic pieces of the thread implementation. Also, how does all of this fit with the ThreadPosix implementation? On 12 Jan 2009, at 12:19, Jay wrote: btw, I don't think it's that hairy, I merely split it into two or three files, and added interfaces so they can reuse code with each other. Movement between files is hard to track though (depending on version control, but with all I've used). The SchedulerPosix implementation moved to ThreadPScheduler.m3.What is shared between it and ThreadPThread/Win32.m3 is ThreadInternal.i3, which maybe should be in ThreadF.i3, though that's exposed outside m3core, and ThreadInternal.i3 includes a variable. I can try again to debug Cygwin pthreads though. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:03:33 +1100> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Jay,> > Can you remind me again why Cygwin was unable to use pthreads? It > seems you have introduced a bunch of hair into the PTHREADS > implementation to deal with broken Cygwin pthreads. As many of us > have already pointed out, Cygwin should be a port that tries as much > as possible to be like a standard POSIX platform (pthread-based) as > opposed to a weird Windows/POSIX hybrid.> > I have a bunch of code that will be going into the PTHREADS base that > I am now at a loss to integrate with the changes you have made.> > Help!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 08:27:09 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 07:27:09 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> Message-ID: Huh..that's what I was saying about the way m3overrides work -- the directory structure IS duplicated /everywhere/.. I don't know what choice there is, if quake code is to be shared across packages. m3tests does the same sort of thing, also to me. Ok, hold, I'll slow sysutils back down. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:24:43 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?Jay, What the hell is the ROOT variable supposed to do now. I can't build m3core with a compiler that doesn't define ROOT. And why does the m3makefile that includes Uwaitpid.quake expect a hardwired cm3 directory hierarchy. Surely, I should be able to build m3core as a separate package, regardless of the structure in which it appears. You are doing damage to the package structures here too, by hardwiring these paths into the m3makefile. -- Tony On 12 Jan 2009, at 17:58, Jay wrote: We have conflicting goals. Keeping things as fast as possible and with as little C as possible, vs. keeping things more portable, more easily ported, more obviously correct. I want to drastically reduce the header cloning, or, the work of porting. It is already reduced, but I want to keep going. I think having to make any changes at all in m3-libs/m3core/src/unix can be removed, other than adding the platform to the list of platforms that uses the "portable" stuff.Porting would devolve to: update the lists of platforms -- including some in m3makefiles update Target.m3 clone/edit Csetjmp.i3 add the GNU platform to m3cc/src/makefile and maybe nothing else. It is likely even that the IR is now portable, for "Posix" systems.Pick word size, pick endian, generate 4 versions of IR, pick the right one for your platform.Except for the OSConfigPosix that sometimes returns the platform name and cm3's defining "HOST". A variable isn't great, but it is faster and more source compatible than a function call, at least.And the C variable really will generally be read only. Writes to it should fault. > In this particular case, you are wanting to use a Modula-3 parameter > passing mechanism on something that is not declared in Modula-3. Isn't this just a variation on what is done all the time? -- having Modula-3 call C and sometimes vice versa?C code calls Modula-3 signal handlers, with data created in the C code. The Modula-3 code can then pass them on. I don't see the line really. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 12:32:15 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it? Jay, I really think you are bending over backwards too far just to be able to shoe-horn things into C. I *like* having the transpar of C header files expressed in Modula-3, *particularly* for system calls, where you might even be trying to build on a system that does not have the C header files installed, even though the libraries exist and can be linked to. Fundamentally, I think anytime the Modula-3 code is made less transparent you should think hard about what you are doing. The same with the change of constants to variables. I am getting very nervous that the changes you are making are destroying the clarity of the Modula-3 run-time code. In this particular case, you are wanting to use a Modula-3 parameter passing mechanism on something that is not declared in Modula-3. Seems kind of dubious to me. Also, I really don't like the idea of accessing external variables in C. -- Tony On 12 Jan 2009, at 11:55, Jay wrote: I considered ADDRESS.However I think it still doesn't satisfy. I want to be able to do this: TYPE Foo_t = something;<* EXTERNAL *> VAR Foo1, Foo2:Foo_t;<* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); (* Modula-3, not external *)PROCEDURE x()=BEGIN UseFoo(Foo1); UseFoo(Foo2);END x; AND I want any use of:VAR Foo3:Foo3_t; (* Modula-3, not external *)to error. This is sem_t and sigset_t in particular. Possibly renaming is the thing.They used to be declared in Modula-3, system-dependently, butI moved them to portable C. I could remove the types entirely and change UseFoo to take an address,and declare mask and ackSem to be integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END; That would satisfy but I thought it might be nicer to still provide the namedtypes to refer to the external variables. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?What's wrong with using ADDRESS for references to opaque values? If sigset_t is never instantiated in Modula-3, then why do you need it declared there? 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 01:44, Jay wrote: Is there a way in Modula-3 to declare that a type exists, and there are <*external*> instances of it, without "fully" declaring it, so that no Modula-3 can instantiate it? I have done this for sigset_t and sem_t, but they could erroneously be instantiated by Modula-3 and I'd like to remove that ability to mess up so easily. (* This type is not declared correctly. It is only instantiated in C code. *) sigset_t = RECORD END;(* This type is not declared correctly. It is only instantiated in C code. *) sem_t = RECORD END;In C I believe you can do this, like: typedef struct foo foo_t; extern foo_t foo; void UseFoo(foo_t*); foo_t* GetFoo(void); Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 08:31:40 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 18:31:40 +1100 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> Message-ID: <079DF9EE-C4DE-4563-B21E-53EA34F364AD@cs.purdue.edu> Don't mess with sysutils. I am about to check in my code. You could help by reverting from the current quake generated copies of waitpid to a single copy. On 12 Jan 2009, at 18:27, Jay wrote: > Huh..that's what I was saying about the way m3overrides work -- the > directory structure IS duplicated /everywhere/.. I don't know what > choice there is, if quake code is to be shared across packages. > > m3tests does the same sort of thing, also to me. > > Ok, hold, I'll slow sysutils back down. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 18:24:43 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > > Jay, > > What the hell is the ROOT variable supposed to do now. I can't > build m3core with a compiler that doesn't define ROOT. And why does > the m3makefile that includes Uwaitpid.quake expect a hardwired cm3 > directory hierarchy. Surely, I should be able to build m3core as a > separate package, regardless of the structure in which it appears. > You are doing damage to the package structures here too, by > hardwiring these paths into the m3makefile. > > -- Tony > > On 12 Jan 2009, at 17:58, Jay wrote: > > We have conflicting goals. > > Keeping things as fast as possible and with as little C as possible, > vs. keeping things more portable, more easily ported, more obviously > correct. > > I want to drastically reduce the header cloning, or, the work of > porting. > It is already reduced, but I want to keep going. > I think having to make any changes at all in m3-libs/m3core/src/ > unix can be removed, other than adding the platform to the list of > platforms that uses the "portable" stuff. > Porting would devolve to: > update the lists of platforms -- including some in m3makefiles > update Target.m3 > clone/edit Csetjmp.i3 > add the GNU platform to m3cc/src/makefile > > and maybe nothing else. > > It is likely even that the IR is now portable, for "Posix" systems. > Pick word size, pick endian, generate 4 versions of IR, pick the > right one for your platform. > Except for the OSConfigPosix that sometimes returns the platform > name and cm3's defining "HOST". > > A variable isn't great, but it is faster and more source compatible > than a function call, at least. > And the C variable really will generally be read only. Writes to it > should fault. > > > In this particular case, you are wanting to use a Modula-3 > parameter > > passing mechanism on something that is not declared in Modula-3. > > Isn't this just a variation on what is done all the time? -- having > Modula-3 call C and sometimes vice versa? > C code calls Modula-3 signal handlers, with data created in the C > code. The Modula-3 code can then pass them on. I don't see the line > really. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 12:32:15 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > > > Jay, I really think you are bending over backwards too far just to > be able to shoe-horn things into C. I *like* having the transpar of > C header files expressed in Modula-3, *particularly* for system > calls, where you might even be trying to build on a system that does > not have the C header files installed, even though the libraries > exist and can be linked to. Fundamentally, I think anytime the > Modula-3 code is made less transparent you should think hard about > what you are doing. The same with the change of constants to > variables. > > I am getting very nervous that the changes you are making are > destroying the clarity of the Modula-3 run-time code. > > In this particular case, you are wanting to use a Modula-3 parameter > passing mechanism on something that is not declared in Modula-3. > Seems kind of dubious to me. Also, I really don't like the idea of > accessing external variables in C. > > -- Tony > > On 12 Jan 2009, at 11:55, Jay wrote: > > I considered ADDRESS. > However I think it still doesn't satisfy. > > I want to be able to do this: > > TYPE Foo_t = something; > <* EXTERNAL *> VAR Foo1, Foo2:Foo_t; > <* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); > > (* Modula-3, not external *) > PROCEDURE x()= > BEGIN > UseFoo(Foo1); > UseFoo(Foo2); > END x; > > AND I want any use of: > VAR Foo3:Foo3_t; (* Modula-3, not external *) > > to error. This is sem_t and sigset_t in particular. > > Possibly renaming is the thing. > They used to be declared in Modula-3, system-dependently, but > I moved them to portable C. > > I could remove the types entirely and change UseFoo to take an > address, > and declare mask and ackSem to be integers or I guess. > <*EXTERNAL> VAR ackSem : RECORD END; > > That would satisfy but I thought it might be nicer to still provide > the named > types to refer to the external variables. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 11:13:00 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > > What's wrong with using ADDRESS for references to opaque values? If > sigset_t is never instantiated in Modula-3, then why do you need it > declared there? > > 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 01:44, Jay wrote: > > Is there a way in Modula-3 to declare that a type exists, and there > are <*external*> instances of it, without "fully" declaring it, so > that no Modula-3 can instantiate it? > > I have done this for sigset_t and sem_t, but they could erroneously > be instantiated by Modula-3 and I'd like to remove that ability to > mess up so easily. > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sigset_t = RECORD END; > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sem_t = RECORD END; > > In C I believe you can do this, like: > typedef struct foo foo_t; > extern foo_t foo; > > void UseFoo(foo_t*); > foo_t* GetFoo(void); > > Thanks, > - Jay > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 08:32:13 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 07:32:13 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> Message-ID: I didn't slow it back down yet, but I changed to a relative path instead of ROOT. All the scripts define ROOT and my config files ferry environment variable CM3_ROOT to ROOT. (ROOT is too generic for an environment variable.) oh -- m3core or sysytils? sysutils needed it. I don't see what m3core does. - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] declaring a type's existance but not enough to instantiate it?Date: Mon, 12 Jan 2009 07:27:09 +0000 Huh..that's what I was saying about the way m3overrides work -- the directory structure IS duplicated /everywhere/.. I don't know what choice there is, if quake code is to be shared across packages. m3tests does the same sort of thing, also to me. Ok, hold, I'll slow sysutils back down. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:24:43 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?Jay, What the hell is the ROOT variable supposed to do now. I can't build m3core with a compiler that doesn't define ROOT. And why does the m3makefile that includes Uwaitpid.quake expect a hardwired cm3 directory hierarchy. Surely, I should be able to build m3core as a separate package, regardless of the structure in which it appears. You are doing damage to the package structures here too, by hardwiring these paths into the m3makefile. -- Tony On 12 Jan 2009, at 17:58, Jay wrote: We have conflicting goals. Keeping things as fast as possible and with as little C as possible, vs. keeping things more portable, more easily ported, more obviously correct. I want to drastically reduce the header cloning, or, the work of porting. It is already reduced, but I want to keep going. I think having to make any changes at all in m3-libs/m3core/src/unix can be removed, other than adding the platform to the list of platforms that uses the "portable" stuff.Porting would devolve to: update the lists of platforms -- including some in m3makefiles update Target.m3 clone/edit Csetjmp.i3 add the GNU platform to m3cc/src/makefile and maybe nothing else. It is likely even that the IR is now portable, for "Posix" systems.Pick word size, pick endian, generate 4 versions of IR, pick the right one for your platform.Except for the OSConfigPosix that sometimes returns the platform name and cm3's defining "HOST". A variable isn't great, but it is faster and more source compatible than a function call, at least.And the C variable really will generally be read only. Writes to it should fault. > In this particular case, you are wanting to use a Modula-3 parameter > passing mechanism on something that is not declared in Modula-3. Isn't this just a variation on what is done all the time? -- having Modula-3 call C and sometimes vice versa?C code calls Modula-3 signal handlers, with data created in the C code. The Modula-3 code can then pass them on. I don't see the line really. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 12:32:15 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it? Jay, I really think you are bending over backwards too far just to be able to shoe-horn things into C. I *like* having the transpar of C header files expressed in Modula-3, *particularly* for system calls, where you might even be trying to build on a system that does not have the C header files installed, even though the libraries exist and can be linked to. Fundamentally, I think anytime the Modula-3 code is made less transparent you should think hard about what you are doing. The same with the change of constants to variables. I am getting very nervous that the changes you are making are destroying the clarity of the Modula-3 run-time code. In this particular case, you are wanting to use a Modula-3 parameter passing mechanism on something that is not declared in Modula-3. Seems kind of dubious to me. Also, I really don't like the idea of accessing external variables in C. -- Tony On 12 Jan 2009, at 11:55, Jay wrote: I considered ADDRESS.However I think it still doesn't satisfy. I want to be able to do this: TYPE Foo_t = something;<* EXTERNAL *> VAR Foo1, Foo2:Foo_t;<* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); (* Modula-3, not external *)PROCEDURE x()=BEGIN UseFoo(Foo1); UseFoo(Foo2);END x; AND I want any use of:VAR Foo3:Foo3_t; (* Modula-3, not external *)to error. This is sem_t and sigset_t in particular. Possibly renaming is the thing.They used to be declared in Modula-3, system-dependently, butI moved them to portable C. I could remove the types entirely and change UseFoo to take an address,and declare mask and ackSem to be integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END; That would satisfy but I thought it might be nicer to still provide the namedtypes to refer to the external variables. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?What's wrong with using ADDRESS for references to opaque values? If sigset_t is never instantiated in Modula-3, then why do you need it declared there? 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 01:44, Jay wrote: Is there a way in Modula-3 to declare that a type exists, and there are <*external*> instances of it, without "fully" declaring it, so that no Modula-3 can instantiate it? I have done this for sigset_t and sem_t, but they could erroneously be instantiated by Modula-3 and I'd like to remove that ability to mess up so easily. (* This type is not declared correctly. It is only instantiated in C code. *) sigset_t = RECORD END;(* This type is not declared correctly. It is only instantiated in C code. *) sem_t = RECORD END;In C I believe you can do this, like: typedef struct foo foo_t; extern foo_t foo; void UseFoo(foo_t*); foo_t* GetFoo(void); Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 08:38:59 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 07:38:59 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> Message-ID: > sysutils needed it. I don't see what m3core does. I see. "fixing". - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] declaring a type's existance but not enough to instantiate it?Date: Mon, 12 Jan 2009 07:32:13 +0000 I didn't slow it back down yet, but I changed to a relative path instead of ROOT.All the scripts define ROOT and my config files ferry environment variable CM3_ROOT to ROOT.(ROOT is too generic for an environment variable.)oh -- m3core or sysytils?sysutils needed it. I don't see what m3core does. - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] declaring a type's existance but not enough to instantiate it?Date: Mon, 12 Jan 2009 07:27:09 +0000 Huh..that's what I was saying about the way m3overrides work -- the directory structure IS duplicated /everywhere/.. I don't know what choice there is, if quake code is to be shared across packages. m3tests does the same sort of thing, also to me. Ok, hold, I'll slow sysutils back down. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:24:43 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?Jay, What the hell is the ROOT variable supposed to do now. I can't build m3core with a compiler that doesn't define ROOT. And why does the m3makefile that includes Uwaitpid.quake expect a hardwired cm3 directory hierarchy. Surely, I should be able to build m3core as a separate package, regardless of the structure in which it appears. You are doing damage to the package structures here too, by hardwiring these paths into the m3makefile. -- Tony On 12 Jan 2009, at 17:58, Jay wrote: We have conflicting goals. Keeping things as fast as possible and with as little C as possible, vs. keeping things more portable, more easily ported, more obviously correct. I want to drastically reduce the header cloning, or, the work of porting. It is already reduced, but I want to keep going. I think having to make any changes at all in m3-libs/m3core/src/unix can be removed, other than adding the platform to the list of platforms that uses the "portable" stuff.Porting would devolve to: update the lists of platforms -- including some in m3makefiles update Target.m3 clone/edit Csetjmp.i3 add the GNU platform to m3cc/src/makefile and maybe nothing else. It is likely even that the IR is now portable, for "Posix" systems.Pick word size, pick endian, generate 4 versions of IR, pick the right one for your platform.Except for the OSConfigPosix that sometimes returns the platform name and cm3's defining "HOST". A variable isn't great, but it is faster and more source compatible than a function call, at least.And the C variable really will generally be read only. Writes to it should fault. > In this particular case, you are wanting to use a Modula-3 parameter > passing mechanism on something that is not declared in Modula-3. Isn't this just a variation on what is done all the time? -- having Modula-3 call C and sometimes vice versa?C code calls Modula-3 signal handlers, with data created in the C code. The Modula-3 code can then pass them on. I don't see the line really. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 12:32:15 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it? Jay, I really think you are bending over backwards too far just to be able to shoe-horn things into C. I *like* having the transpar of C header files expressed in Modula-3, *particularly* for system calls, where you might even be trying to build on a system that does not have the C header files installed, even though the libraries exist and can be linked to. Fundamentally, I think anytime the Modula-3 code is made less transparent you should think hard about what you are doing. The same with the change of constants to variables. I am getting very nervous that the changes you are making are destroying the clarity of the Modula-3 run-time code. In this particular case, you are wanting to use a Modula-3 parameter passing mechanism on something that is not declared in Modula-3. Seems kind of dubious to me. Also, I really don't like the idea of accessing external variables in C. -- Tony On 12 Jan 2009, at 11:55, Jay wrote: I considered ADDRESS.However I think it still doesn't satisfy. I want to be able to do this: TYPE Foo_t = something;<* EXTERNAL *> VAR Foo1, Foo2:Foo_t;<* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); (* Modula-3, not external *)PROCEDURE x()=BEGIN UseFoo(Foo1); UseFoo(Foo2);END x; AND I want any use of:VAR Foo3:Foo3_t; (* Modula-3, not external *)to error. This is sem_t and sigset_t in particular. Possibly renaming is the thing.They used to be declared in Modula-3, system-dependently, butI moved them to portable C. I could remove the types entirely and change UseFoo to take an address,and declare mask and ackSem to be integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END; That would satisfy but I thought it might be nicer to still provide the namedtypes to refer to the external variables. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?What's wrong with using ADDRESS for references to opaque values? If sigset_t is never instantiated in Modula-3, then why do you need it declared there? 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 01:44, Jay wrote: Is there a way in Modula-3 to declare that a type exists, and there are <*external*> instances of it, without "fully" declaring it, so that no Modula-3 can instantiate it? I have done this for sigset_t and sem_t, but they could erroneously be instantiated by Modula-3 and I'd like to remove that ability to mess up so easily. (* This type is not declared correctly. It is only instantiated in C code. *) sigset_t = RECORD END;(* This type is not declared correctly. It is only instantiated in C code. *) sem_t = RECORD END;In C I believe you can do this, like: typedef struct foo foo_t; extern foo_t foo; void UseFoo(foo_t*); foo_t* GetFoo(void); Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 08:51:08 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 18:51:08 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: Why do you not build in the following order to get a new compiler? (You may need to downgrade Compiler.tmpl for use with an old compiler so that you don't get a mismatch between m3core and libm3, but otherwise the following sequence should work). m3core libm3 sysutils m3middle m3objfile m3linker m3back m3front m3quake cm3 On 12 Jan 2009, at 18:25, Jay wrote: > The compiler uses sysutils. The first pass builds against an old > package store, which might not have sysutils at all, if it is that > old. > > Again, once new m3core is around, no problem. > I could/should have put in the m3core change and just waited on the > sysutils change, rather than go ahead and do the quake stuff, and we > can do that now (or your change that moots it, which I haven't > looked into yet). > > I was browsing the docs and it appears there is an "import_pkg" > directive for like, copying in a package contents, instead of > linking. That might also solve this. I found that relatively late > and never looked into it. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 18:19:55 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Not true. sysutils should be built against the m3core with which it > will be linked. I don't think this is correct. > > On 12 Jan 2009, at 17:58, Jay wrote: > > To bootstrap I believe. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 17:53:02 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Why does sysutils need to be compatible with both old and new > versions of m3core? > > On 12 Jan 2009, at 17:39, Jay wrote: > > ThreadPosix is basically unaffected -- I never provided user threads > on Cygwin. > I guess it got a slight reduction regarding DoesWaitPidYield, but > its SchedulerPosix implementation was unchanged. > > The code in ThreadPosix is similar to but different than > ThreadPThread. > It is possible they could be merged but it wasn't trivial so I left > ThreadPosix alone. > > > You are smearing implementation details across multiple files and > directories > > You really think it is bad to have SchedulerPosix implemented in a > small separate file? > On top of what happens to be common implementation details of > ThreadPThread.m3 and ThreadWin32.m3? > > ThreadPScheduler.m3 is just basically three functions: IOWait, > IOAlertWait, XIOWait > Plus the little internal utility, UTimeFromTime, the one liner > DoesWaitPidYield, and non-trivial functions nested in XIOWait: > TestFDS, CallSelect. > > I mean, you know, an alternative is to copy out very large chunks of > ThreadWin32.m3 and ThreadPThread.m3 and merge them into > ThreadCygwin.m3. That would be worse imho. > > "Directories" hardly. > > Or I can try debugging cygwin pthreads again. > > - Jay > > > CC: jkrell at elego.de; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Mon, 12 Jan 2009 12:46:54 +1100 > > You are smearing implementation details across multiple files and > directories. Up until now, ThreadPThread has been nicely self- > contained, and captured all the basic pieces of the thread > implementation. Also, how does all of this fit with the ThreadPosix > implementation? > > On 12 Jan 2009, at 12:19, Jay wrote: > > btw, I don't think it's that hairy, I merely split it into two or > three files, and added interfaces so they can reuse code with each > other. Movement between files is hard to track though (depending on > version control, but with all I've used). > > The SchedulerPosix implementation moved to ThreadPScheduler.m3. > What is shared between it and ThreadPThread/Win32.m3 is > ThreadInternal.i3, which maybe should be in ThreadF.i3, though > that's exposed outside m3core, and ThreadInternal.i3 includes a > variable. > > I can try again to debug Cygwin pthreads though. > > - Jay > > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:03:33 +1100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay, > > > > Can you remind me again why Cygwin was unable to use pthreads? It > > seems you have introduced a bunch of hair into the PTHREADS > > implementation to deal with broken Cygwin pthreads. As many of us > > have already pointed out, Cygwin should be a port that tries as much > > as possible to be like a standard POSIX platform (pthread-based) as > > opposed to a weird Windows/POSIX hybrid. > > > > I have a bunch of code that will be going into the PTHREADS base > that > > I am now at a loss to integrate with the changes you have made. > > > > Help! > > > > -- Tony > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 08:52:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 18:52:34 +1100 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> Message-ID: <5406617A-EFAC-4506-B6F7-F1EFCE4A230E@cs.purdue.edu> There are some of us around who don't use your scripts and expect to be able to build any package using cm3 out of the box. I don't use scripts for my bootstrapping -- I just compile and ship the packages in the right order. On 12 Jan 2009, at 18:32, Jay wrote: > I didn't slow it back down yet, but I changed to a relative path > instead of ROOT. > All the scripts define ROOT and my config files ferry environment > variable CM3_ROOT to ROOT. > (ROOT is too generic for an environment variable.) > > oh -- m3core or sysytils? > sysutils needed it. I don't see what m3core does. > > - Jay > > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] declaring a type's existance but not enough > to instantiate it? > Date: Mon, 12 Jan 2009 07:27:09 +0000 > > Huh..that's what I was saying about the way m3overrides work -- the > directory structure IS duplicated /everywhere/.. I don't know what > choice there is, if quake code is to be shared across packages. > > m3tests does the same sort of thing, also to me. > > Ok, hold, I'll slow sysutils back down. > > - Jay > > > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 18:24:43 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > > Jay, > > > What the hell is the ROOT variable supposed to do now. I can't > build m3core with a compiler that doesn't define ROOT. And why does > the m3makefile that includes Uwaitpid.quake expect a hardwired cm3 > directory hierarchy. Surely, I should be able to build m3core as a > separate package, regardless of the structure in which it appears. > You are doing damage to the package structures here too, by > hardwiring these paths into the m3makefile. > > -- Tony > > On 12 Jan 2009, at 17:58, Jay wrote: > > We have conflicting goals. > > Keeping things as fast as possible and with as little C as possible, > vs. keeping things more portable, more easily ported, more obviously > correct. > > I want to drastically reduce the header cloning, or, the work of > porting. > It is already reduced, but I want to keep going. > I think having to make any changes at all in m3-libs/m3core/src/ > unix can be removed, other than adding the platform to the list of > platforms that uses the "portable" stuff. > Porting would devolve to: > update the lists of platforms -- including some in m3makefiles > update Target.m3 > clone/edit Csetjmp.i3 > add the GNU platform to m3cc/src/makefile > > and maybe nothing else. > > It is likely even that the IR is now portable, for "Posix" systems. > Pick word size, pick endian, generate 4 versions of IR, pick the > right one for your platform. > Except for the OSConfigPosix that sometimes returns the platform > name and cm3's defining "HOST". > > A variable isn't great, but it is faster and more source compatible > than a function call, at least. > And the C variable really will generally be read only. Writes to it > should fault. > > > In this particular case, you are wanting to use a Modula-3 > parameter > > passing mechanism on something that is not declared in Modula-3. > > Isn't this just a variation on what is done all the time? -- having > Modula-3 call C and sometimes vice versa? > C code calls Modula-3 signal handlers, with data created in the C > code. The Modula-3 code can then pass them on. I don't see the line > really. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 12:32:15 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > > > Jay, I really think you are bending over backwards too far just to > be able to shoe-horn things into C. I *like* having the transpar of > C header files expressed in Modula-3, *particularly* for system > calls, where you might even be trying to build on a system that does > not have the C header files installed, even though the libraries > exist and can be linked to. Fundamentally, I think anytime the > Modula-3 code is made less transparent you should think hard about > what you are doing. The same with the change of constants to > variables. > > I am getting very nervous that the changes you are making are > destroying the clarity of the Modula-3 run-time code. > > In this particular case, you are wanting to use a Modula-3 parameter > passing mechanism on something that is not declared in Modula-3. > Seems kind of dubious to me. Also, I really don't like the idea of > accessing external variables in C. > > -- Tony > > On 12 Jan 2009, at 11:55, Jay wrote: > > I considered ADDRESS. > However I think it still doesn't satisfy. > > I want to be able to do this: > > TYPE Foo_t = something; > <* EXTERNAL *> VAR Foo1, Foo2:Foo_t; > <* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); > > (* Modula-3, not external *) > PROCEDURE x()= > BEGIN > UseFoo(Foo1); > UseFoo(Foo2); > END x; > > AND I want any use of: > VAR Foo3:Foo3_t; (* Modula-3, not external *) > > to error. This is sem_t and sigset_t in particular. > > Possibly renaming is the thing. > They used to be declared in Modula-3, system-dependently, but > I moved them to portable C. > > I could remove the types entirely and change UseFoo to take an > address, > and declare mask and ackSem to be integers or I guess. > <*EXTERNAL> VAR ackSem : RECORD END; > > That would satisfy but I thought it might be nicer to still provide > the named > types to refer to the external variables. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 11:13:00 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > > What's wrong with using ADDRESS for references to opaque values? If > sigset_t is never instantiated in Modula-3, then why do you need it > declared there? > > 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 01:44, Jay wrote: > > Is there a way in Modula-3 to declare that a type exists, and there > are <*external*> instances of it, without "fully" declaring it, so > that no Modula-3 can instantiate it? > > I have done this for sigset_t and sem_t, but they could erroneously > be instantiated by Modula-3 and I'd like to remove that ability to > mess up so easily. > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sigset_t = RECORD END; > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sem_t = RECORD END; > > In C I believe you can do this, like: > typedef struct foo foo_t; > extern foo_t foo; > > void UseFoo(foo_t*); > foo_t* GetFoo(void); > > Thanks, > - Jay > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 08:59:09 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 07:59:09 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: <5406617A-EFAC-4506-B6F7-F1EFCE4A230E@cs.purdue.edu> References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> <5406617A-EFAC-4506-B6F7-F1EFCE4A230E@cs.purdue.edu> Message-ID: Understood. It should be ok now (well, "better" at least). > I just compile and ship the packages in the right order. Most folks claim an inability to do that actually. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:52:34 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it? There are some of us around who don't use your scripts and expect to be able to build any package using cm3 out of the box. I don't use scripts for my bootstrapping -- I just compile and ship the packages in the right order. On 12 Jan 2009, at 18:32, Jay wrote: I didn't slow it back down yet, but I changed to a relative path instead of ROOT.All the scripts define ROOT and my config files ferry environment variable CM3_ROOT to ROOT.(ROOT is too generic for an environment variable.)oh -- m3core or sysytils?sysutils needed it. I don't see what m3core does. - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] declaring a type's existance but not enough to instantiate it?Date: Mon, 12 Jan 2009 07:27:09 +0000Huh..that's what I was saying about the way m3overrides work -- the directory structure IS duplicated /everywhere/.. I don't know what choice there is, if quake code is to be shared across packages. m3tests does the same sort of thing, also to me. Ok, hold, I'll slow sysutils back down. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:24:43 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?Jay, What the hell is the ROOT variable supposed to do now. I can't build m3core with a compiler that doesn't define ROOT. And why does the m3makefile that includes Uwaitpid.quake expect a hardwired cm3 directory hierarchy. Surely, I should be able to build m3core as a separate package, regardless of the structure in which it appears. You are doing damage to the package structures here too, by hardwiring these paths into the m3makefile. -- Tony On 12 Jan 2009, at 17:58, Jay wrote: We have conflicting goals. Keeping things as fast as possible and with as little C as possible, vs. keeping things more portable, more easily ported, more obviously correct. I want to drastically reduce the header cloning, or, the work of porting. It is already reduced, but I want to keep going. I think having to make any changes at all in m3-libs/m3core/src/unix can be removed, other than adding the platform to the list of platforms that uses the "portable" stuff.Porting would devolve to: update the lists of platforms -- including some in m3makefiles update Target.m3 clone/edit Csetjmp.i3 add the GNU platform to m3cc/src/makefile and maybe nothing else. It is likely even that the IR is now portable, for "Posix" systems.Pick word size, pick endian, generate 4 versions of IR, pick the right one for your platform.Except for the OSConfigPosix that sometimes returns the platform name and cm3's defining "HOST". A variable isn't great, but it is faster and more source compatible than a function call, at least.And the C variable really will generally be read only. Writes to it should fault. > In this particular case, you are wanting to use a Modula-3 parameter > passing mechanism on something that is not declared in Modula-3. Isn't this just a variation on what is done all the time? -- having Modula-3 call C and sometimes vice versa?C code calls Modula-3 signal handlers, with data created in the C code. The Modula-3 code can then pass them on. I don't see the line really. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 12:32:15 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it? Jay, I really think you are bending over backwards too far just to be able to shoe-horn things into C. I *like* having the transpar of C header files expressed in Modula-3, *particularly* for system calls, where you might even be trying to build on a system that does not have the C header files installed, even though the libraries exist and can be linked to. Fundamentally, I think anytime the Modula-3 code is made less transparent you should think hard about what you are doing. The same with the change of constants to variables. I am getting very nervous that the changes you are making are destroying the clarity of the Modula-3 run-time code. In this particular case, you are wanting to use a Modula-3 parameter passing mechanism on something that is not declared in Modula-3. Seems kind of dubious to me. Also, I really don't like the idea of accessing external variables in C. -- Tony On 12 Jan 2009, at 11:55, Jay wrote: I considered ADDRESS.However I think it still doesn't satisfy. I want to be able to do this: TYPE Foo_t = something;<* EXTERNAL *> VAR Foo1, Foo2:Foo_t;<* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); (* Modula-3, not external *)PROCEDURE x()=BEGIN UseFoo(Foo1); UseFoo(Foo2);END x; AND I want any use of:VAR Foo3:Foo3_t; (* Modula-3, not external *)to error. This is sem_t and sigset_t in particular. Possibly renaming is the thing.They used to be declared in Modula-3, system-dependently, butI moved them to portable C. I could remove the types entirely and change UseFoo to take an address,and declare mask and ackSem to be integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END; That would satisfy but I thought it might be nicer to still provide the namedtypes to refer to the external variables. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?What's wrong with using ADDRESS for references to opaque values? If sigset_t is never instantiated in Modula-3, then why do you need it declared there? 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 01:44, Jay wrote: Is there a way in Modula-3 to declare that a type exists, and there are <*external*> instances of it, without "fully" declaring it, so that no Modula-3 can instantiate it? I have done this for sigset_t and sem_t, but they could erroneously be instantiated by Modula-3 and I'd like to remove that ability to mess up so easily. (* This type is not declared correctly. It is only instantiated in C code. *) sigset_t = RECORD END;(* This type is not declared correctly. It is only instantiated in C code. *) sem_t = RECORD END;In C I believe you can do this, like: typedef struct foo foo_t; extern foo_t foo; void UseFoo(foo_t*); foo_t* GetFoo(void); Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 09:02:37 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 08:02:37 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: If old compiler can't build m3core, such as if old compiler predates LONGINT. You already know this. Are we "past" such compilers? - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:51:08 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3 Why do you not build in the following order to get a new compiler? (You may need to downgrade Compiler.tmpl for use with an old compiler so that you don't get a mismatch between m3core and libm3, but otherwise the following sequence should work). m3core libm3 sysutils m3middle m3objfile m3linker m3back m3front m3quake cm3 On 12 Jan 2009, at 18:25, Jay wrote: The compiler uses sysutils. The first pass builds against an old package store, which might not have sysutils at all, if it is that old. Again, once new m3core is around, no problem.I could/should have put in the m3core change and just waited on the sysutils change, rather than go ahead and do the quake stuff, and we can do that now (or your change that moots it, which I haven't looked into yet). I was browsing the docs and it appears there is an "import_pkg" directive for like, copying in a package contents, instead of linking. That might also solve this. I found that relatively late and never looked into it. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:19:55 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3Not true. sysutils should be built against the m3core with which it will be linked. I don't think this is correct. On 12 Jan 2009, at 17:58, Jay wrote: To bootstrap I believe. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 17:53:02 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3Why does sysutils need to be compatible with both old and new versions of m3core? On 12 Jan 2009, at 17:39, Jay wrote: ThreadPosix is basically unaffected -- I never provided user threads on Cygwin. I guess it got a slight reduction regarding DoesWaitPidYield, but its SchedulerPosix implementation was unchanged. The code in ThreadPosix is similar to but different than ThreadPThread.It is possible they could be merged but it wasn't trivial so I left ThreadPosix alone. > You are smearing implementation details across multiple files and directories You really think it is bad to have SchedulerPosix implemented in a small separate file?On top of what happens to be common implementation details of ThreadPThread.m3 and ThreadWin32.m3? ThreadPScheduler.m3 is just basically three functions: IOWait, IOAlertWait, XIOWaitPlus the little internal utility, UTimeFromTime, the one liner DoesWaitPidYield, and non-trivial functions nested in XIOWait: TestFDS, CallSelect. I mean, you know, an alternative is to copy out very large chunks of ThreadWin32.m3 and ThreadPThread.m3 and merge them into ThreadCygwin.m3. That would be worse imho. "Directories" hardly. Or I can try debugging cygwin pthreads again. - Jay CC: jkrell at elego.de; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 12:46:54 +1100You are smearing implementation details across multiple files and directories. Up until now, ThreadPThread has been nicely self-contained, and captured all the basic pieces of the thread implementation. Also, how does all of this fit with the ThreadPosix implementation? On 12 Jan 2009, at 12:19, Jay wrote: btw, I don't think it's that hairy, I merely split it into two or three files, and added interfaces so they can reuse code with each other. Movement between files is hard to track though (depending on version control, but with all I've used). The SchedulerPosix implementation moved to ThreadPScheduler.m3.What is shared between it and ThreadPThread/Win32.m3 is ThreadInternal.i3, which maybe should be in ThreadF.i3, though that's exposed outside m3core, and ThreadInternal.i3 includes a variable. I can try again to debug Cygwin pthreads though. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:03:33 +1100> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Jay,> > Can you remind me again why Cygwin was unable to use pthreads? It > seems you have introduced a bunch of hair into the PTHREADS > implementation to deal with broken Cygwin pthreads. As many of us > have already pointed out, Cygwin should be a port that tries as much > as possible to be like a standard POSIX platform (pthread-based) as > opposed to a weird Windows/POSIX hybrid.> > I have a bunch of code that will be going into the PTHREADS base that > I am now at a loss to integrate with the changes you have made.> > Help!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: [M3devel] [M3commit] 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:18:29 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 08:18:29 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> Message-ID: I don't think a development system without C headers is interesting.. Is it really? The transform I apply at times is wherever there is interaction with C code that is described by system-dependent headers, or perhaps even fairly system-independent headers outside the Modula-3 tree, either write wrapper functions for the functionality in the headers (e.g. stat, waitpid), which can be done in a system-independent way, or move the Modula-3<->C transition higher, which is also usually system-independent, e.g. ThreadPThreadC_SetupHandlers. It is either that or clone the headers, which seems like the worse evil. There is always going to be a Modula-3<->C transition, it is just a matter of where it occurs. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?Date: Mon, 12 Jan 2009 12:32:15 +1100 Jay, I really think you are bending over backwards too far just to be able to shoe-horn things into C. I *like* having the transpar of C header files expressed in Modula-3, *particularly* for system calls, where you might even be trying to build on a system that does not have the C header files installed, even though the libraries exist and can be linked to. Fundamentally, I think anytime the Modula-3 code is made less transparent you should think hard about what you are doing. The same with the change of constants to variables. I am getting very nervous that the changes you are making are destroying the clarity of the Modula-3 run-time code. In this particular case, you are wanting to use a Modula-3 parameter passing mechanism on something that is not declared in Modula-3. Seems kind of dubious to me. Also, I really don't like the idea of accessing external variables in C. -- Tony On 12 Jan 2009, at 11:55, Jay wrote: I considered ADDRESS.However I think it still doesn't satisfy. I want to be able to do this: TYPE Foo_t = something;<* EXTERNAL *> VAR Foo1, Foo2:Foo_t;<* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); (* Modula-3, not external *)PROCEDURE x()=BEGIN UseFoo(Foo1); UseFoo(Foo2);END x; AND I want any use of:VAR Foo3:Foo3_t; (* Modula-3, not external *)to error. This is sem_t and sigset_t in particular. Possibly renaming is the thing.They used to be declared in Modula-3, system-dependently, butI moved them to portable C. I could remove the types entirely and change UseFoo to take an address,and declare mask and ackSem to be integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END; That would satisfy but I thought it might be nicer to still provide the namedtypes to refer to the external variables. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?What's wrong with using ADDRESS for references to opaque values? If sigset_t is never instantiated in Modula-3, then why do you need it declared there? 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 01:44, Jay wrote: Is there a way in Modula-3 to declare that a type exists, and there are <*external*> instances of it, without "fully" declaring it, so that no Modula-3 can instantiate it? I have done this for sigset_t and sem_t, but they could erroneously be instantiated by Modula-3 and I'd like to remove that ability to mess up so easily. (* This type is not declared correctly. It is only instantiated in C code. *) sigset_t = RECORD END;(* This type is not declared correctly. It is only instantiated in C code. *) sem_t = RECORD END;In C I believe you can do this, like: typedef struct foo foo_t; extern foo_t foo; void UseFoo(foo_t*); foo_t* GetFoo(void); Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 09:22:13 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 19:22:13 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: I think there is a straightforward fix for old compilers that can't compile LONGINT: define LongRep.T = INTEGER. Most everything should compile from there. That's what I recall doing to upgrade my compiler to handle LONGINT. LONGINT is not used anywhere else in m3core, so nothing depends on it working. On 12 Jan 2009, at 19:02, Jay wrote: > If old compiler can't build m3core, such as if old compiler predates > LONGINT. > You already know this. > Are we "past" such compilers? > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 18:51:08 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > Why do you not build in the following order to get a new compiler? > (You may need to downgrade Compiler.tmpl for use with an old > compiler so that you don't get a mismatch between m3core and libm3, > but otherwise the following sequence should work). > > m3core > libm3 > sysutils > m3middle > m3objfile > m3linker > m3back > m3front > m3quake > cm3 > > On 12 Jan 2009, at 18:25, Jay wrote: > > The compiler uses sysutils. The first pass builds against an old > package store, which might not have sysutils at all, if it is that > old. > > Again, once new m3core is around, no problem. > I could/should have put in the m3core change and just waited on the > sysutils change, rather than go ahead and do the quake stuff, and we > can do that now (or your change that moots it, which I haven't > looked into yet). > > I was browsing the docs and it appears there is an "import_pkg" > directive for like, copying in a package contents, instead of > linking. That might also solve this. I found that relatively late > and never looked into it. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 18:19:55 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Not true. sysutils should be built against the m3core with which it > will be linked. I don't think this is correct. > > On 12 Jan 2009, at 17:58, Jay wrote: > > To bootstrap I believe. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 17:53:02 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Why does sysutils need to be compatible with both old and new > versions of m3core? > > On 12 Jan 2009, at 17:39, Jay wrote: > > ThreadPosix is basically unaffected -- I never provided user threads > on Cygwin. > I guess it got a slight reduction regarding DoesWaitPidYield, but > its SchedulerPosix implementation was unchanged. > > The code in ThreadPosix is similar to but different than > ThreadPThread. > It is possible they could be merged but it wasn't trivial so I left > ThreadPosix alone. > > > You are smearing implementation details across multiple files and > directories > > You really think it is bad to have SchedulerPosix implemented in a > small separate file? > On top of what happens to be common implementation details of > ThreadPThread.m3 and ThreadWin32.m3? > > ThreadPScheduler.m3 is just basically three functions: IOWait, > IOAlertWait, XIOWait > Plus the little internal utility, UTimeFromTime, the one liner > DoesWaitPidYield, and non-trivial functions nested in XIOWait: > TestFDS, CallSelect. > > I mean, you know, an alternative is to copy out very large chunks of > ThreadWin32.m3 and ThreadPThread.m3 and merge them into > ThreadCygwin.m3. That would be worse imho. > > "Directories" hardly. > > Or I can try debugging cygwin pthreads again. > > - Jay > > > CC: jkrell at elego.de; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Mon, 12 Jan 2009 12:46:54 +1100 > > You are smearing implementation details across multiple files and > directories. Up until now, ThreadPThread has been nicely self- > contained, and captured all the basic pieces of the thread > implementation. Also, how does all of this fit with the ThreadPosix > implementation? > > On 12 Jan 2009, at 12:19, Jay wrote: > > btw, I don't think it's that hairy, I merely split it into two or > three files, and added interfaces so they can reuse code with each > other. Movement between files is hard to track though (depending on > version control, but with all I've used). > > The SchedulerPosix implementation moved to ThreadPScheduler.m3. > What is shared between it and ThreadPThread/Win32.m3 is > ThreadInternal.i3, which maybe should be in ThreadF.i3, though > that's exposed outside m3core, and ThreadInternal.i3 includes a > variable. > > I can try again to debug Cygwin pthreads though. > > - Jay > > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:03:33 +1100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay, > > > > Can you remind me again why Cygwin was unable to use pthreads? It > > seems you have introduced a bunch of hair into the PTHREADS > > implementation to deal with broken Cygwin pthreads. As many of us > > have already pointed out, Cygwin should be a port that tries as much > > as possible to be like a standard POSIX platform (pthread-based) as > > opposed to a weird Windows/POSIX hybrid. > > > > I have a bunch of code that will be going into the PTHREADS base > that > > I am now at a loss to integrate with the changes you have made. > > > > Help! > > > > -- Tony > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 09:24:50 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 19:24:50 +1100 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> Message-ID: <54BC9DFC-09FC-4082-9E10-694EAAF6E5EC@cs.purdue.edu> Point taken. We live in a C universe and so need to interact. I do think your work with the headers is useful, and I want it to continue. Especially in simplifying ports. On 12 Jan 2009, at 19:18, Jay wrote: > I don't think a development system without C headers is > interesting.. Is it really? > > The transform I apply at times is wherever there is interaction with > C code that is described by system-dependent headers, or perhaps > even fairly system-independent headers outside the Modula-3 tree, > either write wrapper functions for the functionality in the headers > (e.g. stat, waitpid), which can be done in a system-independent way, > or move the Modula-3<->C transition higher, which is also usually > system-independent, e.g. ThreadPThreadC_SetupHandlers. > > It is either that or clone the headers, which seems like the worse > evil. > > There is always going to be a Modula-3<->C transition, it is just a > matter of where it occurs. > > - Jay > > > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > Date: Mon, 12 Jan 2009 12:32:15 +1100 > > > Jay, I really think you are bending over backwards too far just to > be able to shoe-horn things into C. I *like* having the transpar of > C header files expressed in Modula-3, *particularly* for system > calls, where you might even be trying to build on a system that does > not have the C header files installed, even though the libraries > exist and can be linked to. Fundamentally, I think anytime the > Modula-3 code is made less transparent you should think hard about > what you are doing. The same with the change of constants to > variables. > > I am getting very nervous that the changes you are making are > destroying the clarity of the Modula-3 run-time code. > > In this particular case, you are wanting to use a Modula-3 parameter > passing mechanism on something that is not declared in Modula-3. > Seems kind of dubious to me. Also, I really don't like the idea of > accessing external variables in C. > > -- Tony > > On 12 Jan 2009, at 11:55, Jay wrote: > > I considered ADDRESS. > However I think it still doesn't satisfy. > > I want to be able to do this: > > TYPE Foo_t = something; > <* EXTERNAL *> VAR Foo1, Foo2:Foo_t; > <* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); > > (* Modula-3, not external *) > PROCEDURE x()= > BEGIN > UseFoo(Foo1); > UseFoo(Foo2); > END x; > > AND I want any use of: > VAR Foo3:Foo3_t; (* Modula-3, not external *) > > to error. This is sem_t and sigset_t in particular. > > Possibly renaming is the thing. > They used to be declared in Modula-3, system-dependently, but > I moved them to portable C. > > I could remove the types entirely and change UseFoo to take an > address, > and declare mask and ackSem to be integers or I guess. > <*EXTERNAL> VAR ackSem : RECORD END; > > That would satisfy but I thought it might be nicer to still provide > the named > types to refer to the external variables. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 11:13:00 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > > What's wrong with using ADDRESS for references to opaque values? If > sigset_t is never instantiated in Modula-3, then why do you need it > declared there? > > 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 01:44, Jay wrote: > > Is there a way in Modula-3 to declare that a type exists, and there > are <*external*> instances of it, without "fully" declaring it, so > that no Modula-3 can instantiate it? > > I have done this for sigset_t and sem_t, but they could erroneously > be instantiated by Modula-3 and I'd like to remove that ability to > mess up so easily. > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sigset_t = RECORD END; > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sem_t = RECORD END; > > In C I believe you can do this, like: > typedef struct foo foo_t; > extern foo_t foo; > > void UseFoo(foo_t*); > foo_t* GetFoo(void); > > Thanks, > - Jay > > > > > > > -------------- 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: [M3devel] [M3commit] 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 jay.krell at cornell.edu Mon Jan 12 09:47:17 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 08:47:17 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: <54BC9DFC-09FC-4082-9E10-694EAAF6E5EC@cs.purdue.edu> References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> <54BC9DFC-09FC-4082-9E10-694EAAF6E5EC@cs.purdue.edu> Message-ID: This is what you "have to" chose between. Header cloning or C code (and C headers). CONST or VAR (or functions?) I'm going to likely make the Uerror change tonight. You can still veto it (er, vote against it :) ) Possibly some convuluted C (enum/#undef), or splitting the Modula-3 at boundaries that weren't previously believed "natural". (See how SetupHandlers is ~two lines in Modula-3 and the rest in C; this is partly out of ignorance. I don't know how to write those two lines in C; and laziness, I didn't look into how). Remember I'm still staying away from mainstream platforms, so the value isn't what it might appear to be, but it is "stage setting", and the show might go on. :) Also, the dilemna does get more difficult now, with the little C header cloning that remains. For example, look at Upthreads.i3. Mainly, look at function prototypes. Constants and types are "known problems". Prototypes are gray. They actually tend to be portable. For example: TYPE pid_t = INTEGER; <*EXTERNAL "m3_getpid*> PROCEDURE getpid():pid_t; or leave it alone? getpid is probably the worst example. It is so very portable declared in Modula-3. But still, imagine pid_t might be 16bits or 32 or 64. Writing a wrapper is more portable -- as long as the pid isn't stuff into some record that the system defines. Again, Upthreads.i3. Would you like to see it reduced, or left alone? Only deal with the types and initializers, or also the prototypes? You know, I could write a little portable layer, where all the types are pointers, always null initialized. It would buy /some/ portability, and cost some. Do you like the sem_t change? Partly? Not at all? There is one sem_t in the system. So I moved it to be in C code. Or, as I had it before, declared as the max size/align of all the platforms -- getting that right is the same work as getting it right "the old way", except if you make a mistake, odds are still good of it being ok. Should the line be drawn at generating the remaining headers, rather than eliminating them? Uerror.i3 is easily generated. Good enough? Upthread.i3's types can be generated generally as records with opaque arrays with the right size and alignment. Other stuff can be generated or at least checked. e.g. to check that getpid is declared correctly, you can assign it to a function pointer and see if that compiles. Perf on Uerror arguably doesn't matter. Is it only error handling code?Or do sockets often go down "error" paths, because they are slow and you are waiting for more data? Anyway, point is, I agree for sure this is valuable, but I might be hitting the "tail" of the approach and should switch, I'm not sure. I keep saying that though, and then press further. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 19:24:50 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it? Point taken. We live in a C universe and so need to interact. I do think your work with the headers is useful, and I want it to continue. Especially in simplifying ports. On 12 Jan 2009, at 19:18, Jay wrote: I don't think a development system without C headers is interesting.. Is it really? The transform I apply at times is wherever there is interaction with C code that is described by system-dependent headers, or perhaps even fairly system-independent headers outside the Modula-3 tree, either write wrapper functions for the functionality in the headers (e.g. stat, waitpid), which can be done in a system-independent way, or move the Modula-3<->C transition higher, which is also usually system-independent, e.g. ThreadPThreadC_SetupHandlers. It is either that or clone the headers, which seems like the worse evil. There is always going to be a Modula-3<->C transition, it is just a matter of where it occurs. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?Date: Mon, 12 Jan 2009 12:32:15 +1100 Jay, I really think you are bending over backwards too far just to be able to shoe-horn things into C. I *like* having the transpar of C header files expressed in Modula-3, *particularly* for system calls, where you might even be trying to build on a system that does not have the C header files installed, even though the libraries exist and can be linked to. Fundamentally, I think anytime the Modula-3 code is made less transparent you should think hard about what you are doing. The same with the change of constants to variables. I am getting very nervous that the changes you are making are destroying the clarity of the Modula-3 run-time code. In this particular case, you are wanting to use a Modula-3 parameter passing mechanism on something that is not declared in Modula-3. Seems kind of dubious to me. Also, I really don't like the idea of accessing external variables in C. -- Tony On 12 Jan 2009, at 11:55, Jay wrote: I considered ADDRESS.However I think it still doesn't satisfy. I want to be able to do this: TYPE Foo_t = something;<* EXTERNAL *> VAR Foo1, Foo2:Foo_t;<* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); (* Modula-3, not external *)PROCEDURE x()=BEGIN UseFoo(Foo1); UseFoo(Foo2);END x; AND I want any use of:VAR Foo3:Foo3_t; (* Modula-3, not external *)to error. This is sem_t and sigset_t in particular. Possibly renaming is the thing.They used to be declared in Modula-3, system-dependently, butI moved them to portable C. I could remove the types entirely and change UseFoo to take an address,and declare mask and ackSem to be integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END; That would satisfy but I thought it might be nicer to still provide the namedtypes to refer to the external variables. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?What's wrong with using ADDRESS for references to opaque values? If sigset_t is never instantiated in Modula-3, then why do you need it declared there? 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 01:44, Jay wrote: Is there a way in Modula-3 to declare that a type exists, and there are <*external*> instances of it, without "fully" declaring it, so that no Modula-3 can instantiate it? I have done this for sigset_t and sem_t, but they could erroneously be instantiated by Modula-3 and I'd like to remove that ability to mess up so easily. (* This type is not declared correctly. It is only instantiated in C code. *) sigset_t = RECORD END;(* This type is not declared correctly. It is only instantiated in C code. *) sem_t = RECORD END;In C I believe you can do this, like: typedef struct foo foo_t; extern foo_t foo; void UseFoo(foo_t*); foo_t* GetFoo(void); Thanks, - Jay -------------- 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: [M3devel] [M3commit] 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: [M3devel] [M3commit] 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 mika at async.caltech.edu Mon Jan 12 10:06:30 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 12 Jan 2009 01:06:30 -0800 Subject: [M3devel] Juno (X) networking problem on AMD64_FREEBSD In-Reply-To: Your message of "Sun, 11 Jan 2009 22:02:18 GMT." Message-ID: <200901120906.n0C96Uwn074046@camembert.async.caltech.edu> Jay, I think the problem here is actually in the caller. Why does a caller need "GetHostAddr()"? It is probably doing this for the purpose of calling listen() or some such thing. What the caller probably *really* wants is INADDR_ANY, and not the IP address of some arbitrarily chosen interface on the host. I'm guessing it works on the Mac because the Mac libraries do something complicated when you ask for the host's name (i.e., they somehow generate a hostname that always maps to the IP address of an interface on the computer). Mika Jay writes: >--_b00371fe-730b-4981-9051-a874361296d7_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Do you know the right way? >=20 >PPC_LINUX "just worked"=2C and I can check Solaris and Darwin. >=20 >I don't want to edit /etc/hosts -- I use DHCP. >Though DHCP has been bothering me -- only for some of my machines do names = >resolve=2C so I end using IP addresses=2C which change sometimes=2C and I l= >oop over them running ssh to all of them and "see what I get"=2C not ideal. >=20 > - Jay> To: jay.krell at cornell.edu> Date: Sun=2C 11 Jan 2009 08:02:18 -0800>= > From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3d= >evel] Juno (X) networking problem on AMD64_FREEBSD> > This is a screwy thin= >g in Modula-3. A bug I would call it.> > I've noticed a lot of networking M= >3 programs don't work right unless> the return value of Unix's "hostname" m= >aps to a real IP address via> gethostbyname. I accomplish it in practice by= > adding my hostname> to /etc/hosts.> > This is obviously not the right way = >to fix it... > > Mika> > Jay writes:> >--_9e67232c-a064-417d-879e-227a77e31= >0f9_> >Content-Type: text/plain=3B charset=3D"iso-8859-1"> >Content-Transfe= >r-Encoding: quoted-printable> >> >> >Hi. Unix network programming question.= >.> >AMD64_FREEBSD:> >$DISPLAY is set to point back to Cygwin host.It works = >for PPC_LINUX.> >[jay at fbsdamd64a /cm3/bin]$ ./Juno> >****** runtime error:*= >** Exception "IPError.FatalError" not in RAISES li=3D> >st*** file "../src/= >common/IPError.m3"=3D2C line 27***> >Abort trap: 6 (core dumped)[jay at fbsdam= >d64a /cm3/bin]$> >IP.m3:> >=3D20> >PROCEDURE GetHostAddr(): Address =3D3D V= >AR hname: ARRAY [0..255] OF CHAR=3D3B =3D> > BEGIN LOCK mu DO IF Unix.getho= >stname(ADR(hname[0])=3D2C BYTESIZE(hna=3D> >me)) # 0 THEN IPError.Die ()=3D= >3B END=3D3B VAR h :=3D3D Unetdb.g=3D> >ethostbyname(ADR(hname[0]))=3D3B BEG= >IN IF h =3D3D NIL THEN IPError.Die()=3D> >=3D3B END=3D3B RETURN GetAddress(= >h)=3D3B END=3D3B END=3D3B END GetHos=3D> >tAddr=3D3B> >PROCEDURE GetAddress= > (ent: Unetdb.struct_hostent_star): Address =3D3D VAR ua=3D> >: Uin.struct_= >in_addr=3D3B BEGIN <* ASSERT ent.h_length <=3D3D BYTESIZE(Addr=3D> >ess) *>= > ua :=3D3D LOOPHOLE(ent.h_addr_list=3D2C UNTRACED =3D> >REF UNTRACED REF Ui= >n.struct_in_addr)^^=3D3B RETURN LOOPHOLE(ua.s_addr=3D2C A=3D> >ddress)=3D3B= > END GetAddress=3D3B> >=3D20> >gethostbyname is failing.> >=3D20> >Analogou= >s C code also fails:> >=3D20> >[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c#include= > #include #i=3D> >nclude #include type= >def struct hostent hostent_t=3D3B> >=3D20> >int main(){ char hostname[200]= >=3D3B hostent_t* h=3D3B int i=3D3B> > i =3D3D gethostname(hostname=3D2C 200= >)=3D3B assert(i =3D3D=3D3D 0)=3D3B printf("hostna=3D> >me: %s\n"=3D2C hostn= >ame)=3D3B h =3D3D gethostbyname(hostname)=3D3B herror("foo")=3D3B=3D> > pri= >ntf("%p %d %d\n"=3D2C h=3D2C errno=3D2C h_errno)=3D3B assert(h)=3D3B return= > 0=3D3B}> >=3D20> >herror says "unknown host".> >Stack is:> > at ../src/run= >time/ex_frame/RTExFrame.m3:58#13 0x0000000801a7f2b3 in RTH=3D> >ooks__Raise= > (M3_AJWxb1_ex=3D3DError accessing memory address 0x8000ffffd278: =3D> >Bad= > address.) at ../src/runtime/common/RTHooks.m3:79#14 0x000000080169c8=3D> >= >d3 in IPError__Die () at ../src/common/IPError.m3:27#15 0x0000000801698a3e = >=3D> >in IP__GetHostAddr (M3_BCxjPn__result=3D3DError accessing memory addr= >ess 0x80=3D> >00ffffd338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x00000= >008012133d0=3D> > in XSharedMem__SameHost (M3_AQuuui_trsl=3D3DError accessi= >ng memory address 0=3D> >x8000ffffd4d8: Bad address.) at ../src/xvbt/XShare= >dMem.m3:96#17 0x000000=3D> >0801212ab7 in XSharedMem__InitXClient (M3_AQuuu= >i_v=3D3DError accessing memory=3D> > address 0x8000ffffd648: Bad address.) = >at ../src/xvbt/XSharedMem.m3:29#1=3D> >8 0x0000000801211819 in XExtensions_= >_InitXClient (M3_AQuuui_xclient=3D3DError=3D> > accessing memory address 0x= >8000ffffd7f8: Bad address.) at ../src/xvbt/X=3D> >Extensions.m3:14#19 0x000= >00008012467a4 in XClientF__Connect (M3_Bd56fi_inst=3D> >=3D3D0x1879b=3D2C M= >3_AQuuui_trsl=3D3D0x6) at ../src/xvbt/XClientF.m3:583---Typ=3D> >e = > to continue=3D2C or q to quit---(More stack frames follow=3D> >..= >.)(gdb)> >(* return TRUE if server and client are on same host *)PROCEDURE = >SameHost (=3D> >trsl: XClient.T): BOOLEAN =3D3D VAR display :=3D3D DisplayH= >=3D> >ost(trsl)=3D3B displayAddr: IP.Address=3D3B BEGIN IF display =3D3D NI= >L THE=3D> >N RETURN TRUE=3D3B END=3D3B> > TRY IF NOT IP.GetHostByName(displ= >ay=3D2C displayAddr) THEN RETURN FA=3D> >LSE=3D3B END=3D3B RETURN displayAd= >dr =3D3D IP.GetHostAddr()=3D3B EXCEPT =3D> >| IP.Error =3D3D> RETURN FALSE= >=3D3B END=3D3B END SameHost=3D3B> >=3D20> >Thoughts?> >=3D20> >Perhaps my n= >etwork isn't setup well=3D2C like I should add the local machine =3D> >to /= >etc/hosts.I think this can be made to fail gracefully though.It seems l=3D>= > >ike it has nothing to do with AMD64_FREEBSD=3D2C but could have to do wit= >h Fr=3D> >eeBSD.> >=3D20> >Seems like SocketPosix has nearly the exact same= > code but appearsmore forgi=3D> >ving.. IOError instead of Fatal?> >=3D20> = >>SocketPosix.m3:> >=3D20> >PROCEDURE GetHostAddr (): Address RAISES {OSErro= >r.E} =3D3D VAR host : AR=3D> >RAY [0..255] OF CHAR=3D3B info : Unetdb.struc= >t_hostent_star=3D3B ua : U=3D> >in.struct_in_addr=3D3B BEGIN IF Unix.gethos= >tname (ADR (host[0])=3D2C BYTESI=3D> >ZE (host)) # 0 THEN IOError (Unexpect= >ed)=3D3B END=3D3B> > info :=3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3B = >IF info =3D3D NIL TH=3D> >EN IOError (Unexpected)=3D3B END=3D3B <* ASSERT i= >nfo.h_length <=3D3D BYTESIZE =3D> >(Address) *>> > ua :=3D3D LOOPHOLE(info.= >h_addr_list=3D2C UNTRACED REF UNT=3D> >RACED REF Uin.struct_in_addr)^^=3D3B= > RETURN LOOPHOLE (ua.s_addr=3D2C Address=3D> >)=3D3B END GetHostAddr=3D3B> = >>=3D20> >=3D20> >It is again disappointing to see such code duplication.> >= >=3D20> >=3D20> >I guess SameHost can duplicate the logic to predict the err= >or state and ret=3D> >urn false upon error?> >Duplicating the logic for a t= >hird time. :(> >=3D20> > - Jay=3D> >> >--_9e67232c-a064-417d-879e-227a77e31= >0f9_> >Content-Type: text/html=3B charset=3D"iso-8859-1"> >Content-Transfer= >-Encoding: quoted-printable> >> >> >> >> >> >mmessage'>> >Hi. Unix network programming question..
> >
AMD64_FREEBS= >D:
> >
$DISPLAY is set to point back to Cygwin host.
It works for = >PPC_LINUX=3D> >.
> >
[jay at fbsdamd64a /cm3/bin]$ ./Juno
> >
***<= >BR>*** runtime error:
*** =3D3B =3D3B =3D3B Exception "IPE= >=3D> >rror.FatalError" not in RAISES list
*** =3D3B =3D3B = >=3D3B file "..=3D> >/src/common/IPError.m3"=3D2C line 27
***
> >
A= >bort trap: 6 (core dumped)
[jay at fbsdamd64a /cm3/bin]$
> >
IP.m3:R>> > =3D3B
> >PROCEDURE GetHostAddr(): Address =3D3D
 =3D3B = >VAR hname: ARRAY [0..255] =3D> OF CHAR=3D3B
 =3D3B BEGIN
 =3D= >3B =3D3B =3D3B LOCK mu DO
&nbs=3D> >p=3D3B =3D3B =3D3B&n= >bsp=3D3B =3D3B IF Unix.gethostname(ADR(hname[0])=3D2C B=3D> >YTESIZE(hn= >ame)) # 0 THEN
 =3D3B =3D3B =3D3B =3D3B =3D3B = >=3D> >=3D3B =3D3B IPError.Die ()=3D3B
 =3D3B =3D3B =3D3B= > =3D3B =3D3B E=3D> >ND=3D3B
 =3D3B =3D3B =3D3B = >=3D3B =3D3B VAR h :=3D3D Unetdb.gethost=3D> >byname(ADR(hname[0]))=3D3B= > BEGIN
 =3D3B =3D3B =3D3B =3D3B =3D3B&=3D> >nbsp=3D3= >B =3D3B IF h =3D3D NIL THEN IPError.Die()=3D3B END=3D3B
 =3D3B&n= >bsp=3D> >=3D3B =3D3B =3D3B =3D3B =3D3B =3D3B RETURN Get= >Address(h)=3D3B
&nbs=3D> >p=3D3B =3D3B =3D3B =3D3B =3D3B= > END=3D3B
 =3D3B =3D3B =3D3B END=3D> >=3D3B
 =3D3B EN= >D GetHostAddr=3D3B
> >
PROCEDURE GetAddress (ent: Unetdb.struct_hoste= >nt_star): Address =3D3D
=3D> > =3D3B VAR ua: Uin.struct_in_addr=3D3B= >
 =3D3B BEGIN
 =3D3B =3D> >=3D3B =3D3B <=3D3B* ASSE= >RT ent.h_length <=3D3B=3D3D BYTESIZE(Address) *>=3D3B=3D> >
 =3D= >3B =3D3B =3D3B ua :=3D3D LOOPHOLE(ent.h_addr_list=3D2C
 =3D>= > >=3D3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D= >3B =3D3B =3D3B=3D> > =3D3B =3D3B =3D3B =3D3B = >=3D3B =3D3B =3D3B =3D3B =3D3B UN=3D> >TRACED REF UNTRACED R= >EF Uin.struct_in_addr)^^=3D3B
 =3D3B =3D3B =3D> >=3D3B RETUR= >N LOOPHOLE(ua.s_addr=3D2C Address)=3D3B
 =3D3B END GetAddress=3D3B<= >=3D> >BR>> > =3D3B
> >gethostbyname is failing.
> >
 =3D3B= >
> >Analogous C code also fails:
> > =3D3B
> >
[jay at fbsdamd= >64a /cm3/bin]$ cat ~/5.c
#include <=3D3Bassert.h>=3D3B >R>#inc= >lude <=3D3Bnetdb.h>=3D3B
#include <=3D3Bstdio.h>=3D3B
#includ= >e =3D> ><=3D3Berrno.h>=3D3B
typedef struct hostent hostent_t=3D3B>> > =3D3B
> >int main()
{
 =3D3Bchar hostname[200]=3D3BR> =3D3Bhostent_t* h=3D3B=3D> >
 =3D3Bint i=3D3B
> > =3D3= >Bi =3D3D gethostname(hostname=3D2C 200)=3D3B
 =3D3Bassert(i =3D3D=3D= >3D 0)=3D> >=3D3B
 =3D3Bprintf("hostname: %s\n"=3D2C hostname)=3D3BR> =3D3Bh =3D3D get=3D> >hostbyname(hostname)=3D3B
 =3D3Bherror(= >"foo")=3D3B
 =3D3Bprintf("%p %=3D> >d %d\n"=3D2C h=3D2C errno=3D2C h= >_errno)=3D3B
 =3D3Bassert(h)=3D3B
 =3D3Bret=3D> >urn 0=3D3BR>}
> > =3D3B
> >herror says "unknown host".
> >
Stack is:<= >BR>> > =3D3B =3D3B =3D3B at ../src/runtime/ex_frame/RTExFrame.m= >3:58
#13 =3D> >0x0000000801a7f2b3 in RTHooks__Raise (M3_AJWxb1_ex=3D3DEr= >ror accessing memory=3D> > ad
dress 0x8000ffffd278: Bad address.
)> =3D3B =3D3B =3D3B =3D> >at ../src/runtime/common/RTHooks.m3:7= >9
#14 0x000000080169c8d3 in IPError=3D> >__Die () at ../src/common/IPErr= >or.m3:27
#15 0x0000000801698a3e in IP__Ge=3D> >tHostAddr (M3_BCxjPn__res= ult=3D3DError accessing mem
ory address 0x8000fff=3D> >fd338: Bad addres= >s.
)
 =3D3B =3D3B =3D3B at ../src/POSIX/IP.m3:=3D> >82>#16 0x00000008012133d0 in XSharedMem__SameHost (M3_AQuuui_trsl=3D3DErro=3D= >> >r accessing m
emory address 0x8000ffffd4d8: Bad address.
)
&nbs= >p=3D> >=3D3B =3D3B =3D3B at ../src/xvbt/XSharedMem.m3:96
#17 0x0= >000000801212a=3D> >b7 in XSharedMem__InitXClient (M3_AQuuui_v=3D3DError acc= >essing m
emory add=3D> >ress 0x8000ffffd648: Bad address.
)
 = >=3D3B =3D3B =3D3B at ../sr=3D> >c/xvbt/XSharedMem.m3:29
#18 0x00= >00000801211819 in XExtensions__InitXClie=3D> >nt (M3_AQuuui_xclient=3D3DErr= >or acce
ssing memory address 0x8000ffffd7f8: =3D> >Bad address.
)
= > =3D3B =3D3B =3D3B at ../src/xvbt/XExtensions.m3=3D> >:14
#1= >9 0x00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst=3D3D0x1879=3D> >b= >=3D2C
 =3D3B =3D3B =3D3B M3_AQuuui_trsl=3D3D0x6) at ../src/x= >vbt/XClie=3D> >ntF.m3:583
---Type <=3D3Breturn>=3D3B to continue=3D2= >C or q <=3D3Breturn&g=3D> >t=3D3B to quit---
(More stack frames follow= >...)
(gdb)
> >
(* return TRUE if server and client are on same hos= >t *)
PROCEDURE Sa=3D> >meHost (trsl: XClient.T): BOOLEAN =3D3D
 = >=3D3B VAR
 =3D3B =3D3B&n=3D> >bsp=3D3B display =3D3B =3D= >3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D> >=3D3B = >=3D3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D3B= :=3D3D Di=3D> >splayHost(trsl)=3D3B
 =3D3B =3D3B =3D3B disp= >layAddr: IP.Address=3D3B >R> =3D3B BEGIN
 =3D3B =3D3B&= >nbsp=3D3B IF display =3D3D NIL THEN RETURN=3D> > TRUE=3D3B END=3D3B
> >&= >nbsp=3D3B =3D3B =3D3B TRY
 =3D3B =3D3B =3D3B =3D= >3B =3D3B IF=3D> > NOT IP.GetHostByName(display=3D2C displayAddr) THEN R= >ETURN FALSE=3D3B END=3D3B >R> =3D3B =3D3B =3D3B =3D3B= > =3D3B RETURN displayAddr =3D3D IP.GetHos=3D> >tAddr()=3D3B
 =3D= >3B =3D3B =3D3B EXCEPT
 =3D3B =3D3B =3D3B |=3D> > IP.= >Error =3D3D>=3D3B RETURN FALSE=3D3B
 =3D3B =3D3B =3D3B END= >=3D3B
&=3D> >nbsp=3D3B END SameHost=3D3B
> > =3D3B
> >Thoughts= >?
> > =3D3B
> >
Perhaps my network isn't setup well=3D2C like = >I should add the local mach=3D> >ine to /etc/hosts.
I think this can be = >made to fail gracefully though. >R>It seems like it has nothing to do= > with AMD64_FREEBSD=3D2C but could have t=3D> >o do with FreeBSD.
> >> =3D3B
> >Seems like SocketPosix has nearly the exact same code but= > appears
more f=3D> >orgiving.. IOError instead of Fatal?
> > =3D= >3B
> >
SocketPosix.m3:
> > =3D3B
> >
PROCEDURE GetHostAd= >dr (): Address
 =3D3B RAISES {OSError.E} =3D3D >> =3D3B V= >AR
 =3D3B =3D3B =3D3B host : ARRAY [0..255] OF CHAR=3D3B<=3D= >> >BR> =3D3B =3D3B =3D3B info : Unetdb.struct_hostent_star=3D3B= >
 =3D> >=3D3B =3D3B =3D3B ua =3D3B =3D3B : Uin.struc= >t_in_addr=3D3B
 =3D3B =3D> >BEGIN
 =3D3B =3D3B =3D3B = >IF Unix.gethostname (ADR (host[0])=3D2C BYT=3D> >ESIZE (host)) # 0 THEN
= > =3D3B =3D3B =3D3B =3D3B =3D3B IOError =3D> >(Unexpecte= >d)=3D3B
 =3D3B =3D3B =3D3B END=3D3B
> > =3D3B =3D= >3B =3D3B info :=3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3B<=3D> >BR= >> =3D3B =3D3B =3D3B IF info =3D3D NIL THEN IOError (Unexpected)= >=3D3B EN=3D> >D=3D3B
 =3D3B =3D3B =3D3B <=3D3B* ASSERT inf= >o.h_length <=3D3B=3D3D BYT=3D> >ESIZE (Address) *>=3D3B
> > =3D3= >B =3D3B =3D3B ua :=3D3D LOOPHOLE(info.h_addr_list=3D2C
 =3D3= >B&n=3D> >bsp=3D3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D= >3B =3D3B =3D3B =3D> >=3D3B =3D3B =3D3B =3D3B = >=3D3B =3D3B =3D3B =3D3B UNTRACED REF UN=3D> >TRACED REF Uin.str= >uct_in_addr)^^=3D3B
 =3D3B =3D3B =3D3B RETURN LOOP=3D> >HOLE= > (ua.s_addr=3D2C Address)=3D3B
 =3D3B END GetHostAddr=3D3B
> >&nb= >sp=3D3B
> > =3D3B
> >It is again disappointing to see such code d= >uplication.
> > =3D3B
> > =3D3B
> >I guess =3D3BSameHo= >st can duplicate the logic to predict the error state =3D> >and return fals= >e =3D3Bupon error?
> >Duplicating the logic for a third time. :(
= >> > =3D3B
> >
 =3D3B- Jay

> >=3D> >> >--= >_9e67232c-a064-417d-879e-227a77e310f9_--= > >--_b00371fe-730b-4981-9051-a874361296d7_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Do you know the right way?
> =3B
>PPC_LINUX "just worked"=2C and I can check Solaris and Darwin.
> =3B
>I don't want to edit /etc/hosts -- I use DHCP.
>Though DHCP has been bothering me -- only for some of my machines do names = >resolve=2C so I end using IP addresses=2C which change sometimes=2C and I l= >oop over them running ssh to all of them and "see what I get"=2C not ideal.= >
> =3B
> =3B- Jay


>=3B To: jay.krell at cornell.edu
>=3B Date: S= >un=2C 11 Jan 2009 08:02:18 -0800
>=3B From: mika at async.caltech.edu
= >>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] Juno (X) = >networking problem on AMD64_FREEBSD
>=3B
>=3B This is a screwy t= >hing in Modula-3. A bug I would call it.
>=3B
>=3B I've noticed = >a lot of networking M3 programs don't work right unless
>=3B the retur= >n value of Unix's "hostname" maps to a real IP address via
>=3B gethos= >tbyname. I accomplish it in practice by adding my hostname
>=3B to /et= >c/hosts.
>=3B
>=3B This is obviously not the right way to fix it= >...
>=3B
>=3B Mika
>=3B
>=3B Jay writes:
>=3B &= >gt=3B--_9e67232c-a064-417d-879e-227a77e310f9_
>=3B >=3BContent-Type:= > text/plain=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Enco= >ding: quoted-printable
>=3B >=3B
>=3B >=3B
>=3B >=3BHi= >. Unix network programming question..
>=3B >=3BAMD64_FREEBSD:
>= >=3B >=3B$DISPLAY is set to point back to Cygwin host.It works for PPC_LIN= >UX.
>=3B >=3B[jay at fbsdamd64a /cm3/bin]$ ./Juno
>=3B >=3B*****= >* runtime error:*** Exception "IPError.FatalError" not in RAISES li=3D
&= >gt=3B >=3Bst*** file "../src/common/IPError.m3"=3D2C line 27***
>=3B= > >=3BAbort trap: 6 (core dumped)[jay at fbsdamd64a /cm3/bin]$
>=3B >= >=3BIP.m3:
>=3B >=3B=3D20
>=3B >=3BPROCEDURE GetHostAddr(): Ad= >dress =3D3D VAR hname: ARRAY [0..255] OF CHAR=3D3B =3D
>=3B >=3B BEG= >IN LOCK mu DO IF Unix.gethostname(ADR(hname[0])=3D2C BYTESIZE(hna=3D
>= >=3B >=3Bme)) # 0 THEN IPError.Die ()=3D3B END=3D3B VAR h :=3D3D Unetdb.g= >=3D
>=3B >=3Bethostbyname(ADR(hname[0]))=3D3B BEGIN IF h =3D3D NIL T= >HEN IPError.Die()=3D
>=3B >=3B=3D3B END=3D3B RETURN GetAddress(h)=3D= >3B END=3D3B END=3D3B END GetHos=3D
>=3B >=3BtAddr=3D3B
>=3B >= >=3BPROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Address =3D3D VA= >R ua=3D
>=3B >=3B: Uin.struct_in_addr=3D3B BEGIN <=3B* ASSERT ent.= >h_length <=3B=3D3D BYTESIZE(Addr=3D
>=3B >=3Bess) *>=3B ua :=3D3= >D LOOPHOLE(ent.h_addr_list=3D2C UNTRACED =3D
>=3B >=3BREF UNTRACED R= >EF Uin.struct_in_addr)^^=3D3B RETURN LOOPHOLE(ua.s_addr=3D2C A=3D
>=3B= > >=3Bddress)=3D3B END GetAddress=3D3B
>=3B >=3B=3D20
>=3B >= >=3Bgethostbyname is failing.
>=3B >=3B=3D20
>=3B >=3BAnalogou= >s C code also fails:
>=3B >=3B=3D20
>=3B >=3B[jay at fbsdamd64a = >/cm3/bin]$ cat ~/5.c#include <=3Bassert.h>=3B#include <=3Bnetdb.h>= >=3B#i=3D
>=3B >=3Bnclude <=3Bstdio.h>=3B#include <=3Berrno.h&g= >t=3Btypedef struct hostent hostent_t=3D3B
>=3B >=3B=3D20
>=3B &= >gt=3Bint main(){ char hostname[200]=3D3B hostent_t* h=3D3B int i=3D3B
&g= >t=3B >=3B i =3D3D gethostname(hostname=3D2C 200)=3D3B assert(i =3D3D=3D3D= > 0)=3D3B printf("hostna=3D
>=3B >=3Bme: %s\n"=3D2C hostname)=3D3B h = >=3D3D gethostbyname(hostname)=3D3B herror("foo")=3D3B=3D
>=3B >=3B p= >rintf("%p %d %d\n"=3D2C h=3D2C errno=3D2C h_errno)=3D3B assert(h)=3D3B retu= >rn 0=3D3B}
>=3B >=3B=3D20
>=3B >=3Bherror says "unknown host"= >.
>=3B >=3BStack is:
>=3B >=3B at ../src/runtime/ex_frame/RTE= >xFrame.m3:58#13 0x0000000801a7f2b3 in RTH=3D
>=3B >=3Books__Raise (M= >3_AJWxb1_ex=3D3DError accessing memory address 0x8000ffffd278: =3D
>= >=3B >=3BBad address.) at ../src/runtime/common/RTHooks.m3:79#14 0x0000000= >80169c8=3D
>=3B >=3Bd3 in IPError__Die () at ../src/common/IPError.m= >3:27#15 0x0000000801698a3e =3D
>=3B >=3Bin IP__GetHostAddr (M3_BCxjP= >n__result=3D3DError accessing memory address 0x80=3D
>=3B >=3B00ffff= >d338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x00000008012133d0=3D
&g= >t=3B >=3B in XSharedMem__SameHost (M3_AQuuui_trsl=3D3DError accessing mem= >ory address 0=3D
>=3B >=3Bx8000ffffd4d8: Bad address.) at ../src/xvb= >t/XSharedMem.m3:96#17 0x000000=3D
>=3B >=3B0801212ab7 in XSharedMem_= >_InitXClient (M3_AQuuui_v=3D3DError accessing memory=3D
>=3B >=3B ad= >dress 0x8000ffffd648: Bad address.) at ../src/xvbt/XSharedMem.m3:29#1=3D>>=3B >=3B8 0x0000000801211819 in XExtensions__InitXClient (M3_AQuuui_x= >client=3D3DError=3D
>=3B >=3B accessing memory address 0x8000ffffd7f= >8: Bad address.) at ../src/xvbt/X=3D
>=3B >=3BExtensions.m3:14#19 0x= >00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst=3D
>=3B >=3B= >=3D3D0x1879b=3D2C M3_AQuuui_trsl=3D3D0x6) at ../src/xvbt/XClientF.m3:583---= >Typ=3D
>=3B >=3Be <=3Breturn>=3B to continue=3D2C or q <=3Bret= >urn>=3B to quit---(More stack frames follow=3D
>=3B >=3B...)(gdb)<= >BR>>=3B >=3B(* return TRUE if server and client are on same host *)PROC= >EDURE SameHost (=3D
>=3B >=3Btrsl: XClient.T): BOOLEAN =3D3D VAR dis= >play :=3D3D DisplayH=3D
>=3B >=3Bost(trsl)=3D3B displayAddr: IP.Addr= >ess=3D3B BEGIN IF display =3D3D NIL THE=3D
>=3B >=3BN RETURN TRUE=3D= >3B END=3D3B
>=3B >=3B TRY IF NOT IP.GetHostByName(display=3D2C displ= >ayAddr) THEN RETURN FA=3D
>=3B >=3BLSE=3D3B END=3D3B RETURN displayA= >ddr =3D3D IP.GetHostAddr()=3D3B EXCEPT =3D
>=3B >=3B| IP.Error =3D3D= >>=3B RETURN FALSE=3D3B END=3D3B END SameHost=3D3B
>=3B >=3B=3D20R>>=3B >=3BThoughts?
>=3B >=3B=3D20
>=3B >=3BPerhaps my n= >etwork isn't setup well=3D2C like I should add the local machine =3D
>= >=3B >=3Bto /etc/hosts.I think this can be made to fail gracefully though.= >It seems l=3D
>=3B >=3Bike it has nothing to do with AMD64_FREEBSD= >=3D2C but could have to do with Fr=3D
>=3B >=3BeeBSD.
>=3B >= >=3B=3D20
>=3B >=3BSeems like SocketPosix has nearly the exact same c= >ode but appearsmore forgi=3D
>=3B >=3Bving.. IOError instead of Fata= >l?
>=3B >=3B=3D20
>=3B >=3BSocketPosix.m3:
>=3B >=3B= >=3D20
>=3B >=3BPROCEDURE GetHostAddr (): Address RAISES {OSError.E} = >=3D3D VAR host : AR=3D
>=3B >=3BRAY [0..255] OF CHAR=3D3B info : Une= >tdb.struct_hostent_star=3D3B ua : U=3D
>=3B >=3Bin.struct_in_addr=3D= >3B BEGIN IF Unix.gethostname (ADR (host[0])=3D2C BYTESI=3D
>=3B >=3B= >ZE (host)) # 0 THEN IOError (Unexpected)=3D3B END=3D3B
>=3B >=3B inf= >o :=3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3B IF info =3D3D NIL TH=3D<= >BR>>=3B >=3BEN IOError (Unexpected)=3D3B END=3D3B <=3B* ASSERT info.h= >_length <=3B=3D3D BYTESIZE =3D
>=3B >=3B(Address) *>=3B
>= >=3B >=3B ua :=3D3D LOOPHOLE(info.h_addr_list=3D2C UNTRACED REF UNT=3D
= >>=3B >=3BRACED REF Uin.struct_in_addr)^^=3D3B RETURN LOOPHOLE (ua.s_add= >r=3D2C Address=3D
>=3B >=3B)=3D3B END GetHostAddr=3D3B
>=3B >= >=3B=3D20
>=3B >=3B=3D20
>=3B >=3BIt is again disappointing to= > see such code duplication.
>=3B >=3B=3D20
>=3B >=3B=3D20
= >>=3B >=3BI guess SameHost can duplicate the logic to predict the error = >state and ret=3D
>=3B >=3Burn false upon error?
>=3B >=3BDupl= >icating the logic for a third time. :(
>=3B >=3B=3D20
>=3B >= >=3B - Jay=3D
>=3B >=3B
>=3B >=3B--_9e67232c-a064-417d-879e-22= >7a77e310f9_
>=3B >=3BContent-Type: text/html=3B charset=3D"iso-8859-= >1"
>=3B >=3BContent-Transfer-Encoding: quoted-printable
>=3B &g= >t=3B
>=3B >=3B<=3Bhtml>=3B
>=3B >=3B<=3Bhead>=3B
&= >gt=3B >=3B<=3Bstyle>=3B
>=3B >=3B.hmmessage P
>=3B >=3B= >{
>=3B >=3Bmargin:0px=3D3B
>=3B >=3Bpadding:0px
>=3B >= >=3B}
>=3B >=3Bbody.hmmessage
>=3B >=3B{
>=3B >=3Bfont-= >size: 10pt=3D3B
>=3B >=3Bfont-family:Verdana
>=3B >=3B}
&g= >t=3B >=3B<=3B/style>=3B
>=3B >=3B<=3B/head>=3B
>=3B &= >gt=3B<=3Bbody class=3D3D'hmmessage'>=3B
>=3B >=3BHi. Unix networ= >k programming question..<=3BBR>=3B
>=3B >=3B<=3BBR>=3BAMD64_= >FREEBSD:<=3BBR>=3B
>=3B >=3B<=3BBR>=3B$DISPLAY is set to poi= >nt back to Cygwin host.<=3BBR>=3BIt works for PPC_LINUX=3D
>=3B &g= >t=3B.<=3BBR>=3B
>=3B >=3B<=3BBR>=3B[jay at fbsdamd64a /cm3/bin]= >$ ./Juno<=3BBR>=3B
>=3B >=3B<=3BBR>=3B***<=3BBR>=3B*** r= >untime error:<=3BBR>=3B***&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp= >=3D3B Exception "IPE=3D
>=3B >=3Brror.FatalError" not in RAISES list= ><=3BBR>=3B***&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B file "..= >=3D
>=3B >=3B/src/common/IPError.m3"=3D2C line 27<=3BBR>=3B***&l= >t=3BBR>=3B
>=3B >=3B<=3BBR>=3BAbort trap: 6 (core dumped)<= >=3BBR>=3B[jay at fbsdamd64a /cm3/bin]$<=3BBR>=3B
>=3B >=3B<=3BB= >R>=3BIP.m3:<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B<= >BR>>=3B >=3BPROCEDURE GetHostAddr(): Address =3D3D<=3BBR>=3B&=3B= >nbsp=3D3B VAR hname: ARRAY [0..255] =3D
>=3B OF CHAR=3D3B<=3BBR>= >=3B&=3Bnbsp=3D3B BEGIN<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&= >=3Bnbsp=3D3B LOCK mu DO<=3BBR>=3B&=3Bnbs=3D
>=3B >=3Bp=3D3B&a= >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B IF Unix.geth= >ostname(ADR(hname[0])=3D2C B=3D
>=3B >=3BYTESIZE(hname)) # 0 THEN<= >=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B= >&=3Bnbsp=3D3B&=3Bnbsp=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B IPErro= >r.Die ()=3D3B<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B= >&=3Bnbsp=3D3B&=3Bnbsp=3D3B E=3D
>=3B >=3BND=3D3B<=3BBR>=3B= >&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp= >=3D3B VAR h :=3D3D Unetdb.gethost=3D
>=3B >=3Bbyname(ADR(hname[0]))= >=3D3B BEGIN<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&a= >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3B=3D
>=3B >=3Bnbsp=3D3B&=3Bnb= >sp=3D3B IF h =3D3D NIL THEN IPError.Die()=3D3B END=3D3B<=3BBR>=3B&= >=3Bnbsp=3D3B&=3Bnbsp=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B&=3Bnbsp= >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B RETURN GetAddress(h)= >=3D3B<=3BBR>=3B&=3Bnbs=3D
>=3B >=3Bp=3D3B&=3Bnbsp=3D3B&= >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B END=3D3B<=3BBR>=3B&=3Bn= >bsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B END=3D
>=3B >=3B=3D3B<=3B= >BR>=3B&=3Bnbsp=3D3B END GetHostAddr=3D3B<=3BBR>=3B
>=3B >= >=3B<=3BBR>=3BPROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Ad= >dress =3D3D<=3BBR>=3B=3D
>=3B >=3B&=3Bnbsp=3D3B VAR ua: Uin.s= >truct_in_addr=3D3B<=3BBR>=3B&=3Bnbsp=3D3B BEGIN<=3BBR>=3B&=3B= >nbsp=3D3B&=3Bnbsp=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B &=3Blt=3D3= >B* ASSERT ent.h_length &=3Blt=3D3B=3D3D BYTESIZE(Address) *&=3Bgt=3D3= >B=3D
>=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bn= >bsp=3D3B ua :=3D3D LOOPHOLE(ent.h_addr_list=3D2C<=3BBR>=3B&=3Bnbsp= >=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&a= >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp= >=3D3B&=3Bnbsp=3D3B=3D
>=3B >=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&a= >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp= >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B UN=3D
>=3B >=3BTRACED REF UNTR= ACED REF Uin.struct_in_addr)^^=3D3B<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbs= >p=3D3B&=3Bnbsp=3D
>=3B >=3B=3D3B RETURN LOOPHOLE(ua.s_addr=3D2C A= >ddress)=3D3B<=3BBR>=3B&=3Bnbsp=3D3B END GetAddress=3D3B<=3B=3D
= >>=3B >=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>= >=3B >=3Bgethostbyname is failing.<=3BBR>=3B
>=3B >=3B<=3BBR&= >gt=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BAnalogous C code also f= >ails:<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>= >=3B >=3B<=3BBR>=3B[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c<=3BBR>=3B#= >include &=3Blt=3D3Bassert.h&=3Bgt=3D3B<=3BB=3D
>=3B >=3BR>= >=3B#include &=3Blt=3D3Bnetdb.h&=3Bgt=3D3B<=3BBR>=3B#include &= >=3Blt=3D3Bstdio.h&=3Bgt=3D3B<=3BBR>=3B#include =3D
>=3B >=3B&= >amp=3Blt=3D3Berrno.h&=3Bgt=3D3B<=3BBR>=3Btypedef struct hostent host= >ent_t=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
= >>=3B >=3Bint main()<=3BBR>=3B{<=3BBR>=3B&=3Bnbsp=3D3Bchar ho= >stname[200]=3D3B<=3BBR>=3B&=3Bnbsp=3D3Bhostent_t* h=3D3B=3D
>= >=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3Bint i=3D3B<=3BBR>=3B
>=3B = >>=3B&=3Bnbsp=3D3Bi =3D3D gethostname(hostname=3D2C 200)=3D3B<=3BBR&g= >t=3B&=3Bnbsp=3D3Bassert(i =3D3D=3D3D 0)=3D
>=3B >=3B=3D3B<=3BBR= >>=3B&=3Bnbsp=3D3Bprintf("hostname: %s\n"=3D2C hostname)=3D3B<=3BBR&g= >t=3B&=3Bnbsp=3D3Bh =3D3D get=3D
>=3B >=3Bhostbyname(hostname)=3D3= >B<=3BBR>=3B&=3Bnbsp=3D3Bherror("foo")=3D3B<=3BBR>=3B&=3Bnbsp= >=3D3Bprintf("%p %=3D
>=3B >=3Bd %d\n"=3D2C h=3D2C errno=3D2C h_errno= >)=3D3B<=3BBR>=3B&=3Bnbsp=3D3Bassert(h)=3D3B<=3BBR>=3B&=3Bnbsp= >=3D3Bret=3D
>=3B >=3Burn 0=3D3B<=3BBR>=3B}<=3BBR>=3B
>= >=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3Bherror says "unkno= >wn host".<=3BBR>=3B
>=3B >=3B<=3BBR>=3BStack is:<=3BBR>= >=3B
>=3B >=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B at ../= >src/runtime/ex_frame/RTExFrame.m3:58<=3BBR>=3B#13 =3D
>=3B >=3B0= >x0000000801a7f2b3 in RTHooks__Raise (M3_AJWxb1_ex=3D3DError accessing memor= >y=3D
>=3B >=3B ad<=3BBR>=3Bdress 0x8000ffffd278: Bad address.<= >=3BBR>=3B)<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B = >=3D
>=3B >=3Bat ../src/runtime/common/RTHooks.m3:79<=3BBR>=3B#14= > 0x000000080169c8d3 in IPError=3D
>=3B >=3B__Die () at ../src/common= >/IPError.m3:27<=3BBR>=3B#15 0x0000000801698a3e in IP__Ge=3D
>=3B &= >gt=3BtHostAddr (M3_BCxjPn__result=3D3DError accessing mem<=3BBR>=3Bory = >address 0x8000fff=3D
>=3B >=3Bfd338: Bad address.<=3BBR>=3B)<= >=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B at ../src/POSIX= >/IP.m3:=3D
>=3B >=3B82<=3BBR>=3B#16 0x00000008012133d0 in XShare= >dMem__SameHost (M3_AQuuui_trsl=3D3DErro=3D
>=3B >=3Br accessing m<= >=3BBR>=3Bemory address 0x8000ffffd4d8: Bad address.<=3BBR>=3B)<=3BB= >R>=3B&=3Bnbsp=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B= > at ../src/xvbt/XSharedMem.m3:96<=3BBR>=3B#17 0x0000000801212a=3D
&g= >t=3B >=3Bb7 in XSharedMem__InitXClient (M3_AQuuui_v=3D3DError accessing m= ><=3BBR>=3Bemory add=3D
>=3B >=3Bress 0x8000ffffd648: Bad address= >.<=3BBR>=3B)<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp= >=3D3B at ../sr=3D
>=3B >=3Bc/xvbt/XSharedMem.m3:29<=3BBR>=3B#18 = >0x0000000801211819 in XExtensions__InitXClie=3D
>=3B >=3Bnt (M3_AQuu= >ui_xclient=3D3DError acce<=3BBR>=3Bssing memory address 0x8000ffffd7f8:= > =3D
>=3B >=3BBad address.<=3BBR>=3B)<=3BBR>=3B&=3Bnbsp= >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B at ../src/xvbt/XExtensions.m3=3D
&= >gt=3B >=3B:14<=3BBR>=3B#19 0x00000008012467a4 in XClientF__Connect (M= >3_Bd56fi_inst=3D3D0x1879=3D
>=3B >=3Bb=3D2C<=3BBR>=3B&=3Bnbsp= >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B M3_AQuuui_trsl=3D3D0x6) at ../src/xvb= >t/XClie=3D
>=3B >=3BntF.m3:583<=3BBR>=3B---Type &=3Blt=3D3Bre= >turn&=3Bgt=3D3B to continue=3D2C or q &=3Blt=3D3Breturn&=3Bg=3D>>=3B >=3Bt=3D3B to quit---<=3BBR>=3B(More stack frames follow...)&= >lt=3BBR>=3B(gdb)<=3BBR>=3B
>=3B >=3B<=3BBR>=3B(* return TR= >UE if server and client are on same host *)<=3BBR>=3BPROCEDURE Sa=3D>>=3B >=3BmeHost (trsl: XClient.T): BOOLEAN =3D3D<=3BBR>=3B&=3Bn= >bsp=3D3B VAR<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bn=3D
&g= >t=3B >=3Bbsp=3D3B display&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B= >&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp= >=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&a= >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp= >=3D3B :=3D3D Di=3D
>=3B >=3BsplayHost(trsl)=3D3B<=3BBR>=3B&= >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B displayAddr: IP.Address=3D3B&l= >t=3BB=3D
>=3B >=3BR>=3B&=3Bnbsp=3D3B BEGIN<=3BBR>=3B&=3B= >nbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B IF display =3D3D NIL THEN RETURN= >=3D
>=3B >=3B TRUE=3D3B END=3D3B<=3BBR>=3B
>=3B >=3B&= >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B TRY<=3BBR>=3B&=3Bnbsp= >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B IF=3D= >
>=3B >=3B NOT IP.GetHostByName(display=3D2C displayAddr) THEN RETUR= >N FALSE=3D3B END=3D3B<=3BB=3D
>=3B >=3BR>=3B&=3Bnbsp=3D3B&= >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B RETURN display= >Addr =3D3D IP.GetHos=3D
>=3B >=3BtAddr()=3D3B<=3BBR>=3B&=3Bnb= >sp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B EXCEPT<=3BBR>=3B&=3Bnbsp=3D3= >B&=3Bnbsp=3D3B&=3Bnbsp=3D3B |=3D
>=3B >=3B IP.Error =3D3D&= >=3Bgt=3D3B RETURN FALSE=3D3B<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&= >amp=3Bnbsp=3D3B END=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bnbsp=3D3B = >END SameHost=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>= >=3B
>=3B >=3BThoughts?<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3= >B<=3BBR>=3B
>=3B >=3B<=3BBR>=3BPerhaps my network isn't setu= >p well=3D2C like I should add the local mach=3D
>=3B >=3Bine to /etc= >/hosts.<=3BBR>=3BI think this can be made to fail gracefully though.<= >=3BB=3D
>=3B >=3BR>=3BIt seems like it has nothing to do with AMD6= >4_FREEBSD=3D2C but could have t=3D
>=3B >=3Bo do with FreeBSD.<=3B= >BR>=3B
>=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B
&g= >t=3B >=3BSeems like SocketPosix has nearly the exact same code but appear= >s<=3BBR>=3Bmore f=3D
>=3B >=3Borgiving.. IOError instead of Fata= >l?<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B &= >gt=3B<=3BBR>=3BSocketPosix.m3:<=3BBR>=3B
>=3B >=3B&=3Bnbs= >p=3D3B<=3BBR>=3B
>=3B >=3B<=3BBR>=3BPROCEDURE GetHostAddr ()= >: Address<=3BBR>=3B&=3Bnbsp=3D3B RAISES {OSError.E} =3D3D<=3BBR=3D= >
>=3B >=3B>=3B&=3Bnbsp=3D3B VAR<=3BBR>=3B&=3Bnbsp=3D3B&a= >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B host : ARRAY [0..255] OF CHAR=3D3B<=3B=3D<= >BR>>=3B >=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B in= >fo : Unetdb.struct_hostent_star=3D3B<=3BBR>=3B&=3Bnbsp=3D
>=3B = >>=3B=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B ua&=3Bnbsp=3D3B&=3Bnbsp= >=3D3B : Uin.struct_in_addr=3D3B<=3BBR>=3B&=3Bnbsp=3D3B =3D
>=3B= > >=3BBEGIN<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B = >IF Unix.gethostname (ADR (host[0])=3D2C BYT=3D
>=3B >=3BESIZE (host)= >) # 0 THEN<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&am= >p=3Bnbsp=3D3B&=3Bnbsp=3D3B IOError =3D
>=3B >=3B(Unexpected)=3D3B= ><=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B END=3D3B<= >=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3= >B info :=3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3B<=3B=3D
>=3B = >>=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B IF info =3D3= >D NIL THEN IOError (Unexpected)=3D3B EN=3D
>=3B >=3BD=3D3B<=3BBR&g= >t=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B &=3Blt=3D3B* ASSERT= > info.h_length &=3Blt=3D3B=3D3D BYT=3D
>=3B >=3BESIZE (Address) *= >&=3Bgt=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B&=3Bnbsp=3D= >3B&=3Bnbsp=3D3B ua :=3D3D LOOPHOLE(info.h_addr_list=3D2C<=3BBR>=3B&a= >mp=3Bnbsp=3D3B&=3Bn=3D
>=3B >=3Bbsp=3D3B&=3Bnbsp=3D3B&=3Bnb= >sp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&= >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D
>=3B >=3B=3D3B&=3Bnbsp= >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&= >=3Bnbsp=3D3B&=3Bnbsp=3D3B UNTRACED REF UN=3D
>=3B >=3BTRACED REF = >Uin.struct_in_addr)^^=3D3B<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&am= >p=3Bnbsp=3D3B RETURN LOOP=3D
>=3B >=3BHOLE (ua.s_addr=3D2C Address)= >=3D3B<=3BBR>=3B&=3Bnbsp=3D3B END GetHostAddr=3D3B<=3BBR>=3B
&= >gt=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B= ><=3BBR>=3B
>=3B >=3BIt is again disappointing to see such code d= >uplication.<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BI guess&=3B= >nbsp=3D3BSameHost can duplicate the logic to predict the error state =3D>>=3B >=3Band return false&=3Bnbsp=3D3Bupon error?<=3BBR>=3B
= >>=3B >=3BDuplicating the logic for a third time. :(<=3BBR>=3B
&g= >t=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B<=3BBR>=3B&am= >p=3Bnbsp=3D3B- Jay<=3BBR>=3B<=3BBR>=3B<=3B/body>=3B
>=3B &= >gt=3B<=3B/html>=3B=3D
>=3B >=3B
>=3B >=3B--_9e67232c-a064= >-417d-879e-227a77e310f9_--

>= > >--_b00371fe-730b-4981-9051-a874361296d7_-- From jay.krell at cornell.edu Mon Jan 12 10:12:44 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 09:12:44 +0000 Subject: [M3devel] Juno (X) networking problem on AMD64_FREEBSD In-Reply-To: <200901120906.n0C96Uwn074046@camembert.async.caltech.edu> References: Your message of "Sun, 11 Jan 2009 22:02:18 GMT." <200901120906.n0C96Uwn074046@camembert.async.caltech.edu> Message-ID: PPC_LINUX not PPC_DARWIN. I think. And at one point AMD64_LINUX (same machine as AMD64_FREEBSD, multiboot).I think I tested I386_OPENBSD Juno too and it worked,I don't remember. Oh, but that was in a VM, so different networking setup. This is Trestle startup, seeing if there mightbe shared memory available between the X client and server. If $DISPLAY is set, to specify the server, it wants to comparethat against "current", the client.You know, if I set DISPLAY=:0.0 or localhost:0.0, don't penalize perf,but if it really is remote, then do penalize perf. /Something/ like that. I hardly read the code.. - Jay> To: jay.krell at cornell.edu> Date: Mon, 12 Jan 2009 01:06:30 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Juno (X) networking problem on AMD64_FREEBSD> > Jay,> > I think the problem here is actually in the caller. Why does a> caller need "GetHostAddr()"? It is probably doing this for the> purpose of calling listen() or some such thing. What the caller> probably *really* wants is INADDR_ANY, and not the IP address of> some arbitrarily chosen interface on the host.> > I'm guessing it works on the Mac because the Mac libraries do> something complicated when you ask for the host's name (i.e., they> somehow generate a hostname that always maps to the IP address of> an interface on the computer).> > Mika> > Jay writes:> >--_b00371fe-730b-4981-9051-a874361296d7_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >Do you know the right way?> >=20> >PPC_LINUX "just worked"=2C and I can check Solaris and Darwin.> >=20> >I don't want to edit /etc/hosts -- I use DHCP.> >Though DHCP has been bothering me -- only for some of my machines do names => >resolve=2C so I end using IP addresses=2C which change sometimes=2C and I l=> >oop over them running ssh to all of them and "see what I get"=2C not ideal.> >=20> > - Jay> To: jay.krell at cornell.edu> Date: Sun=2C 11 Jan 2009 08:02:18 -0800>=> > From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3d=> >evel] Juno (X) networking problem on AMD64_FREEBSD> > This is a screwy thin=> >g in Modula-3. A bug I would call it.> > I've noticed a lot of networking M=> >3 programs don't work right unless> the return value of Unix's "hostname" m=> >aps to a real IP address via> gethostbyname. I accomplish it in practice by=> > adding my hostname> to /etc/hosts.> > This is obviously not the right way => >to fix it... > > Mika> > Jay writes:> >--_9e67232c-a064-417d-879e-227a77e31=> >0f9_> >Content-Type: text/plain=3B charset=3D"iso-8859-1"> >Content-Transfe=> >r-Encoding: quoted-printable> >> >> >Hi. Unix network programming question.=> >.> >AMD64_FREEBSD:> >$DISPLAY is set to point back to Cygwin host.It works => >for PPC_LINUX.> >[jay at fbsdamd64a /cm3/bin]$ ./Juno> >****** runtime error:*=> >** Exception "IPError.FatalError" not in RAISES li=3D> >st*** file "../src/=> >common/IPError.m3"=3D2C line 27***> >Abort trap: 6 (core dumped)[jay at fbsdam=> >d64a /cm3/bin]$> >IP.m3:> >=3D20> >PROCEDURE GetHostAddr(): Address =3D3D V=> >AR hname: ARRAY [0..255] OF CHAR=3D3B =3D> > BEGIN LOCK mu DO IF Unix.getho=> >stname(ADR(hname[0])=3D2C BYTESIZE(hna=3D> >me)) # 0 THEN IPError.Die ()=3D=> >3B END=3D3B VAR h :=3D3D Unetdb.g=3D> >ethostbyname(ADR(hname[0]))=3D3B BEG=> >IN IF h =3D3D NIL THEN IPError.Die()=3D> >=3D3B END=3D3B RETURN GetAddress(=> >h)=3D3B END=3D3B END=3D3B END GetHos=3D> >tAddr=3D3B> >PROCEDURE GetAddress=> > (ent: Unetdb.struct_hostent_star): Address =3D3D VAR ua=3D> >: Uin.struct_=> >in_addr=3D3B BEGIN <* ASSERT ent.h_length <=3D3D BYTESIZE(Addr=3D> >ess) *>=> > ua :=3D3D LOOPHOLE(ent.h_addr_list=3D2C UNTRACED =3D> >REF UNTRACED REF Ui=> >n.struct_in_addr)^^=3D3B RETURN LOOPHOLE(ua.s_addr=3D2C A=3D> >ddress)=3D3B=> > END GetAddress=3D3B> >=3D20> >gethostbyname is failing.> >=3D20> >Analogou=> >s C code also fails:> >=3D20> >[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c#include=> > #include #i=3D> >nclude #include type=> >def struct hostent hostent_t=3D3B> >=3D20> >int main(){ char hostname[200]=> >=3D3B hostent_t* h=3D3B int i=3D3B> > i =3D3D gethostname(hostname=3D2C 200=> >)=3D3B assert(i =3D3D=3D3D 0)=3D3B printf("hostna=3D> >me: %s\n"=3D2C hostn=> >ame)=3D3B h =3D3D gethostbyname(hostname)=3D3B herror("foo")=3D3B=3D> > pri=> >ntf("%p %d %d\n"=3D2C h=3D2C errno=3D2C h_errno)=3D3B assert(h)=3D3B return=> > 0=3D3B}> >=3D20> >herror says "unknown host".> >Stack is:> > at ../src/run=> >time/ex_frame/RTExFrame.m3:58#13 0x0000000801a7f2b3 in RTH=3D> >ooks__Raise=> > (M3_AJWxb1_ex=3D3DError accessing memory address 0x8000ffffd278: =3D> >Bad=> > address.) at ../src/runtime/common/RTHooks.m3:79#14 0x000000080169c8=3D> >=> >d3 in IPError__Die () at ../src/common/IPError.m3:27#15 0x0000000801698a3e => >=3D> >in IP__GetHostAddr (M3_BCxjPn__result=3D3DError accessing memory addr=> >ess 0x80=3D> >00ffffd338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x00000=> >008012133d0=3D> > in XSharedMem__SameHost (M3_AQuuui_trsl=3D3DError accessi=> >ng memory address 0=3D> >x8000ffffd4d8: Bad address.) at ../src/xvbt/XShare=> >dMem.m3:96#17 0x000000=3D> >0801212ab7 in XSharedMem__InitXClient (M3_AQuuu=> >i_v=3D3DError accessing memory=3D> > address 0x8000ffffd648: Bad address.) => >at ../src/xvbt/XSharedMem.m3:29#1=3D> >8 0x0000000801211819 in XExtensions_=> >_InitXClient (M3_AQuuui_xclient=3D3DError=3D> > accessing memory address 0x=> >8000ffffd7f8: Bad address.) at ../src/xvbt/X=3D> >Extensions.m3:14#19 0x000=> >00008012467a4 in XClientF__Connect (M3_Bd56fi_inst=3D> >=3D3D0x1879b=3D2C M=> >3_AQuuui_trsl=3D3D0x6) at ../src/xvbt/XClientF.m3:583---Typ=3D> >e => > to continue=3D2C or q to quit---(More stack frames follow=3D> >..=> >.)(gdb)> >(* return TRUE if server and client are on same host *)PROCEDURE => >SameHost (=3D> >trsl: XClient.T): BOOLEAN =3D3D VAR display :=3D3D DisplayH=> >=3D> >ost(trsl)=3D3B displayAddr: IP.Address=3D3B BEGIN IF display =3D3D NI=> >L THE=3D> >N RETURN TRUE=3D3B END=3D3B> > TRY IF NOT IP.GetHostByName(displ=> >ay=3D2C displayAddr) THEN RETURN FA=3D> >LSE=3D3B END=3D3B RETURN displayAd=> >dr =3D3D IP.GetHostAddr()=3D3B EXCEPT =3D> >| IP.Error =3D3D> RETURN FALSE=> >=3D3B END=3D3B END SameHost=3D3B> >=3D20> >Thoughts?> >=3D20> >Perhaps my n=> >etwork isn't setup well=3D2C like I should add the local machine =3D> >to /=> >etc/hosts.I think this can be made to fail gracefully though.It seems l=3D>=> > >ike it has nothing to do with AMD64_FREEBSD=3D2C but could have to do wit=> >h Fr=3D> >eeBSD.> >=3D20> >Seems like SocketPosix has nearly the exact same=> > code but appearsmore forgi=3D> >ving.. IOError instead of Fatal?> >=3D20> => >>SocketPosix.m3:> >=3D20> >PROCEDURE GetHostAddr (): Address RAISES {OSErro=> >r.E} =3D3D VAR host : AR=3D> >RAY [0..255] OF CHAR=3D3B info : Unetdb.struc=> >t_hostent_star=3D3B ua : U=3D> >in.struct_in_addr=3D3B BEGIN IF Unix.gethos=> >tname (ADR (host[0])=3D2C BYTESI=3D> >ZE (host)) # 0 THEN IOError (Unexpect=> >ed)=3D3B END=3D3B> > info :=3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3B => >IF info =3D3D NIL TH=3D> >EN IOError (Unexpected)=3D3B END=3D3B <* ASSERT i=> >nfo.h_length <=3D3D BYTESIZE =3D> >(Address) *>> > ua :=3D3D LOOPHOLE(info.=> >h_addr_list=3D2C UNTRACED REF UNT=3D> >RACED REF Uin.struct_in_addr)^^=3D3B=> > RETURN LOOPHOLE (ua.s_addr=3D2C Address=3D> >)=3D3B END GetHostAddr=3D3B> => >>=3D20> >=3D20> >It is again disappointing to see such code duplication.> >=> >=3D20> >=3D20> >I guess SameHost can duplicate the logic to predict the err=> >or state and ret=3D> >urn false upon error?> >Duplicating the logic for a t=> >hird time. :(> >=3D20> > - Jay=3D> >> >--_9e67232c-a064-417d-879e-227a77e31=> >0f9_> >Content-Type: text/html=3B charset=3D"iso-8859-1"> >Content-Transfer=> >-Encoding: quoted-printable> >> >> >> >> >> > >mmessage'>> >Hi. Unix network programming question..
> >
AMD64_FREEBS=> >D:
> >
$DISPLAY is set to point back to Cygwin host.
It works for => >PPC_LINUX=3D> >.
> >
[jay at fbsdamd64a /cm3/bin]$ ./Juno
> >
***<=> >BR>*** runtime error:
*** =3D3B =3D3B =3D3B Exception "IPE=> >=3D> >rror.FatalError" not in RAISES list
*** =3D3B =3D3B => >=3D3B file "..=3D> >/src/common/IPError.m3"=3D2C line 27
***
> >
A=> >bort trap: 6 (core dumped)
[jay at fbsdamd64a /cm3/bin]$
> >
IP.m3: >R>> > =3D3B
> >PROCEDURE GetHostAddr(): Address =3D3D
 =3D3B => >VAR hname: ARRAY [0..255] =3D> OF CHAR=3D3B
 =3D3B BEGIN
 =3D=> >3B =3D3B =3D3B LOCK mu DO
&nbs=3D> >p=3D3B =3D3B =3D3B&n=> >bsp=3D3B =3D3B IF Unix.gethostname(ADR(hname[0])=3D2C B=3D> >YTESIZE(hn=> >ame)) # 0 THEN
 =3D3B =3D3B =3D3B =3D3B =3D3B => >=3D> >=3D3B =3D3B IPError.Die ()=3D3B
 =3D3B =3D3B =3D3B=> > =3D3B =3D3B E=3D> >ND=3D3B
 =3D3B =3D3B =3D3B => >=3D3B =3D3B VAR h :=3D3D Unetdb.gethost=3D> >byname(ADR(hname[0]))=3D3B=> > BEGIN
 =3D3B =3D3B =3D3B =3D3B =3D3B&=3D> >nbsp=3D3=> >B =3D3B IF h =3D3D NIL THEN IPError.Die()=3D3B END=3D3B
 =3D3B&n=> >bsp=3D> >=3D3B =3D3B =3D3B =3D3B =3D3B =3D3B RETURN Get=> >Address(h)=3D3B
&nbs=3D> >p=3D3B =3D3B =3D3B =3D3B =3D3B=> > END=3D3B
 =3D3B =3D3B =3D3B END=3D> >=3D3B
 =3D3B EN=> >D GetHostAddr=3D3B
> >
PROCEDURE GetAddress (ent: Unetdb.struct_hoste=> >nt_star): Address =3D3D
=3D> > =3D3B VAR ua: Uin.struct_in_addr=3D3B=> >
 =3D3B BEGIN
 =3D3B =3D> >=3D3B =3D3B <=3D3B* ASSE=> >RT ent.h_length <=3D3B=3D3D BYTESIZE(Address) *>=3D3B=3D> >
 =3D=> >3B =3D3B =3D3B ua :=3D3D LOOPHOLE(ent.h_addr_list=3D2C
 =3D>=> > >=3D3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D=> >3B =3D3B =3D3B=3D> > =3D3B =3D3B =3D3B =3D3B => >=3D3B =3D3B =3D3B =3D3B =3D3B UN=3D> >TRACED REF UNTRACED R=> >EF Uin.struct_in_addr)^^=3D3B
 =3D3B =3D3B =3D> >=3D3B RETUR=> >N LOOPHOLE(ua.s_addr=3D2C Address)=3D3B
 =3D3B END GetAddress=3D3B<=> >=3D> >BR>> > =3D3B
> >gethostbyname is failing.
> >
 =3D3B=> >
> >Analogous C code also fails:
> > =3D3B
> >
[jay at fbsdamd=> >64a /cm3/bin]$ cat ~/5.c
#include <=3D3Bassert.h>=3D3B >R>#inc=> >lude <=3D3Bnetdb.h>=3D3B
#include <=3D3Bstdio.h>=3D3B
#includ=> >e =3D> ><=3D3Berrno.h>=3D3B
typedef struct hostent hostent_t=3D3B >>> > =3D3B
> >int main()
{
 =3D3Bchar hostname[200]=3D3B >R> =3D3Bhostent_t* h=3D3B=3D> >
 =3D3Bint i=3D3B
> > =3D3=> >Bi =3D3D gethostname(hostname=3D2C 200)=3D3B
 =3D3Bassert(i =3D3D=3D=> >3D 0)=3D> >=3D3B
 =3D3Bprintf("hostname: %s\n"=3D2C hostname)=3D3B >R> =3D3Bh =3D3D get=3D> >hostbyname(hostname)=3D3B
 =3D3Bherror(=> >"foo")=3D3B
 =3D3Bprintf("%p %=3D> >d %d\n"=3D2C h=3D2C errno=3D2C h=> >_errno)=3D3B
 =3D3Bassert(h)=3D3B
 =3D3Bret=3D> >urn 0=3D3B >R>}
> > =3D3B
> >herror says "unknown host".
> >
Stack is:<=> >BR>> > =3D3B =3D3B =3D3B at ../src/runtime/ex_frame/RTExFrame.m=> >3:58
#13 =3D> >0x0000000801a7f2b3 in RTHooks__Raise (M3_AJWxb1_ex=3D3DEr=> >ror accessing memory=3D> > ad
dress 0x8000ffffd278: Bad address.
) >> =3D3B =3D3B =3D3B =3D> >at ../src/runtime/common/RTHooks.m3:7=> >9
#14 0x000000080169c8d3 in IPError=3D> >__Die () at ../src/common/IPErr=> >or.m3:27
#15 0x0000000801698a3e in IP__Ge=3D> >tHostAddr (M3_BCxjPn__res=> ult=3D3DError accessing mem
ory address 0x8000fff=3D> >fd338: Bad addres=> >s.
)
 =3D3B =3D3B =3D3B at ../src/POSIX/IP.m3:=3D> >82 >>#16 0x00000008012133d0 in XSharedMem__SameHost (M3_AQuuui_trsl=3D3DErro=3D=> >> >r accessing m
emory address 0x8000ffffd4d8: Bad address.
)
&nbs=> >p=3D> >=3D3B =3D3B =3D3B at ../src/xvbt/XSharedMem.m3:96
#17 0x0=> >000000801212a=3D> >b7 in XSharedMem__InitXClient (M3_AQuuui_v=3D3DError acc=> >essing m
emory add=3D> >ress 0x8000ffffd648: Bad address.
)
 => >=3D3B =3D3B =3D3B at ../sr=3D> >c/xvbt/XSharedMem.m3:29
#18 0x00=> >00000801211819 in XExtensions__InitXClie=3D> >nt (M3_AQuuui_xclient=3D3DErr=> >or acce
ssing memory address 0x8000ffffd7f8: =3D> >Bad address.
)
=> > =3D3B =3D3B =3D3B at ../src/xvbt/XExtensions.m3=3D> >:14
#1=> >9 0x00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst=3D3D0x1879=3D> >b=> >=3D2C
 =3D3B =3D3B =3D3B M3_AQuuui_trsl=3D3D0x6) at ../src/x=> >vbt/XClie=3D> >ntF.m3:583
---Type <=3D3Breturn>=3D3B to continue=3D2=> >C or q <=3D3Breturn&g=3D> >t=3D3B to quit---
(More stack frames follow=> >...)
(gdb)
> >
(* return TRUE if server and client are on same hos=> >t *)
PROCEDURE Sa=3D> >meHost (trsl: XClient.T): BOOLEAN =3D3D
 => >=3D3B VAR
 =3D3B =3D3B&n=3D> >bsp=3D3B display =3D3B =3D=> >3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D> >=3D3B => >=3D3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D3B=> :=3D3D Di=3D> >splayHost(trsl)=3D3B
 =3D3B =3D3B =3D3B disp=> >layAddr: IP.Address=3D3B >R> =3D3B BEGIN
 =3D3B =3D3B&=> >nbsp=3D3B IF display =3D3D NIL THEN RETURN=3D> > TRUE=3D3B END=3D3B
> >&=> >nbsp=3D3B =3D3B =3D3B TRY
 =3D3B =3D3B =3D3B =3D=> >3B =3D3B IF=3D> > NOT IP.GetHostByName(display=3D2C displayAddr) THEN R=> >ETURN FALSE=3D3B END=3D3B >R> =3D3B =3D3B =3D3B =3D3B=> > =3D3B RETURN displayAddr =3D3D IP.GetHos=3D> >tAddr()=3D3B
 =3D=> >3B =3D3B =3D3B EXCEPT
 =3D3B =3D3B =3D3B |=3D> > IP.=> >Error =3D3D>=3D3B RETURN FALSE=3D3B
 =3D3B =3D3B =3D3B END=> >=3D3B
&=3D> >nbsp=3D3B END SameHost=3D3B
> > =3D3B
> >Thoughts=> >?
> > =3D3B
> >
Perhaps my network isn't setup well=3D2C like => >I should add the local mach=3D> >ine to /etc/hosts.
I think this can be => >made to fail gracefully though. >R>It seems like it has nothing to do=> > with AMD64_FREEBSD=3D2C but could have t=3D> >o do with FreeBSD.
> > >> =3D3B
> >Seems like SocketPosix has nearly the exact same code but=> > appears
more f=3D> >orgiving.. IOError instead of Fatal?
> > =3D=> >3B
> >
SocketPosix.m3:
> > =3D3B
> >
PROCEDURE GetHostAd=> >dr (): Address
 =3D3B RAISES {OSError.E} =3D3D >> =3D3B V=> >AR
 =3D3B =3D3B =3D3B host : ARRAY [0..255] OF CHAR=3D3B<=3D=> >> >BR> =3D3B =3D3B =3D3B info : Unetdb.struct_hostent_star=3D3B=> >
 =3D> >=3D3B =3D3B =3D3B ua =3D3B =3D3B : Uin.struc=> >t_in_addr=3D3B
 =3D3B =3D> >BEGIN
 =3D3B =3D3B =3D3B => >IF Unix.gethostname (ADR (host[0])=3D2C BYT=3D> >ESIZE (host)) # 0 THEN
=> > =3D3B =3D3B =3D3B =3D3B =3D3B IOError =3D> >(Unexpecte=> >d)=3D3B
 =3D3B =3D3B =3D3B END=3D3B
> > =3D3B =3D=> >3B =3D3B info :=3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3B<=3D> >BR=> >> =3D3B =3D3B =3D3B IF info =3D3D NIL THEN IOError (Unexpected)=> >=3D3B EN=3D> >D=3D3B
 =3D3B =3D3B =3D3B <=3D3B* ASSERT inf=> >o.h_length <=3D3B=3D3D BYT=3D> >ESIZE (Address) *>=3D3B
> > =3D3=> >B =3D3B =3D3B ua :=3D3D LOOPHOLE(info.h_addr_list=3D2C
 =3D3=> >B&n=3D> >bsp=3D3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D=> >3B =3D3B =3D3B =3D> >=3D3B =3D3B =3D3B =3D3B => >=3D3B =3D3B =3D3B =3D3B UNTRACED REF UN=3D> >TRACED REF Uin.str=> >uct_in_addr)^^=3D3B
 =3D3B =3D3B =3D3B RETURN LOOP=3D> >HOLE=> > (ua.s_addr=3D2C Address)=3D3B
 =3D3B END GetHostAddr=3D3B
> >&nb=> >sp=3D3B
> > =3D3B
> >It is again disappointing to see such code d=> >uplication.
> > =3D3B
> > =3D3B
> >I guess =3D3BSameHo=> >st can duplicate the logic to predict the error state =3D> >and return fals=> >e =3D3Bupon error?
> >Duplicating the logic for a third time. :(
=> >> > =3D3B
> >
 =3D3B- Jay

> >=3D> >> >--=> >_9e67232c-a064-417d-879e-227a77e310f9_--=> >> >--_b00371fe-730b-4981-9051-a874361296d7_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >> >Do you know the right way?
> > =3B
> >PPC_LINUX "just worked"=2C and I can check Solaris and Darwin.
> > =3B
> >I don't want to edit /etc/hosts -- I use DHCP.
> >Though DHCP has been bothering me -- only for some of my machines do names => >resolve=2C so I end using IP addresses=2C which change sometimes=2C and I l=> >oop over them running ssh to all of them and "see what I get"=2C not ideal.=> >
> > =3B
> > =3B- Jay


>=3B To: jay.krell at cornell.edu
>=3B Date: S=> >un=2C 11 Jan 2009 08:02:18 -0800
>=3B From: mika at async.caltech.edu
=> >>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] Juno (X) => >networking problem on AMD64_FREEBSD
>=3B
>=3B This is a screwy t=> >hing in Modula-3. A bug I would call it.
>=3B
>=3B I've noticed => >a lot of networking M3 programs don't work right unless
>=3B the retur=> >n value of Unix's "hostname" maps to a real IP address via
>=3B gethos=> >tbyname. I accomplish it in practice by adding my hostname
>=3B to /et=> >c/hosts.
>=3B
>=3B This is obviously not the right way to fix it=> >...
>=3B
>=3B Mika
>=3B
>=3B Jay writes:
>=3B &=> >gt=3B--_9e67232c-a064-417d-879e-227a77e310f9_
>=3B >=3BContent-Type:=> > text/plain=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Enco=> >ding: quoted-printable
>=3B >=3B
>=3B >=3B
>=3B >=3BHi=> >. Unix network programming question..
>=3B >=3BAMD64_FREEBSD:
>=> >=3B >=3B$DISPLAY is set to point back to Cygwin host.It works for PPC_LIN=> >UX.
>=3B >=3B[jay at fbsdamd64a /cm3/bin]$ ./Juno
>=3B >=3B*****=> >* runtime error:*** Exception "IPError.FatalError" not in RAISES li=3D
&=> >gt=3B >=3Bst*** file "../src/common/IPError.m3"=3D2C line 27***
>=3B=> > >=3BAbort trap: 6 (core dumped)[jay at fbsdamd64a /cm3/bin]$
>=3B >=> >=3BIP.m3:
>=3B >=3B=3D20
>=3B >=3BPROCEDURE GetHostAddr(): Ad=> >dress =3D3D VAR hname: ARRAY [0..255] OF CHAR=3D3B =3D
>=3B >=3B BEG=> >IN LOCK mu DO IF Unix.gethostname(ADR(hname[0])=3D2C BYTESIZE(hna=3D
>=> >=3B >=3Bme)) # 0 THEN IPError.Die ()=3D3B END=3D3B VAR h :=3D3D Unetdb.g=> >=3D
>=3B >=3Bethostbyname(ADR(hname[0]))=3D3B BEGIN IF h =3D3D NIL T=> >HEN IPError.Die()=3D
>=3B >=3B=3D3B END=3D3B RETURN GetAddress(h)=3D=> >3B END=3D3B END=3D3B END GetHos=3D
>=3B >=3BtAddr=3D3B
>=3B >=> >=3BPROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Address =3D3D VA=> >R ua=3D
>=3B >=3B: Uin.struct_in_addr=3D3B BEGIN <=3B* ASSERT ent.=> >h_length <=3B=3D3D BYTESIZE(Addr=3D
>=3B >=3Bess) *>=3B ua :=3D3=> >D LOOPHOLE(ent.h_addr_list=3D2C UNTRACED =3D
>=3B >=3BREF UNTRACED R=> >EF Uin.struct_in_addr)^^=3D3B RETURN LOOPHOLE(ua.s_addr=3D2C A=3D
>=3B=> > >=3Bddress)=3D3B END GetAddress=3D3B
>=3B >=3B=3D20
>=3B >=> >=3Bgethostbyname is failing.
>=3B >=3B=3D20
>=3B >=3BAnalogou=> >s C code also fails:
>=3B >=3B=3D20
>=3B >=3B[jay at fbsdamd64a => >/cm3/bin]$ cat ~/5.c#include <=3Bassert.h>=3B#include <=3Bnetdb.h>=> >=3B#i=3D
>=3B >=3Bnclude <=3Bstdio.h>=3B#include <=3Berrno.h&g=> >t=3Btypedef struct hostent hostent_t=3D3B
>=3B >=3B=3D20
>=3B &=> >gt=3Bint main(){ char hostname[200]=3D3B hostent_t* h=3D3B int i=3D3B
&g=> >t=3B >=3B i =3D3D gethostname(hostname=3D2C 200)=3D3B assert(i =3D3D=3D3D=> > 0)=3D3B printf("hostna=3D
>=3B >=3Bme: %s\n"=3D2C hostname)=3D3B h => >=3D3D gethostbyname(hostname)=3D3B herror("foo")=3D3B=3D
>=3B >=3B p=> >rintf("%p %d %d\n"=3D2C h=3D2C errno=3D2C h_errno)=3D3B assert(h)=3D3B retu=> >rn 0=3D3B}
>=3B >=3B=3D20
>=3B >=3Bherror says "unknown host"=> >.
>=3B >=3BStack is:
>=3B >=3B at ../src/runtime/ex_frame/RTE=> >xFrame.m3:58#13 0x0000000801a7f2b3 in RTH=3D
>=3B >=3Books__Raise (M=> >3_AJWxb1_ex=3D3DError accessing memory address 0x8000ffffd278: =3D
>=> >=3B >=3BBad address.) at ../src/runtime/common/RTHooks.m3:79#14 0x0000000=> >80169c8=3D
>=3B >=3Bd3 in IPError__Die () at ../src/common/IPError.m=> >3:27#15 0x0000000801698a3e =3D
>=3B >=3Bin IP__GetHostAddr (M3_BCxjP=> >n__result=3D3DError accessing memory address 0x80=3D
>=3B >=3B00ffff=> >d338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x00000008012133d0=3D
&g=> >t=3B >=3B in XSharedMem__SameHost (M3_AQuuui_trsl=3D3DError accessing mem=> >ory address 0=3D
>=3B >=3Bx8000ffffd4d8: Bad address.) at ../src/xvb=> >t/XSharedMem.m3:96#17 0x000000=3D
>=3B >=3B0801212ab7 in XSharedMem_=> >_InitXClient (M3_AQuuui_v=3D3DError accessing memory=3D
>=3B >=3B ad=> >dress 0x8000ffffd648: Bad address.) at ../src/xvbt/XSharedMem.m3:29#1=3D >>>=3B >=3B8 0x0000000801211819 in XExtensions__InitXClient (M3_AQuuui_x=> >client=3D3DError=3D
>=3B >=3B accessing memory address 0x8000ffffd7f=> >8: Bad address.) at ../src/xvbt/X=3D
>=3B >=3BExtensions.m3:14#19 0x=> >00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst=3D
>=3B >=3B=> >=3D3D0x1879b=3D2C M3_AQuuui_trsl=3D3D0x6) at ../src/xvbt/XClientF.m3:583---=> >Typ=3D
>=3B >=3Be <=3Breturn>=3B to continue=3D2C or q <=3Bret=> >urn>=3B to quit---(More stack frames follow=3D
>=3B >=3B...)(gdb)<=> >BR>>=3B >=3B(* return TRUE if server and client are on same host *)PROC=> >EDURE SameHost (=3D
>=3B >=3Btrsl: XClient.T): BOOLEAN =3D3D VAR dis=> >play :=3D3D DisplayH=3D
>=3B >=3Bost(trsl)=3D3B displayAddr: IP.Addr=> >ess=3D3B BEGIN IF display =3D3D NIL THE=3D
>=3B >=3BN RETURN TRUE=3D=> >3B END=3D3B
>=3B >=3B TRY IF NOT IP.GetHostByName(display=3D2C displ=> >ayAddr) THEN RETURN FA=3D
>=3B >=3BLSE=3D3B END=3D3B RETURN displayA=> >ddr =3D3D IP.GetHostAddr()=3D3B EXCEPT =3D
>=3B >=3B| IP.Error =3D3D=> >>=3B RETURN FALSE=3D3B END=3D3B END SameHost=3D3B
>=3B >=3B=3D20 >R>>=3B >=3BThoughts?
>=3B >=3B=3D20
>=3B >=3BPerhaps my n=> >etwork isn't setup well=3D2C like I should add the local machine =3D
>=> >=3B >=3Bto /etc/hosts.I think this can be made to fail gracefully though.=> >It seems l=3D
>=3B >=3Bike it has nothing to do with AMD64_FREEBSD=> >=3D2C but could have to do with Fr=3D
>=3B >=3BeeBSD.
>=3B >=> >=3B=3D20
>=3B >=3BSeems like SocketPosix has nearly the exact same c=> >ode but appearsmore forgi=3D
>=3B >=3Bving.. IOError instead of Fata=> >l?
>=3B >=3B=3D20
>=3B >=3BSocketPosix.m3:
>=3B >=3B=> >=3D20
>=3B >=3BPROCEDURE GetHostAddr (): Address RAISES {OSError.E} => >=3D3D VAR host : AR=3D
>=3B >=3BRAY [0..255] OF CHAR=3D3B info : Une=> >tdb.struct_hostent_star=3D3B ua : U=3D
>=3B >=3Bin.struct_in_addr=3D=> >3B BEGIN IF Unix.gethostname (ADR (host[0])=3D2C BYTESI=3D
>=3B >=3B=> >ZE (host)) # 0 THEN IOError (Unexpected)=3D3B END=3D3B
>=3B >=3B inf=> >o :=3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3B IF info =3D3D NIL TH=3D<=> >BR>>=3B >=3BEN IOError (Unexpected)=3D3B END=3D3B <=3B* ASSERT info.h=> >_length <=3B=3D3D BYTESIZE =3D
>=3B >=3B(Address) *>=3B
>=> >=3B >=3B ua :=3D3D LOOPHOLE(info.h_addr_list=3D2C UNTRACED REF UNT=3D
=> >>=3B >=3BRACED REF Uin.struct_in_addr)^^=3D3B RETURN LOOPHOLE (ua.s_add=> >r=3D2C Address=3D
>=3B >=3B)=3D3B END GetHostAddr=3D3B
>=3B >=> >=3B=3D20
>=3B >=3B=3D20
>=3B >=3BIt is again disappointing to=> > see such code duplication.
>=3B >=3B=3D20
>=3B >=3B=3D20
=> >>=3B >=3BI guess SameHost can duplicate the logic to predict the error => >state and ret=3D
>=3B >=3Burn false upon error?
>=3B >=3BDupl=> >icating the logic for a third time. :(
>=3B >=3B=3D20
>=3B >=> >=3B - Jay=3D
>=3B >=3B
>=3B >=3B--_9e67232c-a064-417d-879e-22=> >7a77e310f9_
>=3B >=3BContent-Type: text/html=3B charset=3D"iso-8859-=> >1"
>=3B >=3BContent-Transfer-Encoding: quoted-printable
>=3B &g=> >t=3B
>=3B >=3B<=3Bhtml>=3B
>=3B >=3B<=3Bhead>=3B
&=> >gt=3B >=3B<=3Bstyle>=3B
>=3B >=3B.hmmessage P
>=3B >=3B=> >{
>=3B >=3Bmargin:0px=3D3B
>=3B >=3Bpadding:0px
>=3B >=> >=3B}
>=3B >=3Bbody.hmmessage
>=3B >=3B{
>=3B >=3Bfont-=> >size: 10pt=3D3B
>=3B >=3Bfont-family:Verdana
>=3B >=3B}
&g=> >t=3B >=3B<=3B/style>=3B
>=3B >=3B<=3B/head>=3B
>=3B &=> >gt=3B<=3Bbody class=3D3D'hmmessage'>=3B
>=3B >=3BHi. Unix networ=> >k programming question..<=3BBR>=3B
>=3B >=3B<=3BBR>=3BAMD64_=> >FREEBSD:<=3BBR>=3B
>=3B >=3B<=3BBR>=3B$DISPLAY is set to poi=> >nt back to Cygwin host.<=3BBR>=3BIt works for PPC_LINUX=3D
>=3B &g=> >t=3B.<=3BBR>=3B
>=3B >=3B<=3BBR>=3B[jay at fbsdamd64a /cm3/bin]=> >$ ./Juno<=3BBR>=3B
>=3B >=3B<=3BBR>=3B***<=3BBR>=3B*** r=> >untime error:<=3BBR>=3B***&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=> >=3D3B Exception "IPE=3D
>=3B >=3Brror.FatalError" not in RAISES list=> ><=3BBR>=3B***&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B file "..=> >=3D
>=3B >=3B/src/common/IPError.m3"=3D2C line 27<=3BBR>=3B***&l=> >t=3BBR>=3B
>=3B >=3B<=3BBR>=3BAbort trap: 6 (core dumped)<=> >=3BBR>=3B[jay at fbsdamd64a /cm3/bin]$<=3BBR>=3B
>=3B >=3B<=3BB=> >R>=3BIP.m3:<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B<=> >BR>>=3B >=3BPROCEDURE GetHostAddr(): Address =3D3D<=3BBR>=3B&=3B=> >nbsp=3D3B VAR hname: ARRAY [0..255] =3D
>=3B OF CHAR=3D3B<=3BBR>=> >=3B&=3Bnbsp=3D3B BEGIN<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=> >=3Bnbsp=3D3B LOCK mu DO<=3BBR>=3B&=3Bnbs=3D
>=3B >=3Bp=3D3B&a=> >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B IF Unix.geth=> >ostname(ADR(hname[0])=3D2C B=3D
>=3B >=3BYTESIZE(hname)) # 0 THEN<=> >=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B=> >&=3Bnbsp=3D3B&=3Bnbsp=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B IPErro=> >r.Die ()=3D3B<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B=> >&=3Bnbsp=3D3B&=3Bnbsp=3D3B E=3D
>=3B >=3BND=3D3B<=3BBR>=3B=> >&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=> >=3D3B VAR h :=3D3D Unetdb.gethost=3D
>=3B >=3Bbyname(ADR(hname[0]))=> >=3D3B BEGIN<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&a=> >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3B=3D
>=3B >=3Bnbsp=3D3B&=3Bnb=> >sp=3D3B IF h =3D3D NIL THEN IPError.Die()=3D3B END=3D3B<=3BBR>=3B&=> >=3Bnbsp=3D3B&=3Bnbsp=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B&=3Bnbsp=> >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B RETURN GetAddress(h)=> >=3D3B<=3BBR>=3B&=3Bnbs=3D
>=3B >=3Bp=3D3B&=3Bnbsp=3D3B&=> >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B END=3D3B<=3BBR>=3B&=3Bn=> >bsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B END=3D
>=3B >=3B=3D3B<=3B=> >BR>=3B&=3Bnbsp=3D3B END GetHostAddr=3D3B<=3BBR>=3B
>=3B >=> >=3B<=3BBR>=3BPROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Ad=> >dress =3D3D<=3BBR>=3B=3D
>=3B >=3B&=3Bnbsp=3D3B VAR ua: Uin.s=> >truct_in_addr=3D3B<=3BBR>=3B&=3Bnbsp=3D3B BEGIN<=3BBR>=3B&=3B=> >nbsp=3D3B&=3Bnbsp=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B &=3Blt=3D3=> >B* ASSERT ent.h_length &=3Blt=3D3B=3D3D BYTESIZE(Address) *&=3Bgt=3D3=> >B=3D
>=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bn=> >bsp=3D3B ua :=3D3D LOOPHOLE(ent.h_addr_list=3D2C<=3BBR>=3B&=3Bnbsp=> >=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&a=> >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=> >=3D3B&=3Bnbsp=3D3B=3D
>=3B >=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&a=> >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=> >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B UN=3D
>=3B >=3BTRACED REF UNTR=> ACED REF Uin.struct_in_addr)^^=3D3B<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbs=> >p=3D3B&=3Bnbsp=3D
>=3B >=3B=3D3B RETURN LOOPHOLE(ua.s_addr=3D2C A=> >ddress)=3D3B<=3BBR>=3B&=3Bnbsp=3D3B END GetAddress=3D3B<=3B=3D
=> >>=3B >=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=> >=3B >=3Bgethostbyname is failing.<=3BBR>=3B
>=3B >=3B<=3BBR&=> >gt=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BAnalogous C code also f=> >ails:<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=> >=3B >=3B<=3BBR>=3B[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c<=3BBR>=3B#=> >include &=3Blt=3D3Bassert.h&=3Bgt=3D3B<=3BB=3D
>=3B >=3BR>=> >=3B#include &=3Blt=3D3Bnetdb.h&=3Bgt=3D3B<=3BBR>=3B#include &=> >=3Blt=3D3Bstdio.h&=3Bgt=3D3B<=3BBR>=3B#include =3D
>=3B >=3B&=> >amp=3Blt=3D3Berrno.h&=3Bgt=3D3B<=3BBR>=3Btypedef struct hostent host=> >ent_t=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
=> >>=3B >=3Bint main()<=3BBR>=3B{<=3BBR>=3B&=3Bnbsp=3D3Bchar ho=> >stname[200]=3D3B<=3BBR>=3B&=3Bnbsp=3D3Bhostent_t* h=3D3B=3D
>=> >=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3Bint i=3D3B<=3BBR>=3B
>=3B => >>=3B&=3Bnbsp=3D3Bi =3D3D gethostname(hostname=3D2C 200)=3D3B<=3BBR&g=> >t=3B&=3Bnbsp=3D3Bassert(i =3D3D=3D3D 0)=3D
>=3B >=3B=3D3B<=3BBR=> >>=3B&=3Bnbsp=3D3Bprintf("hostname: %s\n"=3D2C hostname)=3D3B<=3BBR&g=> >t=3B&=3Bnbsp=3D3Bh =3D3D get=3D
>=3B >=3Bhostbyname(hostname)=3D3=> >B<=3BBR>=3B&=3Bnbsp=3D3Bherror("foo")=3D3B<=3BBR>=3B&=3Bnbsp=> >=3D3Bprintf("%p %=3D
>=3B >=3Bd %d\n"=3D2C h=3D2C errno=3D2C h_errno=> >)=3D3B<=3BBR>=3B&=3Bnbsp=3D3Bassert(h)=3D3B<=3BBR>=3B&=3Bnbsp=> >=3D3Bret=3D
>=3B >=3Burn 0=3D3B<=3BBR>=3B}<=3BBR>=3B
>=> >=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3Bherror says "unkno=> >wn host".<=3BBR>=3B
>=3B >=3B<=3BBR>=3BStack is:<=3BBR>=> >=3B
>=3B >=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B at ../=> >src/runtime/ex_frame/RTExFrame.m3:58<=3BBR>=3B#13 =3D
>=3B >=3B0=> >x0000000801a7f2b3 in RTHooks__Raise (M3_AJWxb1_ex=3D3DError accessing memor=> >y=3D
>=3B >=3B ad<=3BBR>=3Bdress 0x8000ffffd278: Bad address.<=> >=3BBR>=3B)<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B => >=3D
>=3B >=3Bat ../src/runtime/common/RTHooks.m3:79<=3BBR>=3B#14=> > 0x000000080169c8d3 in IPError=3D
>=3B >=3B__Die () at ../src/common=> >/IPError.m3:27<=3BBR>=3B#15 0x0000000801698a3e in IP__Ge=3D
>=3B &=> >gt=3BtHostAddr (M3_BCxjPn__result=3D3DError accessing mem<=3BBR>=3Bory => >address 0x8000fff=3D
>=3B >=3Bfd338: Bad address.<=3BBR>=3B)<=> >=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B at ../src/POSIX=> >/IP.m3:=3D
>=3B >=3B82<=3BBR>=3B#16 0x00000008012133d0 in XShare=> >dMem__SameHost (M3_AQuuui_trsl=3D3DErro=3D
>=3B >=3Br accessing m<=> >=3BBR>=3Bemory address 0x8000ffffd4d8: Bad address.<=3BBR>=3B)<=3BB=> >R>=3B&=3Bnbsp=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B=> > at ../src/xvbt/XSharedMem.m3:96<=3BBR>=3B#17 0x0000000801212a=3D
&g=> >t=3B >=3Bb7 in XSharedMem__InitXClient (M3_AQuuui_v=3D3DError accessing m=> ><=3BBR>=3Bemory add=3D
>=3B >=3Bress 0x8000ffffd648: Bad address=> >.<=3BBR>=3B)<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=> >=3D3B at ../sr=3D
>=3B >=3Bc/xvbt/XSharedMem.m3:29<=3BBR>=3B#18 => >0x0000000801211819 in XExtensions__InitXClie=3D
>=3B >=3Bnt (M3_AQuu=> >ui_xclient=3D3DError acce<=3BBR>=3Bssing memory address 0x8000ffffd7f8:=> > =3D
>=3B >=3BBad address.<=3BBR>=3B)<=3BBR>=3B&=3Bnbsp=> >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B at ../src/xvbt/XExtensions.m3=3D
&=> >gt=3B >=3B:14<=3BBR>=3B#19 0x00000008012467a4 in XClientF__Connect (M=> >3_Bd56fi_inst=3D3D0x1879=3D
>=3B >=3Bb=3D2C<=3BBR>=3B&=3Bnbsp=> >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B M3_AQuuui_trsl=3D3D0x6) at ../src/xvb=> >t/XClie=3D
>=3B >=3BntF.m3:583<=3BBR>=3B---Type &=3Blt=3D3Bre=> >turn&=3Bgt=3D3B to continue=3D2C or q &=3Blt=3D3Breturn&=3Bg=3D >>>=3B >=3Bt=3D3B to quit---<=3BBR>=3B(More stack frames follow...)&=> >lt=3BBR>=3B(gdb)<=3BBR>=3B
>=3B >=3B<=3BBR>=3B(* return TR=> >UE if server and client are on same host *)<=3BBR>=3BPROCEDURE Sa=3D >>>=3B >=3BmeHost (trsl: XClient.T): BOOLEAN =3D3D<=3BBR>=3B&=3Bn=> >bsp=3D3B VAR<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bn=3D
&g=> >t=3B >=3Bbsp=3D3B display&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B=> >&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=> >=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&a=> >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=> >=3D3B :=3D3D Di=3D
>=3B >=3BsplayHost(trsl)=3D3B<=3BBR>=3B&=> >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B displayAddr: IP.Address=3D3B&l=> >t=3BB=3D
>=3B >=3BR>=3B&=3Bnbsp=3D3B BEGIN<=3BBR>=3B&=3B=> >nbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B IF display =3D3D NIL THEN RETURN=> >=3D
>=3B >=3B TRUE=3D3B END=3D3B<=3BBR>=3B
>=3B >=3B&=> >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B TRY<=3BBR>=3B&=3Bnbsp=> >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B IF=3D=> >
>=3B >=3B NOT IP.GetHostByName(display=3D2C displayAddr) THEN RETUR=> >N FALSE=3D3B END=3D3B<=3BB=3D
>=3B >=3BR>=3B&=3Bnbsp=3D3B&=> >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B RETURN display=> >Addr =3D3D IP.GetHos=3D
>=3B >=3BtAddr()=3D3B<=3BBR>=3B&=3Bnb=> >sp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B EXCEPT<=3BBR>=3B&=3Bnbsp=3D3=> >B&=3Bnbsp=3D3B&=3Bnbsp=3D3B |=3D
>=3B >=3B IP.Error =3D3D&=> >=3Bgt=3D3B RETURN FALSE=3D3B<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=> >amp=3Bnbsp=3D3B END=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bnbsp=3D3B => >END SameHost=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=> >=3B
>=3B >=3BThoughts?<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3=> >B<=3BBR>=3B
>=3B >=3B<=3BBR>=3BPerhaps my network isn't setu=> >p well=3D2C like I should add the local mach=3D
>=3B >=3Bine to /etc=> >/hosts.<=3BBR>=3BI think this can be made to fail gracefully though.<=> >=3BB=3D
>=3B >=3BR>=3BIt seems like it has nothing to do with AMD6=> >4_FREEBSD=3D2C but could have t=3D
>=3B >=3Bo do with FreeBSD.<=3B=> >BR>=3B
>=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B
&g=> >t=3B >=3BSeems like SocketPosix has nearly the exact same code but appear=> >s<=3BBR>=3Bmore f=3D
>=3B >=3Borgiving.. IOError instead of Fata=> >l?<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B &=> >gt=3B<=3BBR>=3BSocketPosix.m3:<=3BBR>=3B
>=3B >=3B&=3Bnbs=> >p=3D3B<=3BBR>=3B
>=3B >=3B<=3BBR>=3BPROCEDURE GetHostAddr ()=> >: Address<=3BBR>=3B&=3Bnbsp=3D3B RAISES {OSError.E} =3D3D<=3BBR=3D=> >
>=3B >=3B>=3B&=3Bnbsp=3D3B VAR<=3BBR>=3B&=3Bnbsp=3D3B&a=> >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B host : ARRAY [0..255] OF CHAR=3D3B<=3B=3D<=> >BR>>=3B >=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B in=> >fo : Unetdb.struct_hostent_star=3D3B<=3BBR>=3B&=3Bnbsp=3D
>=3B => >>=3B=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B ua&=3Bnbsp=3D3B&=3Bnbsp=> >=3D3B : Uin.struct_in_addr=3D3B<=3BBR>=3B&=3Bnbsp=3D3B =3D
>=3B=> > >=3BBEGIN<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B => >IF Unix.gethostname (ADR (host[0])=3D2C BYT=3D
>=3B >=3BESIZE (host)=> >) # 0 THEN<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&am=> >p=3Bnbsp=3D3B&=3Bnbsp=3D3B IOError =3D
>=3B >=3B(Unexpected)=3D3B=> ><=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B END=3D3B<=> >=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3=> >B info :=3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3B<=3B=3D
>=3B => >>=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B IF info =3D3=> >D NIL THEN IOError (Unexpected)=3D3B EN=3D
>=3B >=3BD=3D3B<=3BBR&g=> >t=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B &=3Blt=3D3B* ASSERT=> > info.h_length &=3Blt=3D3B=3D3D BYT=3D
>=3B >=3BESIZE (Address) *=> >&=3Bgt=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B&=3Bnbsp=3D=> >3B&=3Bnbsp=3D3B ua :=3D3D LOOPHOLE(info.h_addr_list=3D2C<=3BBR>=3B&a=> >mp=3Bnbsp=3D3B&=3Bn=3D
>=3B >=3Bbsp=3D3B&=3Bnbsp=3D3B&=3Bnb=> >sp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=> >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D
>=3B >=3B=3D3B&=3Bnbsp=> >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=> >=3Bnbsp=3D3B&=3Bnbsp=3D3B UNTRACED REF UN=3D
>=3B >=3BTRACED REF => >Uin.struct_in_addr)^^=3D3B<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&am=> >p=3Bnbsp=3D3B RETURN LOOP=3D
>=3B >=3BHOLE (ua.s_addr=3D2C Address)=> >=3D3B<=3BBR>=3B&=3Bnbsp=3D3B END GetHostAddr=3D3B<=3BBR>=3B
&=> >gt=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B=> ><=3BBR>=3B
>=3B >=3BIt is again disappointing to see such code d=> >uplication.<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B >>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BI guess&=3B=> >nbsp=3D3BSameHost can duplicate the logic to predict the error state =3D >>>=3B >=3Band return false&=3Bnbsp=3D3Bupon error?<=3BBR>=3B
=> >>=3B >=3BDuplicating the logic for a third time. :(<=3BBR>=3B
&g=> >t=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B<=3BBR>=3B&am=> >p=3Bnbsp=3D3B- Jay<=3BBR>=3B<=3BBR>=3B<=3B/body>=3B
>=3B &=> >gt=3B<=3B/html>=3B=3D
>=3B >=3B
>=3B >=3B--_9e67232c-a064=> >-417d-879e-227a77e310f9_--

> >=> >> >--_b00371fe-730b-4981-9051-a874361296d7_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 10:31:13 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 20:31:13 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20090112092033.2748010D5FD1@birch.elegosoft.com> References: <20090112092033.2748010D5FD1@birch.elegosoft.com> Message-ID: Jay, I have to call it quits on this tonight. As you can see, I've reverted the clients of SchedulerPosix.WaitProcess to do the re- packing based on the original definitions in Uexec. We need to do a more wholesale check of the clients of Process.Wait and System.Wait to see who 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. I think we can make this much cleaner if we can get rid of the re-packing. I am still concerned that there is needless splitting of the threads files. Perhaps ThreadPWait.m3 and ThreadPScheduler.m3 can be merged. I still don't like either of those names, but we should avoid SchedulerPosix.m3 since ThreadPosix.m3 also exports SchedulerPosix. It would really be much nicer if you could get CygWin to run using PTHREAD instead of the weird WIN32 hybrid. I'm hoping I can get back to more productive pursuits tomorrow... today has been pretty much destroyed as a result of these commits... The productive things are improving concurrency in the garbage collector -- I'd like to be able to do collection in parallel... ;-) On 12 Jan 2009, at 10:20, Antony Hosking wrote: > 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 mika at async.caltech.edu Mon Jan 12 10:34:24 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 12 Jan 2009 01:34:24 -0800 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: Your message of "Mon, 12 Jan 2009 08:47:17 GMT." Message-ID: <200901120934.n0C9YOs8074851@camembert.async.caltech.edu> You present it as a true tragic Dilemma. But isn't there a Third Way---to wit, can't you "Ask the Computer" to do the work for you? Generate the code somehow... Parsing the C headers is an obvious way but there may be others that are simpler, such as writing a Modula-3 program to generate the cloned M3 headers, sorry, interfaces. If I had to do this I would use my Scheme interpreter that's coded in Modula-3 to write a Scheme program to generate the headers. This program could pull whatever tricks are deemed necessary and suitable, down to the point of generating and compiling and running C programs as necessary (or parsing C code, or reading tea leaves). But the end result would be a set of interfaces written in "Pure Modula-3". The process of running the header generator would also have very few dependencies on anything outside the M3 distribution. Mika Jay writes: >--_6117a048-9185-4c03-badb-ef8f93402268_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >This is what you "have to" chose between. >Header cloning or C code (and C headers). >=20 >CONST or VAR (or functions?) >=20 >I'm going to likely make the Uerror change tonight. >You can still veto it (er=2C vote against it :) ) >=20 >Possibly some convuluted C (enum/#undef)=2C or splitting the Modula-3 >at boundaries that weren't previously believed "natural". >(See how SetupHandlers is ~two lines in Modula-3 and the rest in C=3B >this is partly out of ignorance. I don't know how to write those >two lines in C=3B and laziness=2C I didn't look into how). >=20 >=20 >=20 >Remember I'm still staying away from mainstream platforms=2C >so the value isn't what it might appear to be=2C but it is "stage setting"= >=2C >and the show might go on. :) >=20 >=20 >Also=2C the dilemna does get more difficult now=2C with the little C header= > cloning that remains. >=20 >For example=2C look at Upthreads.i3. >Mainly=2C look at function prototypes. >Constants and types are "known problems". >Prototypes are gray. They actually tend to be portable. >=20 >For example: >=20 >TYPE pid_t =3D INTEGER=3B ><*EXTERNAL "m3_getpid*> PROCEDURE getpid():pid_t=3B >=20 >or leave it alone? >getpid is probably the worst example. >It is so very portable declared in Modula-3. >But still=2C imagine pid_t might be 16bits or 32 or 64. >Writing a wrapper is more portable -- as long as the pid isn't stuff into s= >ome record that the system defines. >=20 >=20 >Again=2C Upthreads.i3. >Would you like to see it reduced=2C or left alone? >Only deal with the types and initializers=2C or also the prototypes? >You know=2C I could write a little portable layer=2C where all the types ar= >e pointers=2C always null initialized. >It would buy /some/ portability=2C and cost some. >=20 >=20 >Do you like the sem_t change? Partly? Not at all? >There is one sem_t in the system. So I moved it to be in C code. >Or=2C as I had it before=2C declared as the max size/align of all the platf= >orms -- getting that right is the same work as getting it right "the old wa= >y"=2C except if you make a mistake=2C odds are still good of it being ok. >=20 >=20 >Should the line be drawn at generating the remaining headers=2C rather than= > eliminating them? >Uerror.i3 is easily generated. Good enough? >=20 >Upthread.i3's types can be generated generally as records with opaque array= >s with the right size and alignment. >=20 >Other stuff can be generated or at least checked. >e.g. to check that getpid is declared correctly=2C you can assign it to a f= >unction pointer and see if that compiles. >=20 >Perf on Uerror arguably doesn't matter. >Is it only error handling code?Or do sockets often go down "error" paths=2C= > because they are slow and you are waiting for more data? >=20 >Anyway=2C point is=2C I agree for sure this is valuable=2C but I might be h= >itting the "tail" of the approach and should switch=2C I'm not sure. I keep= > saying that though=2C and then press further. >=20 >=20 > - Jay > > > >From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon=2C 12 Jan 200= >9 19:24:50 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a= > type's existance but not enough to instantiate it? > > >Point taken. We live in a C universe and so need to interact. I do think = >your work with the headers is useful=2C and I want it to continue. Especia= >lly in simplifying ports. > > >On 12 Jan 2009=2C at 19:18=2C Jay wrote: > >I don't think a development system without C headers is interesting.. Is it= > really? The transform I apply at times is wherever there is interaction wi= >th C code that is described by system-dependent headers=2C or perhaps even = >fairly system-independent headers outside the Modula-3 tree=2C either write= > wrapper functions for the functionality in the headers (e.g. stat=2C waitp= >id)=2C which can be done in a system-independent way=2C or move the Modula-= >3<->C transition higher=2C which is also usually system-independent=2C e.g.= > ThreadPThreadC_SetupHandlers. It is either that or clone the headers=2C wh= >ich seems like the worse evil. There is always going to be a Modula-3<->C t= >ransition=2C it is just a matter of where it occurs. - Jay > >CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.e= >duSubject: Re: [M3devel] declaring a type's existance but not enough to ins= >tantiate it?Date: Mon=2C 12 Jan 2009 12:32:15 +1100 > > >Jay=2C I really think you are bending over backwards too far just to be abl= >e to shoe-horn things into C. I *like* having the transpar of C header fil= >es expressed in Modula-3=2C *particularly* for system calls=2C where you mi= >ght even be trying to build on a system that does not have the C header fil= >es installed=2C even though the libraries exist and can be linked to. Fund= >amentally=2C I think anytime the Modula-3 code is made less transparent you= > should think hard about what you are doing. The same with the change of c= >onstants to variables. > >I am getting very nervous that the changes you are making are destroying th= >e clarity of the Modula-3 run-time code. > >In this particular case=2C you are wanting to use a Modula-3 parameter pass= >ing mechanism on something that is not declared in Modula-3. Seems kind of= > dubious to me. Also=2C I really don't like the idea of accessing external= > variables in C. > >-- Tony > >On 12 Jan 2009=2C at 11:55=2C Jay wrote: > >I considered ADDRESS.However I think it still doesn't satisfy. I want to be= > able to do this: TYPE Foo_t =3D something=3B<* EXTERNAL *> VAR Foo1=2C Foo= >2:Foo_t=3B<* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t)= >=3B (* Modula-3=2C not external *)PROCEDURE x()=3DBEGIN UseFoo(Foo1)=3B U= >seFoo(Foo2)=3BEND x=3B AND I want any use of:VAR Foo3:Foo3_t=3B (* Modula-3= >=2C not external *)to error. This is sem_t and sigset_t in particular. Poss= >ibly renaming is the thing.They used to be declared in Modula-3=2C system-d= >ependently=2C butI moved them to portable C. I could remove the types entir= >ely and change UseFoo to take an address=2Cand declare mask and ackSem to b= >e integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END=3B That would sat= >isfy but I thought it might be nicer to still provide the namedtypes to ref= >er to the external variables. - Jay > >From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon=2C 12 Jan 200= >9 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a= > type's existance but not enough to instantiate it?What's wrong with using = >ADDRESS for references to opaque values? If sigset_t is never instantiated= > in Modula-3=2C then why do you need it declared there? > > > >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=2C at 01:44=2C Jay wrote: > >Is there a way in Modula-3 to declare that a type exists=2C and there are <= >*external*> instances of it=2C without "fully" declaring it=2C so that no M= >odula-3 can instantiate it? I have done this for sigset_t and sem_t=2C but = >they could erroneously be instantiated by Modula-3 and I'd like to remove t= >hat ability to mess up so easily. (* This type is not declared correctly. I= >t is only instantiated in C code. *) sigset_t =3D RECORD END=3B(* This typ= >e is not declared correctly. It is only instantiated in C code. *) sem_t = >=3D RECORD END=3BIn C I believe you can do this=2C like: typedef struct fo= >o foo_t=3B extern foo_t foo=3B void UseFoo(foo_t*)=3B foo_t* GetFoo= >(void)=3B Thanks=2C - Jay= > >--_6117a048-9185-4c03-badb-ef8f93402268_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >This is what you "have to" chose between.
>Header cloning or C code (and C headers).
> =3B
>CONST or VAR (or functions?)
> =3B
>I'm going to likely make the Uerror change tonight.
>You can still veto it (er=2C vote against it :) )
> =3B
>Possibly some convuluted C (enum/#undef)=2C or splitting the Modula-3
>at boundaries that weren't previously believed "natural".
>(See how SetupHandlers is ~two lines in Modula-3 and the rest in C=3B
>this is partly out of ignorance. I don't know how to write those
>two lines in C=3B and laziness=2C I didn't look into how).
> =3B
> =3B
> =3B
>Remember I'm still staying away from mainstream platforms=2C
>so the value isn't what it might appear to be=2C but it is "stage setting"= >=2C
>and the show might go on. :)
> =3B
> =3B
>Also=2C the dilemna does get more difficult now=2C with the little C header= > cloning that remains.
> =3B
>For example=2C look at Upthreads.i3.
>Mainly=2C look at function prototypes.
>Constants and types are "known problems".
>Prototypes are gray. They actually tend to be portable.
> =3B
>For example:
> =3B
>TYPE pid_t =3D INTEGER=3B
><=3B*EXTERNAL "m3_getpid*>=3B PROCEDURE getpid():pid_t=3B
> =3B
>or leave it alone?
>getpid is probably the worst example.
>It is so very portable declared in Modula-3.
>But still=2C imagine pid_t might be 16bits or 32 or 64.
>Writing a wrapper is more portable -- as long as the pid isn't stuff into s= >ome record that the system defines.
> =3B
> =3B
>Again=2C Upthreads.i3.
>Would you like to see it reduced=2C or left alone?
>Only deal with the types and initializers=2C or also the prototypes?
>You know=2C I could write a little portable layer=2C where all the types ar= >e pointers=2C always null initialized.
>It would buy /some/ portability=2C and cost some.
> =3B
> =3B
>Do you like the sem_t change? Partly? Not at all?
>There is one sem_t in the system. So I moved it to be in C code.
>Or=2C as I had it before=2C declared as the max size/align of all the platf= >orms -- getting that right is the same work as getting it right "the old wa= >y"=2C except if you make a mistake=2C odds are still good of it being ok.R> > =3B
> =3B
>Should the line be drawn at generating the remaining headers=2C rather than= > eliminating them?
>Uerror.i3 is easily generated. Good enough?
> =3B
>Upthread.i3's types can be generated generally as records with opaque array= >s with the right size and alignment.
> =3B
>Other stuff can be generated or at least checked.
>e.g. to check that getpid is declared correctly=2C you can assign it to a f= >unction pointer and see if that compiles.
> =3B
>Perf on Uerror arguably doesn't matter.
>Is it only error handling code?
Or do sockets often go down "error" path= >s=2C because they are slow and you are waiting for more data?
> =3B
>Anyway=2C point is=2C I agree for sure this is valuable=2C but I might be h= >itting the "tail" of the approach and should switch=2C I'm not sure. I keep= > saying that though=2C and then press further.
> =3B
> =3B
> =3B- Jay

> >

>From: hosking at cs.purdue.edu
To: jay.krell at cornell.edu
Date: Mon=2C 12= > Jan 2009 19:24:50 +1100
CC: m3devel at elegosoft.com
Subject: Re: [M3de= >vel] declaring a type's existance but not enough to instantiate it?

= >
>
12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-IND= >ENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPS= >E: separate"> >
e=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B C= >OLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-S= >PACING: normal=3B BORDER-COLLAPSE: separate">pan style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: n= >one=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B = >LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate">-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRAN= >SFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: no= >rmal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate">EC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B T= >EXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-S= >PACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate">class=3DEC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvet= >ica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B= > WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate= >">x Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT= >: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: = >separate">ONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEX= >T-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-CO= >LLAPSE: separate">0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0= >)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B B= >ORDER-COLLAPSE: separate"> >
Point taken.  =3BWe live in a C universe and so need to interact. = > =3BI do think your work with the headers is useful=2C and I want it to= > continue.  =3BEspecially in simplifying ports.
>

V>
>
>
On 12 Jan 2009=2C at 19:18=2C Jay wrote:

erchange-newline> >
FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B T= >EXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-= >COLLAPSE: separate"> >
>I don't think a development system without C headers is interesting.. Is i= >t really?
 =3B
The transform I apply at times is wherever there i= >s interaction with C code that is described by system-dependent headers=2C = >or perhaps even fairly system-independent headers outside the Modula-3 tree= >=2C either write wrapper functions for the functionality in the headers (e.= >g. stat=2C waitpid)=2C which =3Bcan be done in a system-independent way= >=2C =3Bor move the Modula-3<=3B->=3BC transition higher=2C which is= > also usually system-independent=2C e.g. ThreadPThreadC_SetupHandlers.
&= >nbsp=3B
It is either that or clone the headers=2C which seems like the w= >orse evil.
 =3B
There is always going to be a Modula-3<=3B->= >=3BC transition=2C it is just a matter of where it occurs.
 =3B
&= >nbsp=3B- Jay

>
>
CC: =3Blto:m3devel at elegosoft.com">m3devel at elegosoft.com
From:EC_Apple-converted-space> =3B.edu">hosking at cs.purdue.edu
To:e> =3Bjay.krell at cornell= >.edu
Subject: Re: [M3devel] declaring a type's existance but not eno= >ugh to instantiate it?
Date: Mon=2C 12 Jan 2009 12:32:15 +1100

R>
T: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-= >INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLL= >APSE: separate"> >
tyle=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none= >=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LET= >TER-SPACING: normal=3B BORDER-COLLAPSE: separate">-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRAN= >SFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: no= >rmal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate">EC_EC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica= >=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WH= >ITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate"><= >SPAN class=3DEC_EC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12p= >x Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT= >: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: = >separate">=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)= >=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BO= >RDER-COLLAPSE: separate">-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb= >(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: n= >ormal=3B BORDER-COLLAPSE: separate">yle=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B= > COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER= >-SPACING: normal=3B BORDER-COLLAPSE: separate">yle-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFO= >RM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: norma= >l=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate"> >
Jay=2C I really think you are bending over backwards too far just to b= >e able to shoe-horn things into C.  =3BI *like* having the transpar of = >C header files expressed in Modula-3=2C *particularly* for system calls=2C = >where you might even be trying to build on a system that does not have the = >C header files installed=2C even though the libraries exist and can be link= >ed to.  =3BFundamentally=2C I think anytime the Modula-3 code is made l= >ess transparent you should think hard about what you are doing.  =3BThe= > same with the change of constants to variables.
>

>
I am getting very nervous that the changes you are making are destroyi= >ng the clarity of the Modula-3 run-time code.
>

>
In this particular case=2C you are wanting to use a Modula-3 parameter= > passing mechanism on something that is not declared in Modula-3.  =3BS= >eems kind of dubious to me.  =3BAlso=2C I really don't like the idea of= > accessing external variables in C.
>

>
-- Tony
<= >/DIV>

>
>
On 12 Jan 2009=2C at 11:55=2C Jay wrote:

interchange-newline> >
=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)= >=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BO= >RDER-COLLAPSE: separate"> >
na">I considered ADDRESS.
However I think it still doesn't satisfy.
&= >nbsp=3B
I want to be able to do this:
 =3B
TYPE =3BFoo_t = >=3D something=3B
<=3B* EXTERNAL *>=3B VAR Foo1=2C Foo2:Foo_t=3B
&= >lt=3B* EXTERNAL *>=3B PROCEDURE =3BUseFoo(READONLY (* or VAR *) foo:F= >oo_t)=3B
 =3B
(* Modula-3=2C not external *)
PROCEDURE x()=3D<= >BR>BEGIN
 =3B UseFoo(Foo1)=3B
 =3B UseFoo(Foo2)=3B
END x= >=3B
 =3B
AND I want any use of:
VAR Foo3:Foo3_t=3B (* Modula-3= >=2C not external *)

to error. This is sem_t and sigset_t in particul= >ar.
 =3B
Possibly renaming is the thing.
They used to be decla= >red in Modula-3=2C system-dependently=2C but
I moved them to portable C.= >
 =3B
I could remove the types entirely and change UseFoo to take= > an address=2C
and declare mask and ackSem to be integers or I guess.><=3B*EXTERNAL>=3B VAR ackSem =3B: RECORD END=3B
 =3B
Tha= >t would satisfy but I thought it might be nicer to still provide the named<= >BR>types to refer to the external variables.
 =3B
 =3B- JayR>
>
>
From: =3B=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu
To:ss=3DEC_EC_Apple-converted-space> =3B@cornell.edu">jay.krell at cornell.edu
Date: Mon=2C 12 Jan 2009 11:13:0= >0 +1100
CC: =3Bref=3D"mailto:m3devel at elegosoft.com">m3devel at elegosoft.com
Subject: = >Re: [M3devel] declaring a type's existance but not enough to instantiate it= >?

What's wrong with using ADDRESS for references to opaque values? &= >nbsp=3BIf sigset_t is never instantiated in Modula-3=2C then why do you nee= >d it declared there?
>

>
FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TE= >XT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-C= >OLLAPSE: separate"> >
n style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: non= >e=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LE= >TTER-SPACING: normal=3B BORDER-COLLAPSE: separate">pple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-= >TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE= >: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate">s=3DEC_EC_EC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helv= >etica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px= >=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separ= >ate">FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TE= >XT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-C= >OLLAPSE: separate">ACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0= >=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: nor= >mal=3B BORDER-COLLAPSE: separate">tyle=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none= >=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LET= >TER-SPACING: normal=3B BORDER-COLLAPSE: separate">ple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-T= >RANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE:= > normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate">=3DEC_EC_EC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helve= >tica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px= >=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separ= >ate"> >
EC_EC_EC_Apple-style-span face=3D"Gill Sans">tyle-span style=3D"COLOR: rgb(0=2C0=2C255)=3B FONT-FAMILY: 'Gill Sans'">AN class=3DEC_EC_EC_Apple-style-span style=3D"COLOR: rgb(0=2C0=2C255)=3B FO= >NT-FAMILY: 'Gill Sans'">Antony Hoskingss=3DEC_EC_EC_Apple-style-span face=3D"Gill Sans">ple-style-span style=3D"FONT-FAMILY: 'Gill Sans'">ple-style-span style=3D"FONT-FAMILY: 'Gill Sans'">-converted-space> =3B|= > =3B=3D"FONT-FAMILY: 'Gill Sans'">=3D"FONT-FAMILY: 'Gill Sans'">Associate Professor=3DEC_EC_EC_Apple-style-span style=3D"FONT-FAMILY: 'Gill Sans'">=3DEC_EC_EC_Apple-style-span style=3D"FONT-FAMILY: 'Gill Sans'"> =3B| C= >omputer Science | Purdue University
>
ass=3DEC_EC_EC_Apple-style-span style=3D"FONT-FAMILY: GillSans-Light">305 N= >. University Street | West Lafayette | IN 47907 | USA
>
00ff>5)=3B FONT-FAMILY: 'Gill Sans'">le=3D"COLOR: rgb(0=2C0=2C255)=3B FONT-FAMILY: 'Gill Sans'">OfficePAN>PAN class=3DEC_EC_EC_Apple-style-span style=3D"FONT-FAMILY: GillSans-Light"= >>ht"> =3B+1 765 494 6001 |&nbs= >p=3Be=3D"Gill Sans" color=3D#0000ff>le=3D"COLOR: rgb(0=2C0=2C255)=3B FONT-FAMILY: 'Gill Sans'">_EC_EC_Apple-style-span style=3D"COLOR: rgb(0=2C0=2C255)=3B FONT-FAMILY: 'G= >ill Sans'">Mobilean face=3DGillSans-Light>ONT-FAMILY: GillSans-Light">=3D"FONT-FAMILY: GillSans-Light">= > =3B+1 765 427 5484
>

s=3DEC_EC_EC_khtml-block-placeholder>
AN>
AN>

>
>
On 12 Jan 2009=2C at 01:44=2C Jay wrote:

le-interchange-newline> >
0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0= >)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B B= >ORDER-COLLAPSE: separate"> >
rdana">Is there a way in Modula-3 to declare that =3Ba type exists=2C a= >nd there are <=3B*external*>=3B instances of it=2C without "fully" decl= >aring it=2C so that no Modula-3 can instantiate it?
 =3B
I have d= >one this for sigset_t and sem_t=2C but they could erroneously be instantiat= >ed by Modula-3 and I'd like to remove that ability to mess up so easily.> =3B
(* This type is not declared correctly. It is only instantiate= >d in C code. *)
 =3B sigset_t =3D RECORD END=3B

(* This type = >is not declared correctly. It is only instantiated in C code. *)
 = >=3B sem_t =3D RECORD END=3B

In C I believe you can do this=2C like:<= >BR> =3B =3Btypedef struct foo foo_t=3B =3BC_Apple-converted-space> =3B
 =3B =3Bextern foo_t foo= >=3B =3B =3B
= > =3B
 =3Bvoid UseFoo(foo_t*)=3Berted-space> =3B
 =3B foo_t* GetFoo(void)=3B=3DEC_EC_EC_Apple-converted-space> =3B
 =3B
Thanks=2C<= >BR> =3B- Jay




<= >/DIV>
= >

V>
>= > >--_6117a048-9185-4c03-badb-ef8f93402268_-- From mika at async.caltech.edu Mon Jan 12 10:37:42 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 12 Jan 2009 01:37:42 -0800 Subject: [M3devel] Juno (X) networking problem on AMD64_FREEBSD In-Reply-To: Your message of "Mon, 12 Jan 2009 09:12:44 GMT." Message-ID: <200901120937.n0C9bgR5074988@camembert.async.caltech.edu> netobjd has similar problems. Hmm, yes, in both cases it is somehow related to listening on a port. In your X case it also sounds wrong. It should just check hname[0] against the DISPLAY env var. It doesn't need GetHostAddress. Mika Jay writes: >--_b0c10337-0e1c-414e-aae5-e611dcd4be8a_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >PPC_LINUX not PPC_DARWIN. >I think. >And at one point AMD64_LINUX (same machine as AMD64_FREEBSD=2C multiboot).I= > think I tested I386_OPENBSD Juno too and it worked=2CI don't remember. Oh= >=2C but that was in a VM=2C so different networking setup. >This is Trestle startup=2C seeing if there mightbe shared memory available = >between the X client and server. >If $DISPLAY is set=2C to specify the server=2C it wants to comparethat agai= >nst "current"=2C the client.You know=2C if I set DISPLAY=3D:0.0 or localhos= >t:0.0=2C don't penalize perf=2Cbut if it really is remote=2C then do penali= >ze perf. >/Something/ like that. >I hardly read the code.. > - Jay> To: jay.krell at cornell.edu> Date: Mon=2C 12 Jan 2009 01:06:30 -0800>= > From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3d= >evel] Juno (X) networking problem on AMD64_FREEBSD> > Jay=2C> > I think the= > problem here is actually in the caller. Why does a> caller need "GetHostAd= >dr()"? It is probably doing this for the> purpose of calling listen() or so= >me such thing. What the caller> probably *really* wants is INADDR_ANY=2C an= >d not the IP address of> some arbitrarily chosen interface on the host.> > = >I'm guessing it works on the Mac because the Mac libraries do> something co= >mplicated when you ask for the host's name (i.e.=2C they> somehow generate = >a hostname that always maps to the IP address of> an interface on the compu= >ter).> > Mika> > Jay writes:> >--_b00371fe-730b-4981-9051-a874361296d7_> >C= >ontent-Type: text/plain=3B charset=3D"iso-8859-1"> >Content-Transfer-Encodi= >ng: quoted-printable> >> >> >Do you know the right way?> >=3D20> >PPC_LINUX= > "just worked"=3D2C and I can check Solaris and Darwin.> >=3D20> >I don't w= >ant to edit /etc/hosts -- I use DHCP.> >Though DHCP has been bothering me -= >- only for some of my machines do names =3D> >resolve=3D2C so I end using I= >P addresses=3D2C which change sometimes=3D2C and I l=3D> >oop over them run= >ning ssh to all of them and "see what I get"=3D2C not ideal.> >=3D20> > - J= >ay> To: jay.krell at cornell.edu> Date: Sun=3D2C 11 Jan 2009 08:02:18 -0800>= >=3D> > From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re= >: [M3d=3D> >evel] Juno (X) networking problem on AMD64_FREEBSD> > This is a= > screwy thin=3D> >g in Modula-3. A bug I would call it.> > I've noticed a l= >ot of networking M=3D> >3 programs don't work right unless> the return valu= >e of Unix's "hostname" m=3D> >aps to a real IP address via> gethostbyname. = >I accomplish it in practice by=3D> > adding my hostname> to /etc/hosts.> > = >This is obviously not the right way =3D> >to fix it... > > Mika> > Jay writ= >es:> >--_9e67232c-a064-417d-879e-227a77e31=3D> >0f9_> >Content-Type: text/p= >lain=3D3B charset=3D3D"iso-8859-1"> >Content-Transfe=3D> >r-Encoding: quote= >d-printable> >> >> >Hi. Unix network programming question.=3D> >.> >AMD64_F= >REEBSD:> >$DISPLAY is set to point back to Cygwin host.It works =3D> >for P= >PC_LINUX.> >[jay at fbsdamd64a /cm3/bin]$ ./Juno> >****** runtime error:*=3D> = >>** Exception "IPError.FatalError" not in RAISES li=3D3D> >st*** file "../s= >rc/=3D> >common/IPError.m3"=3D3D2C line 27***> >Abort trap: 6 (core dumped)= >[jay at fbsdam=3D> >d64a /cm3/bin]$> >IP.m3:> >=3D3D20> >PROCEDURE GetHostAddr= >(): Address =3D3D3D V=3D> >AR hname: ARRAY [0..255] OF CHAR=3D3D3B =3D3D> >= > BEGIN LOCK mu DO IF Unix.getho=3D> >stname(ADR(hname[0])=3D3D2C BYTESIZE(h= >na=3D3D> >me)) # 0 THEN IPError.Die ()=3D3D=3D> >3B END=3D3D3B VAR h :=3D3D= >3D Unetdb.g=3D3D> >ethostbyname(ADR(hname[0]))=3D3D3B BEG=3D> >IN IF h =3D3= >D3D NIL THEN IPError.Die()=3D3D> >=3D3D3B END=3D3D3B RETURN GetAddress(=3D>= > >h)=3D3D3B END=3D3D3B END=3D3D3B END GetHos=3D3D> >tAddr=3D3D3B> >PROCEDUR= >E GetAddress=3D> > (ent: Unetdb.struct_hostent_star): Address =3D3D3D VAR u= >a=3D3D> >: Uin.struct_=3D> >in_addr=3D3D3B BEGIN <* ASSERT ent.h_length <= >=3D3D3D BYTESIZE(Addr=3D3D> >ess) *>=3D> > ua :=3D3D3D LOOPHOLE(ent.h_addr_= >list=3D3D2C UNTRACED =3D3D> >REF UNTRACED REF Ui=3D> >n.struct_in_addr)^^= >=3D3D3B RETURN LOOPHOLE(ua.s_addr=3D3D2C A=3D3D> >ddress)=3D3D3B=3D> > END = >GetAddress=3D3D3B> >=3D3D20> >gethostbyname is failing.> >=3D3D20> >Analogo= >u=3D> >s C code also fails:> >=3D3D20> >[jay at fbsdamd64a /cm3/bin]$ cat ~/5.= >c#include=3D> > #include #i=3D3D> >nclude #incl= >ude type=3D> >def struct hostent hostent_t=3D3D3B> >=3D3D20> >int = >main(){ char hostname[200]=3D> >=3D3D3B hostent_t* h=3D3D3B int i=3D3D3B> >= > i =3D3D3D gethostname(hostname=3D3D2C 200=3D> >)=3D3D3B assert(i =3D3D3D= >=3D3D3D 0)=3D3D3B printf("hostna=3D3D> >me: %s\n"=3D3D2C hostn=3D> >ame)=3D= >3D3B h =3D3D3D gethostbyname(hostname)=3D3D3B herror("foo")=3D3D3B=3D3D> > = >pri=3D> >ntf("%p %d %d\n"=3D3D2C h=3D3D2C errno=3D3D2C h_errno)=3D3D3B asse= >rt(h)=3D3D3B return=3D> > 0=3D3D3B}> >=3D3D20> >herror says "unknown host".= >> >Stack is:> > at ../src/run=3D> >time/ex_frame/RTExFrame.m3:58#13 0x00000= >00801a7f2b3 in RTH=3D3D> >ooks__Raise=3D> > (M3_AJWxb1_ex=3D3D3DError acces= >sing memory address 0x8000ffffd278: =3D3D> >Bad=3D> > address.) at ../src/r= >untime/common/RTHooks.m3:79#14 0x000000080169c8=3D3D> >=3D> >d3 in IPError_= >_Die () at ../src/common/IPError.m3:27#15 0x0000000801698a3e =3D> >=3D3D> >= >in IP__GetHostAddr (M3_BCxjPn__result=3D3D3DError accessing memory addr=3D>= > >ess 0x80=3D3D> >00ffffd338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x0= >0000=3D> >008012133d0=3D3D> > in XSharedMem__SameHost (M3_AQuuui_trsl=3D3D3= >DError accessi=3D> >ng memory address 0=3D3D> >x8000ffffd4d8: Bad address.)= > at ../src/xvbt/XShare=3D> >dMem.m3:96#17 0x000000=3D3D> >0801212ab7 in XSh= >aredMem__InitXClient (M3_AQuuu=3D> >i_v=3D3D3DError accessing memory=3D3D> = >> address 0x8000ffffd648: Bad address.) =3D> >at ../src/xvbt/XSharedMem.m3:= >29#1=3D3D> >8 0x0000000801211819 in XExtensions_=3D> >_InitXClient (M3_AQuu= >ui_xclient=3D3D3DError=3D3D> > accessing memory address 0x=3D> >8000ffffd7f= >8: Bad address.) at ../src/xvbt/X=3D3D> >Extensions.m3:14#19 0x000=3D> >000= >08012467a4 in XClientF__Connect (M3_Bd56fi_inst=3D3D> >=3D3D3D0x1879b=3D3D2= >C M=3D> >3_AQuuui_trsl=3D3D3D0x6) at ../src/xvbt/XClientF.m3:583---Typ=3D3D= >> >e =3D> > to continue=3D3D2C or q to quit---(More stack = >frames follow=3D3D> >..=3D> >.)(gdb)> >(* return TRUE if server and client = >are on same host *)PROCEDURE =3D> >SameHost (=3D3D> >trsl: XClient.T): BOOL= >EAN =3D3D3D VAR display :=3D3D3D DisplayH=3D> >=3D3D> >ost(trsl)=3D3D3B dis= >playAddr: IP.Address=3D3D3B BEGIN IF display =3D3D3D NI=3D> >L THE=3D3D> >N= > RETURN TRUE=3D3D3B END=3D3D3B> > TRY IF NOT IP.GetHostByName(displ=3D> >ay= >=3D3D2C displayAddr) THEN RETURN FA=3D3D> >LSE=3D3D3B END=3D3D3B RETURN dis= >playAd=3D> >dr =3D3D3D IP.GetHostAddr()=3D3D3B EXCEPT =3D3D> >| IP.Error = >=3D3D3D> RETURN FALSE=3D> >=3D3D3B END=3D3D3B END SameHost=3D3D3B> >=3D3D20= >> >Thoughts?> >=3D3D20> >Perhaps my n=3D> >etwork isn't setup well=3D3D2C l= >ike I should add the local machine =3D3D> >to /=3D> >etc/hosts.I think this= > can be made to fail gracefully though.It seems l=3D3D>=3D> > >ike it has n= >othing to do with AMD64_FREEBSD=3D3D2C but could have to do wit=3D> >h Fr= >=3D3D> >eeBSD.> >=3D3D20> >Seems like SocketPosix has nearly the exact same= >=3D> > code but appearsmore forgi=3D3D> >ving.. IOError instead of Fatal?> = >>=3D3D20> =3D> >>SocketPosix.m3:> >=3D3D20> >PROCEDURE GetHostAddr (): Addr= >ess RAISES {OSErro=3D> >r.E} =3D3D3D VAR host : AR=3D3D> >RAY [0..255] OF C= >HAR=3D3D3B info : Unetdb.struc=3D> >t_hostent_star=3D3D3B ua : U=3D3D> >in.= >struct_in_addr=3D3D3B BEGIN IF Unix.gethos=3D> >tname (ADR (host[0])=3D3D2C= > BYTESI=3D3D> >ZE (host)) # 0 THEN IOError (Unexpect=3D> >ed)=3D3D3B END=3D= >3D3B> > info :=3D3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3D3B =3D> >IF = >info =3D3D3D NIL TH=3D3D> >EN IOError (Unexpected)=3D3D3B END=3D3D3B <* ASS= >ERT i=3D> >nfo.h_length <=3D3D3D BYTESIZE =3D3D> >(Address) *>> > ua :=3D3D= >3D LOOPHOLE(info.=3D> >h_addr_list=3D3D2C UNTRACED REF UNT=3D3D> >RACED REF= > Uin.struct_in_addr)^^=3D3D3B=3D> > RETURN LOOPHOLE (ua.s_addr=3D3D2C Addre= >ss=3D3D> >)=3D3D3B END GetHostAddr=3D3D3B> =3D> >>=3D3D20> >=3D3D20> >It is= > again disappointing to see such code duplication.> >=3D> >=3D3D20> >=3D3D2= >0> >I guess SameHost can duplicate the logic to predict the err=3D> >or sta= >te and ret=3D3D> >urn false upon error?> >Duplicating the logic for a t=3D>= > >hird time. :(> >=3D3D20> > - Jay=3D3D> >> >--_9e67232c-a064-417d-879e-227= >a77e31=3D> >0f9_> >Content-Type: text/html=3D3B charset=3D3D"iso-8859-1"> >= >Content-Transfer=3D> >-Encoding: quoted-printable> >> >> >> >tyle>> >.hmmessage P> =3D> >>{> >margin:0px=3D3D3B> >padding:0px> >}> >body= >.hmmessage> >{> >font-size: 10=3D> >pt=3D3D3B> >font-family:Verdana> >}> ><= >/style>> >> > >mmessage'>> >Hi. Unix network= > programming question..
> >
AMD64_FREEBS=3D> >D:
> >
$DISPLAY i= >s set to point back to Cygwin host.
It works for =3D> >PPC_LINUX=3D3D> >= >.
> >
[jay at fbsdamd64a /cm3/bin]$ ./Juno
> >
***<=3D> >BR>*** ru= >ntime error:
*** =3D3D3B =3D3D3B =3D3D3B Exception "IPE=3D> = >>=3D3D> >rror.FatalError" not in RAISES list
*** =3D3D3B =3D3D3B= > =3D> >=3D3D3B file "..=3D3D> >/src/common/IPError.m3"=3D3D2C line 27R>***
> >
A=3D> >bort trap: 6 (core dumped)
[jay at fbsdamd64a /cm3/b= >in]$
> >
IP.m3: >R>> > =3D3D3B
> >PROCEDURE GetHostAddr(= >): Address =3D3D3D
 =3D3D3B =3D> >VAR hname: ARRAY [0..255] =3D3D> O= >F CHAR=3D3D3B
 =3D3D3B BEGIN
 =3D3D=3D> >3B =3D3D3B = >=3D3D3B LOCK mu DO
&nbs=3D3D> >p=3D3D3B =3D3D3B =3D3D3B&n=3D> >b= >sp=3D3D3B =3D3D3B IF Unix.gethostname(ADR(hname[0])=3D3D2C B=3D3D> >YTE= >SIZE(hn=3D> >ame)) # 0 THEN
 =3D3D3B =3D3D3B =3D3D3B =3D= >3D3B =3D3D3B =3D> >=3D3D> >=3D3D3B =3D3D3B IPError.Die ()=3D3D3= >B
 =3D3D3B =3D3D3B =3D3D3B=3D> > =3D3D3B =3D3D3B E= >=3D3D> >ND=3D3D3B
 =3D3D3B =3D3D3B =3D3D3B =3D> >=3D3D3B= > =3D3D3B VAR h :=3D3D3D Unetdb.gethost=3D3D> >byname(ADR(hname[0]))=3D3= >D3B=3D> > BEGIN
 =3D3D3B =3D3D3B =3D3D3B =3D3D3B =3D= >3D3B&=3D3D> >nbsp=3D3D3=3D> >B =3D3D3B IF h =3D3D3D NIL THEN IPError.Di= >e()=3D3D3B END=3D3D3B
 =3D3D3B&n=3D> >bsp=3D3D> >=3D3D3B =3D3D3B= > =3D3D3B =3D3D3B =3D3D3B =3D3D3B RETURN Get=3D> >Address(h)= >=3D3D3B
&nbs=3D3D> >p=3D3D3B =3D3D3B =3D3D3B =3D3D3B =3D= >3D3B=3D> > END=3D3D3B
 =3D3D3B =3D3D3B =3D3D3B END=3D3D> >= >=3D3D3B
 =3D3D3B EN=3D> >D GetHostAddr=3D3D3B
> >
PROCEDURE Ge= >tAddress (ent: Unetdb.struct_hoste=3D> >nt_star): Address =3D3D3D
=3D3D>= > > =3D3D3B VAR ua: Uin.struct_in_addr=3D3D3B=3D> >
 =3D3D3B BEGI= >N
 =3D3D3B =3D3D> >=3D3D3B =3D3D3B <=3D3D3B* ASSE=3D> >RT = >ent.h_length <=3D3D3B=3D3D3D BYTESIZE(Address) *>=3D3D3B=3D3D> >
&nb= >sp=3D3D=3D> >3B =3D3D3B =3D3D3B ua :=3D3D3D LOOPHOLE(ent.h_addr_lis= >t=3D3D2C
 =3D3D>=3D> > >=3D3D3B =3D3D3B =3D3D3B =3D3D3B&= >nbsp=3D3D3B =3D3D3B =3D3D3B =3D3D=3D> >3B =3D3D3B =3D3D= >3B=3D3D> > =3D3D3B =3D3D3B =3D3D3B =3D3D3B =3D> >=3D3D3= >B =3D3D3B =3D3D3B =3D3D3B =3D3D3B UN=3D3D> >TRACED REF UNTR= >ACED R=3D> >EF Uin.struct_in_addr)^^=3D3D3B
 =3D3D3B =3D3D3B&nbs= >p=3D3D> >=3D3D3B RETUR=3D> >N LOOPHOLE(ua.s_addr=3D3D2C Address)=3D3D3B
= > =3D3D3B END GetAddress=3D3D3B<=3D> >=3D3D> >BR>> > =3D3D3B
> >g= >ethostbyname is failing.
> >
 =3D3D3B=3D> >
> >Analogous C cod= >e also fails:
> > =3D3D3B
> >
[jay at fbsdamd=3D> >64a /cm3/bin]$= > cat ~/5.c
#include <=3D3D3Bassert.h>=3D3D3B >R>#inc=3D> >lu= >de <=3D3D3Bnetdb.h>=3D3D3B
#include <=3D3D3Bstdio.h>=3D3D3B
#= >includ=3D> >e =3D3D> ><=3D3D3Berrno.h>=3D3D3B
typedef struct hostent= > hostent_t=3D3D3B >>> > =3D3D3B
> >int main()
{
 = >=3D3D3Bchar hostname[200]=3D3D3B >R> =3D3D3Bhostent_t* h=3D3D3B= >=3D3D> >
 =3D3D3Bint i=3D3D3B
> > =3D3D3=3D> >Bi =3D3D3D geth= >ostname(hostname=3D3D2C 200)=3D3D3B
 =3D3D3Bassert(i =3D3D3D=3D3D=3D= >> >3D 0)=3D3D> >=3D3D3B
 =3D3D3Bprintf("hostname: %s\n"=3D3D2C hostn= >ame)=3D3D3B >R> =3D3D3Bh =3D3D3D get=3D3D> >hostbyname(hostname)= >=3D3D3B
 =3D3D3Bherror(=3D> >"foo")=3D3D3B
 =3D3D3Bprintf("%p= > %=3D3D> >d %d\n"=3D3D2C h=3D3D2C errno=3D3D2C h=3D> >_errno)=3D3D3B
&nb= >sp=3D3D3Bassert(h)=3D3D3B
 =3D3D3Bret=3D3D> >urn 0=3D3D3B >R>}= >
> > =3D3D3B
> >herror says "unknown host".
> >
Stack is:<= >=3D> >BR>> > =3D3D3B =3D3D3B =3D3D3B at ../src/runtime/ex_frame= >/RTExFrame.m=3D> >3:58
#13 =3D3D> >0x0000000801a7f2b3 in RTHooks__Raise = >(M3_AJWxb1_ex=3D3D3DEr=3D> >ror accessing memory=3D3D> > ad
dress 0x8000= >ffffd278: Bad address.
) >> =3D3D3B =3D3D3B =3D3D3B = >=3D3D> >at ../src/runtime/common/RTHooks.m3:7=3D> >9
#14 0x000000080169c= >8d3 in IPError=3D3D> >__Die () at ../src/common/IPErr=3D> >or.m3:27
#15 = >0x0000000801698a3e in IP__Ge=3D3D> >tHostAddr (M3_BCxjPn__res=3D> ult=3D3D3= >DError accessing mem
ory address 0x8000fff=3D3D> >fd338: Bad addres=3D> = >>s.
)
 =3D3D3B =3D3D3B =3D3D3B at ../src/POSIX/IP.m3:=3D3= >D> >82 >>#16 0x00000008012133d0 in XSharedMem__SameHost (M3_AQuuui_t= >rsl=3D3D3DErro=3D3D=3D> >> >r accessing m
emory address 0x8000ffffd4d8: = >Bad address.
)
&nbs=3D> >p=3D3D> >=3D3D3B =3D3D3B =3D3D3B at = >../src/xvbt/XSharedMem.m3:96
#17 0x0=3D> >000000801212a=3D3D> >b7 in XSh= >aredMem__InitXClient (M3_AQuuui_v=3D3D3DError acc=3D> >essing m
emory ad= >d=3D3D> >ress 0x8000ffffd648: Bad address.
)
 =3D> >=3D3D3B = >=3D3D3B =3D3D3B at ../sr=3D3D> >c/xvbt/XSharedMem.m3:29
#18 0x00=3D>= > >00000801211819 in XExtensions__InitXClie=3D3D> >nt (M3_AQuuui_xclient=3D3= >D3DErr=3D> >or acce
ssing memory address 0x8000ffffd7f8: =3D3D> >Bad add= >ress.
)
=3D> > =3D3D3B =3D3D3B =3D3D3B at ../src/xvbt/XEx= >tensions.m3=3D3D> >:14
#1=3D> >9 0x00000008012467a4 in XClientF__Connect= > (M3_Bd56fi_inst=3D3D3D0x1879=3D3D> >b=3D> >=3D3D2C
 =3D3D3B =3D= >3D3B =3D3D3B M3_AQuuui_trsl=3D3D3D0x6) at ../src/x=3D> >vbt/XClie=3D3D>= > >ntF.m3:583
---Type <=3D3D3Breturn>=3D3D3B to continue=3D3D2=3D> >C= > or q <=3D3D3Breturn&g=3D3D> >t=3D3D3B to quit---
(More stack frames f= >ollow=3D> >...)
(gdb)
> >
(* return TRUE if server and client are = >on same hos=3D> >t *)
PROCEDURE Sa=3D3D> >meHost (trsl: XClient.T): BOOL= >EAN =3D3D3D
 =3D> >=3D3D3B VAR
 =3D3D3B =3D3D3B&n=3D3D> >= >bsp=3D3D3B display =3D3D3B =3D3D=3D> >3B =3D3D3B =3D3D3B&nb= >sp=3D3D3B =3D3D3B =3D3D3B =3D3D> >=3D3D3B =3D> >=3D3D3B&nbs= >p=3D3D3B =3D3D3B =3D3D3B =3D3D3B =3D3D3B =3D3D3B = >=3D3D3B=3D> :=3D3D3D Di=3D3D> >splayHost(trsl)=3D3D3B
 =3D3D3B = >=3D3D3B =3D3D3B disp=3D> >layAddr: IP.Address=3D3D3B >R> = >=3D3D3B BEGIN
 =3D3D3B =3D3D3B&=3D> >nbsp=3D3D3B IF display =3D3= >D3D NIL THEN RETURN=3D3D> > TRUE=3D3D3B END=3D3D3B
> >&=3D> >nbsp=3D3D3B= > =3D3D3B =3D3D3B TRY
 =3D3D3B =3D3D3B =3D3D3B = >=3D3D=3D> >3B =3D3D3B IF=3D3D> > NOT IP.GetHostByName(display=3D3D2C di= >splayAddr) THEN R=3D> >ETURN FALSE=3D3D3B END=3D3D3B >R> =3D3D3= >B =3D3D3B =3D3D3B =3D3D3B=3D> > =3D3D3B RETURN displayAddr = >=3D3D3D IP.GetHos=3D3D> >tAddr()=3D3D3B
 =3D3D=3D> >3B =3D3D3B&n= >bsp=3D3D3B EXCEPT
 =3D3D3B =3D3D3B =3D3D3B |=3D3D> > IP.=3D>= > >Error =3D3D3D>=3D3D3B RETURN FALSE=3D3D3B
 =3D3D3B =3D3D3B&n= >bsp=3D3D3B END=3D> >=3D3D3B
&=3D3D> >nbsp=3D3D3B END SameHost=3D3D3B
= >> > =3D3D3B
> >Thoughts=3D> >?
> > =3D3D3B
> >
Perhaps = >my network isn't setup well=3D3D2C like =3D> >I should add the local mach= >=3D3D> >ine to /etc/hosts.
I think this can be =3D> >made to fail gracef= >ully though. >R>It seems like it has nothing to do=3D> > with AMD64= >_FREEBSD=3D3D2C but could have t=3D3D> >o do with FreeBSD.
> > >>= > =3D3D3B
> >Seems like SocketPosix has nearly the exact same code bu= >t=3D> > appears
more f=3D3D> >orgiving.. IOError instead of Fatal?
> = >> =3D3D=3D> >3B
> >
SocketPosix.m3:
> > =3D3D3B
> >
= >PROCEDURE GetHostAd=3D> >dr (): Address
 =3D3D3B RAISES {OSError.E} = >=3D3D3D >> =3D3D3B V=3D> >AR
 =3D3D3B =3D3D3B = >=3D3D3B host : ARRAY [0..255] OF CHAR=3D3D3B<=3D3D=3D> >> >BR> =3D3D3B&= >nbsp=3D3D3B =3D3D3B info : Unetdb.struct_hostent_star=3D3D3B=3D> >
&= >nbsp=3D3D> >=3D3D3B =3D3D3B =3D3D3B ua =3D3D3B =3D3D3B : Ui= >n.struc=3D> >t_in_addr=3D3D3B
 =3D3D3B =3D3D> >BEGIN
 =3D3D3B= > =3D3D3B =3D3D3B =3D> >IF Unix.gethostname (ADR (host[0])=3D3D2C BY= >T=3D3D> >ESIZE (host)) # 0 THEN
=3D> > =3D3D3B =3D3D3B =3D3D= >3B =3D3D3B =3D3D3B IOError =3D3D> >(Unexpecte=3D> >d)=3D3D3B
&nb= >sp=3D3D3B =3D3D3B =3D3D3B END=3D3D3B
> > =3D3D3B =3D3D= >=3D> >3B =3D3D3B info :=3D3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3= >D3B<=3D3D> >BR=3D> >> =3D3D3B =3D3D3B =3D3D3B IF info =3D3D3D N= >IL THEN IOError (Unexpected)=3D> >=3D3D3B EN=3D3D> >D=3D3D3B
 =3D3D3= >B =3D3D3B =3D3D3B <=3D3D3B* ASSERT inf=3D> >o.h_length <=3D3D3B= >=3D3D3D BYT=3D3D> >ESIZE (Address) *>=3D3D3B
> > =3D3D3=3D> >B&nbs= >p=3D3D3B =3D3D3B ua :=3D3D3D LOOPHOLE(info.h_addr_list=3D3D2C
 = >=3D3D3=3D> >B&n=3D3D> >bsp=3D3D3B =3D3D3B =3D3D3B =3D3D3B = >=3D3D3B =3D3D3B =3D3D=3D> >3B =3D3D3B =3D3D3B =3D3D> >= >=3D3D3B =3D3D3B =3D3D3B =3D3D3B =3D> >=3D3D3B =3D3D3B&n= >bsp=3D3D3B =3D3D3B UNTRACED REF UN=3D3D> >TRACED REF Uin.str=3D> >uct_i= >n_addr)^^=3D3D3B
 =3D3D3B =3D3D3B =3D3D3B RETURN LOOP=3D3D> = >>HOLE=3D> > (ua.s_addr=3D3D2C Address)=3D3D3B
 =3D3D3B END GetHostAd= >dr=3D3D3B
> >&nb=3D> >sp=3D3D3B
> > =3D3D3B
> >It is again dis= >appointing to see such code d=3D> >uplication.
> > =3D3D3B
> >&nb= >sp=3D3D3B
> >I guess =3D3D3BSameHo=3D> >st can duplicate the logic t= >o predict the error state =3D3D> >and return fals=3D> >e =3D3D3Bupon er= >ror?
> >Duplicating the logic for a third time. :(
=3D> >> > =3D3= >D3B
> >
 =3D3D3B- Jay

> >=3D3D> >> >--=3D> >= >_9e67232c-a064-417d-879e-227a77e310f9_--=3D> >> >--_b00371fe-730b-4981-9051= >-a874361296d7_> >Content-Type: text/html=3B charset=3D"iso-8859-1"> >Conten= >t-Transfer-Encoding: quoted-printable> >> >> >> >> >> >ass=3D3D'hmmessage'>> >Do you know the right way?
> > =3D3B
> >PP= >C_LINUX "just worked"=3D2C and I can check Solaris and Darwin.
> > = >=3D3B
> >I don't want to edit /etc/hosts -- I use DHCP.
> >Though DHC= >P has been bothering me -- only for some of my machines do names =3D> >reso= >lve=3D2C so I end using IP addresses=3D2C which change sometimes=3D2C and I= > l=3D> >oop over them running ssh to all of them and "see what I get"=3D2C = >not ideal.=3D> >
> > =3D3B
> > =3D3B- Jay


>=3D3B= > To: jay.krell at cornell.edu
>=3D3B Date: S=3D> >un=3D2C 11 Jan 2009 08:= >02:18 -0800
>=3D3B From: mika at async.caltech.edu
=3D> >>=3D3B CC: = >m3devel at elegosoft.com
>=3D3B Subject: Re: [M3devel] Juno (X) =3D> >net= >working problem on AMD64_FREEBSD
>=3D3B
>=3D3B This is a screwy = >t=3D> >hing in Modula-3. A bug I would call it.
>=3D3B
>=3D3B I'= >ve noticed =3D> >a lot of networking M3 programs don't work right unless>>=3D3B the retur=3D> >n value of Unix's "hostname" maps to a real IP add= >ress via
>=3D3B gethos=3D> >tbyname. I accomplish it in practice by ad= >ding my hostname
>=3D3B to /et=3D> >c/hosts.
>=3D3B
>=3D3B = >This is obviously not the right way to fix it=3D> >...
>=3D3B
>= >=3D3B Mika
>=3D3B
>=3D3B Jay writes:
>=3D3B &=3D> >gt=3D3B-= >-_9e67232c-a064-417d-879e-227a77e310f9_
>=3D3B >=3D3BContent-Type:= >=3D> > text/plain=3D3B charset=3D3D"iso-8859-1"
>=3D3B >=3D3BContent= >-Transfer-Enco=3D> >ding: quoted-printable
>=3D3B >=3D3B
>=3D3B= > >=3D3B
>=3D3B >=3D3BHi=3D> >. Unix network programming question..= >
>=3D3B >=3D3BAMD64_FREEBSD:
>=3D> >=3D3B >=3D3B$DISPLAY is s= >et to point back to Cygwin host.It works for PPC_LIN=3D> >UX.
>=3D3B &= >gt=3D3B[jay at fbsdamd64a /cm3/bin]$ ./Juno
>=3D3B >=3D3B*****=3D> >* r= >untime error:*** Exception "IPError.FatalError" not in RAISES li=3D3D
&= >=3D> >gt=3D3B >=3D3Bst*** file "../src/common/IPError.m3"=3D3D2C line 27*= >**
>=3D3B=3D> > >=3D3BAbort trap: 6 (core dumped)[jay at fbsdamd64a /cm= >3/bin]$
>=3D3B >=3D> >=3D3BIP.m3:
>=3D3B >=3D3B=3D3D20
>= >=3D3B >=3D3BPROCEDURE GetHostAddr(): Ad=3D> >dress =3D3D3D VAR hname: ARR= >AY [0..255] OF CHAR=3D3D3B =3D3D
>=3D3B >=3D3B BEG=3D> >IN LOCK mu D= >O IF Unix.gethostname(ADR(hname[0])=3D3D2C BYTESIZE(hna=3D3D
>=3D> >= >=3D3B >=3D3Bme)) # 0 THEN IPError.Die ()=3D3D3B END=3D3D3B VAR h :=3D3D3D= > Unetdb.g=3D> >=3D3D
>=3D3B >=3D3Bethostbyname(ADR(hname[0]))=3D3D3B= > BEGIN IF h =3D3D3D NIL T=3D> >HEN IPError.Die()=3D3D
>=3D3B >=3D3B= >=3D3D3B END=3D3D3B RETURN GetAddress(h)=3D3D=3D> >3B END=3D3D3B END=3D3D3B = >END GetHos=3D3D
>=3D3B >=3D3BtAddr=3D3D3B
>=3D3B >=3D> >=3D3B= >PROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Address =3D3D3D VA= >=3D> >R ua=3D3D
>=3D3B >=3D3B: Uin.struct_in_addr=3D3D3B BEGIN <= >=3D3B* ASSERT ent.=3D> >h_length <=3D3B=3D3D3D BYTESIZE(Addr=3D3D
>= >=3D3B >=3D3Bess) *>=3D3B ua :=3D3D3=3D> >D LOOPHOLE(ent.h_addr_list=3D3= >D2C UNTRACED =3D3D
>=3D3B >=3D3BREF UNTRACED R=3D> >EF Uin.struct_in= >_addr)^^=3D3D3B RETURN LOOPHOLE(ua.s_addr=3D3D2C A=3D3D
>=3D3B=3D> > &= >gt=3D3Bddress)=3D3D3B END GetAddress=3D3D3B
>=3D3B >=3D3B=3D3D20
= >>=3D3B >=3D> >=3D3Bgethostbyname is failing.
>=3D3B >=3D3B=3D3D2= >0
>=3D3B >=3D3BAnalogou=3D> >s C code also fails:
>=3D3B >=3D= >3B=3D3D20
>=3D3B >=3D3B[jay at fbsdamd64a =3D> >/cm3/bin]$ cat ~/5.c#in= >clude <=3D3Bassert.h>=3D3B#include <=3D3Bnetdb.h>=3D> >=3D3B#i=3D3D= >
>=3D3B >=3D3Bnclude <=3D3Bstdio.h>=3D3B#include <=3D3Berrno.h= >&g=3D> >t=3D3Btypedef struct hostent hostent_t=3D3D3B
>=3D3B >=3D3B= >=3D3D20
>=3D3B &=3D> >gt=3D3Bint main(){ char hostname[200]=3D3D3B hos= >tent_t* h=3D3D3B int i=3D3D3B
&g=3D> >t=3D3B >=3D3B i =3D3D3D gethostn= >ame(hostname=3D3D2C 200)=3D3D3B assert(i =3D3D3D=3D3D3D=3D> > 0)=3D3D3B pri= >ntf("hostna=3D3D
>=3D3B >=3D3Bme: %s\n"=3D3D2C hostname)=3D3D3B h = >=3D> >=3D3D3D gethostbyname(hostname)=3D3D3B herror("foo")=3D3D3B=3D3D
&= >gt=3D3B >=3D3B p=3D> >rintf("%p %d %d\n"=3D3D2C h=3D3D2C errno=3D3D2C h_e= >rrno)=3D3D3B assert(h)=3D3D3B retu=3D> >rn 0=3D3D3B}
>=3D3B >=3D3B= >=3D3D20
>=3D3B >=3D3Bherror says "unknown host"=3D> >.
>=3D3B &= >gt=3D3BStack is:
>=3D3B >=3D3B at ../src/runtime/ex_frame/RTE=3D> >x= >Frame.m3:58#13 0x0000000801a7f2b3 in RTH=3D3D
>=3D3B >=3D3Books__Rai= >se (M=3D> >3_AJWxb1_ex=3D3D3DError accessing memory address 0x8000ffffd278:= > =3D3D
>=3D> >=3D3B >=3D3BBad address.) at ../src/runtime/common/RTH= >ooks.m3:79#14 0x0000000=3D> >80169c8=3D3D
>=3D3B >=3D3Bd3 in IPError= >__Die () at ../src/common/IPError.m=3D> >3:27#15 0x0000000801698a3e =3D3DR>>=3D3B >=3D3Bin IP__GetHostAddr (M3_BCxjP=3D> >n__result=3D3D3DError = >accessing memory address 0x80=3D3D
>=3D3B >=3D3B00ffff=3D> >d338: Ba= >d address.) at ../src/POSIX/IP.m3:82#16 0x00000008012133d0=3D3D
&g=3D> >= >t=3D3B >=3D3B in XSharedMem__SameHost (M3_AQuuui_trsl=3D3D3DError accessi= >ng mem=3D> >ory address 0=3D3D
>=3D3B >=3D3Bx8000ffffd4d8: Bad addre= >ss.) at ../src/xvb=3D> >t/XSharedMem.m3:96#17 0x000000=3D3D
>=3D3B >= >=3D3B0801212ab7 in XSharedMem_=3D> >_InitXClient (M3_AQuuui_v=3D3D3DError a= >ccessing memory=3D3D
>=3D3B >=3D3B ad=3D> >dress 0x8000ffffd648: Bad= > address.) at ../src/xvbt/XSharedMem.m3:29#1=3D3D >>>=3D3B >=3D3= >B8 0x0000000801211819 in XExtensions__InitXClient (M3_AQuuui_x=3D> >client= >=3D3D3DError=3D3D
>=3D3B >=3D3B accessing memory address 0x8000ffffd= >7f=3D> >8: Bad address.) at ../src/xvbt/X=3D3D
>=3D3B >=3D3BExtensio= >ns.m3:14#19 0x=3D> >00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst= >=3D3D
>=3D3B >=3D3B=3D> >=3D3D3D0x1879b=3D3D2C M3_AQuuui_trsl=3D3D3D= >0x6) at ../src/xvbt/XClientF.m3:583---=3D> >Typ=3D3D
>=3D3B >=3D3Be = ><=3D3Breturn>=3D3B to continue=3D3D2C or q <=3D3Bret=3D> >urn>=3D3B= > to quit---(More stack frames follow=3D3D
>=3D3B >=3D3B...)(gdb)<=3D= >> >BR>>=3D3B >=3D3B(* return TRUE if server and client are on same host= > *)PROC=3D> >EDURE SameHost (=3D3D
>=3D3B >=3D3Btrsl: XClient.T): BO= >OLEAN =3D3D3D VAR dis=3D> >play :=3D3D3D DisplayH=3D3D
>=3D3B >=3D3B= >ost(trsl)=3D3D3B displayAddr: IP.Addr=3D> >ess=3D3D3B BEGIN IF display =3D3= >D3D NIL THE=3D3D
>=3D3B >=3D3BN RETURN TRUE=3D3D=3D> >3B END=3D3D3B<= >BR>>=3D3B >=3D3B TRY IF NOT IP.GetHostByName(display=3D3D2C displ=3D> >= >ayAddr) THEN RETURN FA=3D3D
>=3D3B >=3D3BLSE=3D3D3B END=3D3D3B RETUR= >N displayA=3D> >ddr =3D3D3D IP.GetHostAddr()=3D3D3B EXCEPT =3D3D
>=3D3= >B >=3D3B| IP.Error =3D3D3D=3D> >>=3D3B RETURN FALSE=3D3D3B END=3D3D3B E= >ND SameHost=3D3D3B
>=3D3B >=3D3B=3D3D20 >R>>=3D3B >=3D3BTh= >oughts?
>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3BPerhaps my n=3D> >e= >twork isn't setup well=3D3D2C like I should add the local machine =3D3D
= >>=3D> >=3D3B >=3D3Bto /etc/hosts.I think this can be made to fail grace= >fully though.=3D> >It seems l=3D3D
>=3D3B >=3D3Bike it has nothing t= >o do with AMD64_FREEBSD=3D> >=3D3D2C but could have to do with Fr=3D3D
&= >gt=3D3B >=3D3BeeBSD.
>=3D3B >=3D> >=3D3B=3D3D20
>=3D3B >=3D= >3BSeems like SocketPosix has nearly the exact same c=3D> >ode but appearsmo= >re forgi=3D3D
>=3D3B >=3D3Bving.. IOError instead of Fata=3D> >l?>>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3BSocketPosix.m3:
>=3D3B &= >gt=3D3B=3D> >=3D3D20
>=3D3B >=3D3BPROCEDURE GetHostAddr (): Address = >RAISES {OSError.E} =3D> >=3D3D3D VAR host : AR=3D3D
>=3D3B >=3D3BRAY= > [0..255] OF CHAR=3D3D3B info : Une=3D> >tdb.struct_hostent_star=3D3D3B ua = >: U=3D3D
>=3D3B >=3D3Bin.struct_in_addr=3D3D=3D> >3B BEGIN IF Unix.g= >ethostname (ADR (host[0])=3D3D2C BYTESI=3D3D
>=3D3B >=3D3B=3D> >ZE (= >host)) # 0 THEN IOError (Unexpected)=3D3D3B END=3D3D3B
>=3D3B >=3D3B= > inf=3D> >o :=3D3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3D3B IF info = >=3D3D3D NIL TH=3D3D<=3D> >BR>>=3D3B >=3D3BEN IOError (Unexpected)=3D3D3= >B END=3D3D3B <=3D3B* ASSERT info.h=3D> >_length <=3D3B=3D3D3D BYTESIZE = >=3D3D
>=3D3B >=3D3B(Address) *>=3D3B
>=3D> >=3D3B >=3D3B ua= > :=3D3D3D LOOPHOLE(info.h_addr_list=3D3D2C UNTRACED REF UNT=3D3D
=3D> >&= >gt=3D3B >=3D3BRACED REF Uin.struct_in_addr)^^=3D3D3B RETURN LOOPHOLE (ua.= >s_add=3D> >r=3D3D2C Address=3D3D
>=3D3B >=3D3B)=3D3D3B END GetHostAd= >dr=3D3D3B
>=3D3B >=3D> >=3D3B=3D3D20
>=3D3B >=3D3B=3D3D20
= >>=3D3B >=3D3BIt is again disappointing to=3D> > see such code duplicati= >on.
>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B=3D3D20
=3D> >>=3D= >3B >=3D3BI guess SameHost can duplicate the logic to predict the error = >=3D> >state and ret=3D3D
>=3D3B >=3D3Burn false upon error?
>= >=3D3B >=3D3BDupl=3D> >icating the logic for a third time. :(
>=3D3B = >>=3D3B=3D3D20
>=3D3B >=3D> >=3D3B - Jay=3D3D
>=3D3B >=3D3B<= >BR>>=3D3B >=3D3B--_9e67232c-a064-417d-879e-22=3D> >7a77e310f9_
>= >=3D3B >=3D3BContent-Type: text/html=3D3B charset=3D3D"iso-8859-=3D> >1"R>>=3D3B >=3D3BContent-Transfer-Encoding: quoted-printable
>=3D3B = >&g=3D> >t=3D3B
>=3D3B >=3D3B<=3D3Bhtml>=3D3B
>=3D3B >=3D3= >B<=3D3Bhead>=3D3B
&=3D> >gt=3D3B >=3D3B<=3D3Bstyle>=3D3B
&g= >t=3D3B >=3D3B.hmmessage P
>=3D3B >=3D3B=3D> >{
>=3D3B >=3D3= >Bmargin:0px=3D3D3B
>=3D3B >=3D3Bpadding:0px
>=3D3B >=3D> >=3D= >3B}
>=3D3B >=3D3Bbody.hmmessage
>=3D3B >=3D3B{
>=3D3B &g= >t=3D3Bfont-=3D> >size: 10pt=3D3D3B
>=3D3B >=3D3Bfont-family:Verdana<= >BR>>=3D3B >=3D3B}
&g=3D> >t=3D3B >=3D3B<=3D3B/style>=3D3B
&= >gt=3D3B >=3D3B<=3D3B/head>=3D3B
>=3D3B &=3D> >gt=3D3B<=3D3Bbod= >y class=3D3D3D'hmmessage'>=3D3B
>=3D3B >=3D3BHi. Unix networ=3D> >= >k programming question..<=3D3BBR>=3D3B
>=3D3B >=3D3B<=3D3BBR&g= >t=3D3BAMD64_=3D> >FREEBSD:<=3D3BBR>=3D3B
>=3D3B >=3D3B<=3D3BBR= >>=3D3B$DISPLAY is set to poi=3D> >nt back to Cygwin host.<=3D3BBR>=3D= >3BIt works for PPC_LINUX=3D3D
>=3D3B &g=3D> >t=3D3B.<=3D3BBR>=3D3B= >
>=3D3B >=3D3B<=3D3BBR>=3D3B[jay at fbsdamd64a /cm3/bin]=3D> >$ ./J= >uno<=3D3BBR>=3D3B
>=3D3B >=3D3B<=3D3BBR>=3D3B***<=3D3BBR&g= >t=3D3B*** r=3D> >untime error:<=3D3BBR>=3D3B***&=3D3Bnbsp=3D3D3B&= >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D> >=3D3D3B Exception "IPE=3D3D
>=3D3B = >>=3D3Brror.FatalError" not in RAISES list=3D> ><=3D3BBR>=3D3B***&= >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B file "..=3D> >=3D3= >D
>=3D3B >=3D3B/src/common/IPError.m3"=3D3D2C line 27<=3D3BBR>= >=3D3B***&l=3D> >t=3D3BBR>=3D3B
>=3D3B >=3D3B<=3D3BBR>=3D3BAbor= >t trap: 6 (core dumped)<=3D> >=3D3BBR>=3D3B[jay at fbsdamd64a /cm3/bin]$&l= >t=3D3BBR>=3D3B
>=3D3B >=3D3B<=3D3BB=3D> >R>=3D3BIP.m3:<=3D3B= >BR>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B<=3D> = >>BR>>=3D3B >=3D3BPROCEDURE GetHostAddr(): Address =3D3D3D<=3D3BBR>= >=3D3B&=3D3B=3D> >nbsp=3D3D3B VAR hname: ARRAY [0..255] =3D3D
>=3D3B= > OF CHAR=3D3D3B<=3D3BBR>=3D> >=3D3B&=3D3Bnbsp=3D3D3B BEGIN<=3D3BBR= >>=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D> >=3D3Bnbsp=3D3D3B = >LOCK mu DO<=3D3BBR>=3D3B&=3D3Bnbs=3D3D
>=3D3B >=3D3Bp=3D3D3B&= >a=3D> >mp=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bn= >bsp=3D3D3B IF Unix.geth=3D> >ostname(ADR(hname[0])=3D3D2C B=3D3D
>=3D3= >B >=3D3BYTESIZE(hname)) # 0 THEN<=3D> >=3D3BBR>=3D3B&=3D3Bnbsp=3D3= >D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B=3D> >&= >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D
>=3D3B >=3D3B=3D3D3B&=3D3Bnbsp= >=3D3D3B IPErro=3D> >r.Die ()=3D3D3B<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B&a= >mp=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B=3D> >&=3D3Bnbsp=3D3D3B&=3D3Bnb= >sp=3D3D3B E=3D3D
>=3D3B >=3D3BND=3D3D3B<=3D3BBR>=3D3B=3D> >&= >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3= >B&=3D3Bnbsp=3D> >=3D3D3B VAR h :=3D3D3D Unetdb.gethost=3D3D
>=3D3B = >>=3D3Bbyname(ADR(hname[0]))=3D> >=3D3D3B BEGIN<=3D3BBR>=3D3B&=3D3B= >nbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&a=3D> >mp=3D3Bnbsp=3D3D= >3B&=3D3Bnbsp=3D3D3B&=3D3B=3D3D
>=3D3B >=3D3Bnbsp=3D3D3B&=3D= >3Bnb=3D> >sp=3D3D3B IF h =3D3D3D NIL THEN IPError.Die()=3D3D3B END=3D3D3B&l= >t=3D3BBR>=3D3B&=3D> >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D
>=3D3B &g= >t=3D3B=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D> >=3D3D3B&=3D3Bnbsp=3D= >3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B RETURN GetAddress(h)=3D> >=3D3= >D3B<=3D3BBR>=3D3B&=3D3Bnbs=3D3D
>=3D3B >=3D3Bp=3D3D3B&=3D3= >Bnbsp=3D3D3B&=3D> >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3= >D3B END=3D3D3B<=3D3BBR>=3D3B&=3D3Bn=3D> >bsp=3D3D3B&=3D3Bnbsp=3D3= >D3B&=3D3Bnbsp=3D3D3B END=3D3D
>=3D3B >=3D3B=3D3D3B<=3D3B=3D> >B= >R>=3D3B&=3D3Bnbsp=3D3D3B END GetHostAddr=3D3D3B<=3D3BBR>=3D3B
&= >gt=3D3B >=3D> >=3D3B<=3D3BBR>=3D3BPROCEDURE GetAddress (ent: Unetdb.s= >truct_hostent_star): Ad=3D> >dress =3D3D3D<=3D3BBR>=3D3B=3D3D
>=3D= >3B >=3D3B&=3D3Bnbsp=3D3D3B VAR ua: Uin.s=3D> >truct_in_addr=3D3D3B<= >=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B BEGIN<=3D3BBR>=3D3B&=3D3B=3D> >n= >bsp=3D3D3B&=3D3Bnbsp=3D3D
>=3D3B >=3D3B=3D3D3B&=3D3Bnbsp=3D3D3= >B &=3D3Blt=3D3D3=3D> >B* ASSERT ent.h_length &=3D3Blt=3D3D3B=3D3D3D B= >YTESIZE(Address) *&=3D3Bgt=3D3D3=3D> >B=3D3D
>=3D3B >=3D3B<=3D3= >BBR>=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bn=3D> >bsp=3D3D= >3B ua :=3D3D3D LOOPHOLE(ent.h_addr_list=3D3D2C<=3D3BBR>=3D3B&=3D3Bnb= >sp=3D> >=3D3D
>=3D3B >=3D3B=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp= >=3D3D3B&=3D3Bnbsp=3D3D3B&a=3D> >mp=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&a= >mp=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D> >=3D3D3B&=3D3Bnb= >sp=3D3D3B=3D3D
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B= >&a=3D> >mp=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3B= >nbsp=3D3D3B&=3D3Bnbsp=3D> >=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D= >3B UN=3D3D
>=3D3B >=3D3BTRACED REF UNTR=3D> ACED REF Uin.struct_in_a= >ddr)^^=3D3D3B<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbs=3D> >p=3D3D= >3B&=3D3Bnbsp=3D3D
>=3D3B >=3D3B=3D3D3B RETURN LOOPHOLE(ua.s_addr= >=3D3D2C A=3D> >ddress)=3D3D3B<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B END Get= >Address=3D3D3B<=3D3B=3D3D
=3D> >>=3D3B >=3D3BBR>=3D3B
>=3D3= >B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
>=3D> >=3D3B >=3D3B= >gethostbyname is failing.<=3D3BBR>=3D3B
>=3D3B >=3D3B<=3D3BBR&= >=3D> >gt=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
>=3D3B >=3D3BAna= >logous C code also f=3D> >ails:<=3D3BBR>=3D3B
>=3D3B >=3D3B&= >=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
>=3D> >=3D3B >=3D3B<=3D3BBR>= >=3D3B[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c<=3D3BBR>=3D3B#=3D> >include &= >amp=3D3Blt=3D3D3Bassert.h&=3D3Bgt=3D3D3B<=3D3BB=3D3D
>=3D3B >= >=3D3BR>=3D> >=3D3B#include &=3D3Blt=3D3D3Bnetdb.h&=3D3Bgt=3D3D3B<= >=3D3BBR>=3D3B#include &=3D> >=3D3Blt=3D3D3Bstdio.h&=3D3Bgt=3D3D3B&l= >t=3D3BBR>=3D3B#include =3D3D
>=3D3B >=3D3B&=3D> >amp=3D3Blt=3D3D3B= >errno.h&=3D3Bgt=3D3D3B<=3D3BBR>=3D3Btypedef struct hostent host=3D> = >>ent_t=3D3D3B<=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<= >=3D3BBR>=3D3B
=3D> >>=3D3B >=3D3Bint main()<=3D3BBR>=3D3B{<= >=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3Bchar ho=3D> >stname[200]=3D3D3B<=3D3BB= >R>=3D3B&=3D3Bnbsp=3D3D3Bhostent_t* h=3D3D3B=3D3D
>=3D> >=3D3B >= >=3D3B<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3Bint i=3D3D3B<=3D3BBR>=3D3BR>>=3D3B =3D> >>=3D3B&=3D3Bnbsp=3D3D3Bi =3D3D3D gethostname(hostname= >=3D3D2C 200)=3D3D3B<=3D3BBR&g=3D> >t=3D3B&=3D3Bnbsp=3D3D3Bassert(i =3D= >3D3D=3D3D3D 0)=3D3D
>=3D3B >=3D3B=3D3D3B<=3D3BBR=3D> >>=3D3B&= >=3D3Bnbsp=3D3D3Bprintf("hostname: %s\n"=3D3D2C hostname)=3D3D3B<=3D3BBR&g= >=3D> >t=3D3B&=3D3Bnbsp=3D3D3Bh =3D3D3D get=3D3D
>=3D3B >=3D3Bhost= >byname(hostname)=3D3D3=3D> >B<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3Bherror("= >foo")=3D3D3B<=3D3BBR>=3D3B&=3D3Bnbsp=3D> >=3D3D3Bprintf("%p %=3D3DR>>=3D3B >=3D3Bd %d\n"=3D3D2C h=3D3D2C errno=3D3D2C h_errno=3D> >)=3D3D= >3B<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3Bassert(h)=3D3D3B<=3D3BBR>=3D3B&= >amp=3D3Bnbsp=3D> >=3D3D3Bret=3D3D
>=3D3B >=3D3Burn 0=3D3D3B<=3D3BB= >R>=3D3B}<=3D3BBR>=3D3B
>=3D> >=3D3B >=3D3B&=3D3Bnbsp=3D3D3B= ><=3D3BBR>=3D3B
>=3D3B >=3D3Bherror says "unkno=3D> >wn host".<= >=3D3BBR>=3D3B
>=3D3B >=3D3B<=3D3BBR>=3D3BStack is:<=3D3BBR&g= >t=3D> >=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&a= >mp=3D3Bnbsp=3D3D3B at ../=3D> >src/runtime/ex_frame/RTExFrame.m3:58<=3D3B= >BR>=3D3B#13 =3D3D
>=3D3B >=3D3B0=3D> >x0000000801a7f2b3 in RTHooks= >__Raise (M3_AJWxb1_ex=3D3D3DError accessing memor=3D> >y=3D3D
>=3D3B &= >gt=3D3B ad<=3D3BBR>=3D3Bdress 0x8000ffffd278: Bad address.<=3D> >=3D3= >BBR>=3D3B)<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&= >=3D3Bnbsp=3D3D3B =3D> >=3D3D
>=3D3B >=3D3Bat ../src/runtime/common/R= >THooks.m3:79<=3D3BBR>=3D3B#14=3D> > 0x000000080169c8d3 in IPError=3D3D<= >BR>>=3D3B >=3D3B__Die () at ../src/common=3D> >/IPError.m3:27<=3D3BBR= >>=3D3B#15 0x0000000801698a3e in IP__Ge=3D3D
>=3D3B &=3D> >gt=3D3BtHo= >stAddr (M3_BCxjPn__result=3D3D3DError accessing mem<=3D3BBR>=3D3Bory = >=3D> >address 0x8000fff=3D3D
>=3D3B >=3D3Bfd338: Bad address.<=3D3= >BBR>=3D3B)<=3D> >=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3= >B&=3D3Bnbsp=3D3D3B at ../src/POSIX=3D> >/IP.m3:=3D3D
>=3D3B >=3D3= >B82<=3D3BBR>=3D3B#16 0x00000008012133d0 in XShare=3D> >dMem__SameHost (= >M3_AQuuui_trsl=3D3D3DErro=3D3D
>=3D3B >=3D3Br accessing m<=3D> >= >=3D3BBR>=3D3Bemory address 0x8000ffffd4d8: Bad address.<=3D3BBR>=3D3B= >)<=3D3BB=3D> >R>=3D3B&=3D3Bnbsp=3D3D
>=3D3B >=3D3B=3D3D3B&= >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B=3D> > at ../src/xvbt/XSharedMem.m3:96&= >lt=3D3BBR>=3D3B#17 0x0000000801212a=3D3D
&g=3D> >t=3D3B >=3D3Bb7 in = >XSharedMem__InitXClient (M3_AQuuui_v=3D3D3DError accessing m=3D> ><=3D3BB= >R>=3D3Bemory add=3D3D
>=3D3B >=3D3Bress 0x8000ffffd648: Bad addres= >s=3D> >.<=3D3BBR>=3D3B)<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bn= >bsp=3D3D3B&=3D3Bnbsp=3D> >=3D3D3B at ../sr=3D3D
>=3D3B >=3D3Bc/xv= >bt/XSharedMem.m3:29<=3D3BBR>=3D3B#18 =3D> >0x0000000801211819 in XExten= >sions__InitXClie=3D3D
>=3D3B >=3D3Bnt (M3_AQuu=3D> >ui_xclient=3D3D3= >DError acce<=3D3BBR>=3D3Bssing memory address 0x8000ffffd7f8:=3D> > =3D= >3D
>=3D3B >=3D3BBad address.<=3D3BBR>=3D3B)<=3D3BBR>=3D3B&am= >p=3D3Bnbsp=3D> >=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B at ../src/x= >vbt/XExtensions.m3=3D3D
&=3D> >gt=3D3B >=3D3B:14<=3D3BBR>=3D3B#19 = >0x00000008012467a4 in XClientF__Connect (M=3D> >3_Bd56fi_inst=3D3D3D0x1879= >=3D3D
>=3D3B >=3D3Bb=3D3D2C<=3D3BBR>=3D3B&=3D3Bnbsp=3D> >=3D3= >D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B M3_AQuuui_trsl=3D3D3D0x6) at ..= >/src/xvb=3D> >t/XClie=3D3D
>=3D3B >=3D3BntF.m3:583<=3D3BBR>=3D3B= >---Type &=3D3Blt=3D3D3Bre=3D> >turn&=3D3Bgt=3D3D3B to continue=3D3D2C= > or q &=3D3Blt=3D3D3Breturn&=3D3Bg=3D3D >>>=3D3B >=3D3Bt= >=3D3D3B to quit---<=3D3BBR>=3D3B(More stack frames follow...)&=3D> >lt= >=3D3BBR>=3D3B(gdb)<=3D3BBR>=3D3B
>=3D3B >=3D3B<=3D3BBR>=3D= >3B(* return TR=3D> >UE if server and client are on same host *)<=3D3BBR&g= >t=3D3BPROCEDURE Sa=3D3D >>>=3D3B >=3D3BmeHost (trsl: XClient.T):= > BOOLEAN =3D3D3D<=3D3BBR>=3D3B&=3D3Bn=3D> >bsp=3D3D3B VAR<=3D3BBR&= >gt=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bn=3D3D
&g=3D> >t= >=3D3B >=3D3Bbsp=3D3D3B display&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&am= >p=3D3Bnbsp=3D3D3B=3D> >&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbs= >p=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D> >=3D3D
>=3D3B >=3D3B= >=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&a=3D> >= >mp=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3= >D3B&=3D3Bnbsp=3D> >=3D3D3B :=3D3D3D Di=3D3D
>=3D3B >=3D3BsplayHos= >t(trsl)=3D3D3B<=3D3BBR>=3D3B&=3D> >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3= >D3B&=3D3Bnbsp=3D3D3B displayAddr: IP.Address=3D3D3B&l=3D> >t=3D3BB=3D3D<= >BR>>=3D3B >=3D3BR>=3D3B&=3D3Bnbsp=3D3D3B BEGIN<=3D3BBR>=3D3B&a= >mp=3D3B=3D> >nbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B IF display= > =3D3D3D NIL THEN RETURN=3D> >=3D3D
>=3D3B >=3D3B TRUE=3D3D3B END=3D= >3D3B<=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D> >=3D3Bnbsp=3D3D3B&= >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B TRY<=3D3BBR>=3D3B&=3D3Bnbsp=3D>= > >=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&= >=3D3Bnbsp=3D3D3B IF=3D3D=3D> >
>=3D3B >=3D3B NOT IP.GetHostByName(di= >splay=3D3D2C displayAddr) THEN RETUR=3D> >N FALSE=3D3D3B END=3D3D3B<=3D3B= >B=3D3D
>=3D3B >=3D3BR>=3D3B&=3D3Bnbsp=3D3D3B&=3D> >=3D3Bnbsp= >=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B RETURN = >display=3D> >Addr =3D3D3D IP.GetHos=3D3D
>=3D3B >=3D3BtAddr()=3D3D3B= ><=3D3BBR>=3D3B&=3D3Bnb=3D> >sp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnb= >sp=3D3D3B EXCEPT<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3=3D> >B&=3D3Bnbsp= >=3D3D3B&=3D3Bnbsp=3D3D3B |=3D3D
>=3D3B >=3D3B IP.Error =3D3D3D&am= >p=3D> >=3D3Bgt=3D3D3B RETURN FALSE=3D3D3B<=3D3BBR>=3D3B&=3D3Bnbsp=3D= >3D3B&=3D3Bnbsp=3D3D3B&=3D> >amp=3D3Bnbsp=3D3D3B END=3D3D3B<=3D3BBR>= >=3D3B&=3D3B=3D3D
>=3D3B >=3D3Bnbsp=3D3D3B =3D> >END SameHost=3D3D= >3B<=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>= >=3D> >=3D3B
>=3D3B >=3D3BThoughts?<=3D3BBR>=3D3B
>=3D3B >= >=3D3B&=3D3Bnbsp=3D3D3=3D> >B<=3D3BBR>=3D3B
>=3D3B >=3D3B<= >=3D3BBR>=3D3BPerhaps my network isn't setu=3D> >p well=3D3D2C like I shou= >ld add the local mach=3D3D
>=3D3B >=3D3Bine to /etc=3D> >/hosts.<= >=3D3BBR>=3D3BI think this can be made to fail gracefully though.<=3D> >= >=3D3BB=3D3D
>=3D3B >=3D3BR>=3D3BIt seems like it has nothing to do= > with AMD6=3D> >4_FREEBSD=3D3D2C but could have t=3D3D
>=3D3B >=3D3B= >o do with FreeBSD.<=3D3B=3D> >BR>=3D3B
>=3D3B >=3D3B<=3D3BBR&g= >t=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
&g=3D> >t=3D3B >=3D3BSeem= >s like SocketPosix has nearly the exact same code but appear=3D> >s<=3D3B= >BR>=3D3Bmore f=3D3D
>=3D3B >=3D3Borgiving.. IOError instead of Fat= >a=3D> >l?<=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3= >BBR>=3D3B
>=3D3B &=3D> >gt=3D3B<=3D3BBR>=3D3BSocketPosix.m3:<= >=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D3Bnbs=3D> >p=3D3D3B<=3D3BBR>= >=3D3B
>=3D3B >=3D3B<=3D3BBR>=3D3BPROCEDURE GetHostAddr ()=3D> >:= > Address<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B RAISES {OSError.E} =3D3D3D&l= >t=3D3BBR=3D3D=3D> >
>=3D3B >=3D3B>=3D3B&=3D3Bnbsp=3D3D3B VAR<= >=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B&a=3D> >mp=3D3Bnbsp=3D3D3B&=3D3Bnbsp= >=3D3D3B host : ARRAY [0..255] OF CHAR=3D3D3B<=3D3B=3D3D<=3D> >BR>>=3D3B= > >=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D= >3D3B in=3D> >fo : Unetdb.struct_hostent_star=3D3D3B<=3D3BBR>=3D3B&= >=3D3Bnbsp=3D3D
>=3D3B =3D> >>=3D3B=3D3D3B&=3D3Bnbsp=3D3D3B&=3D= >3Bnbsp=3D3D3B ua&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D> >=3D3D3B : Uin.struct= >_in_addr=3D3D3B<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B =3D3D
>=3D3B=3D>= > > >=3D3BBEGIN<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&= >amp=3D3Bnbsp=3D3D3B =3D> >IF Unix.gethostname (ADR (host[0])=3D3D2C BYT=3D3= >D
>=3D3B >=3D3BESIZE (host)=3D> >) # 0 THEN<=3D3BBR>=3D3B&=3D= >3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&am=3D> >p=3D3Bnbsp=3D= >3D3B&=3D3Bnbsp=3D3D3B IOError =3D3D
>=3D3B >=3D3B(Unexpected)=3D3= >D3B=3D> ><=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3= >Bnbsp=3D3D3B END=3D3D3B<=3D> >=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D= >3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3=3D> >B info :=3D3D3D U= >netdb.gethostbyname (ADR (host[0]))=3D3D3B<=3D3B=3D3D
>=3D3B =3D> >&= >gt=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D= >3B IF info =3D3D3=3D> >D NIL THEN IOError (Unexpected)=3D3D3B EN=3D3D
&g= >t=3D3B >=3D3BD=3D3D3B<=3D3BBR&g=3D> >t=3D3B&=3D3Bnbsp=3D3D3B&=3D3= >Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B &=3D3Blt=3D3D3B* ASSERT=3D> > info.h_le= >ngth &=3D3Blt=3D3D3B=3D3D3D BYT=3D3D
>=3D3B >=3D3BESIZE (Address)= > *=3D> >&=3D3Bgt=3D3D3B<=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D3Bn= >bsp=3D3D3B&=3D3Bnbsp=3D3D=3D> >3B&=3D3Bnbsp=3D3D3B ua :=3D3D3D LOOPHO= >LE(info.h_addr_list=3D3D2C<=3D3BBR>=3D3B&a=3D> >mp=3D3Bnbsp=3D3D3B&= >=3D3Bn=3D3D
>=3D3B >=3D3Bbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnb= >=3D> >sp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B= >&=3D3Bnbsp=3D3D3B&=3D> >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3B= >nbsp=3D3D
>=3D3B >=3D3B=3D3D3B&=3D3Bnbsp=3D> >=3D3D3B&=3D3Bnbs= >p=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D= >> >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B UNTRACED REF UN=3D3D
>=3D3B &g= >t=3D3BTRACED REF =3D> >Uin.struct_in_addr)^^=3D3D3B<=3D3BBR>=3D3B&= >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&am=3D> >p=3D3Bnbsp=3D3D3B RETURN LOOP= >=3D3D
>=3D3B >=3D3BHOLE (ua.s_addr=3D3D2C Address)=3D> >=3D3D3B<= >=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B END GetHostAddr=3D3D3B<=3D3BBR>=3D3= >B
&=3D> >gt=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
>= >=3D3B >=3D3B&=3D3Bnbsp=3D3D3B=3D> ><=3D3BBR>=3D3B
>=3D3B >= >=3D3BIt is again disappointing to see such code d=3D> >uplication.<=3D3BB= >R>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B= > >>>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
>=3D3B >= >=3D3BI guess&=3D3B=3D> >nbsp=3D3D3BSameHost can duplicate the logic to p= >redict the error state =3D3D >>>=3D3B >=3D3Band return false&= >=3D3Bnbsp=3D3D3Bupon error?<=3D3BBR>=3D3B
=3D> >>=3D3B >=3D3BDup= >licating the logic for a third time. :(<=3D3BBR>=3D3B
&g=3D> >t=3D3B= > >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
>=3D3B >=3D3B<=3D3= >BBR>=3D3B&am=3D> >p=3D3Bnbsp=3D3D3B- Jay<=3D3BBR>=3D3B<=3D3BBR>= >=3D3B<=3D3B/body>=3D3B
>=3D3B &=3D> >gt=3D3B<=3D3B/html>=3D3B= >=3D3D
>=3D3B >=3D3B
>=3D3B >=3D3B--_9e67232c-a064=3D> >-417d-= >879e-227a77e310f9_--

> >=3D> >> >--_b00371fe-730b-4981= >-9051-a874361296d7_--= > >--_b0c10337-0e1c-414e-aae5-e611dcd4be8a_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >PPC_LINUX not PPC_DARWIN.
>I think.
>And at one point AMD64_LINUX (same machine as AMD64_FREEBSD=2C multiboot).<= >BR>I think I tested I386_OPENBSD Juno too and it worked=2C
I don't remem= >ber. Oh=2C but that was in a VM=2C so different networking setup.
>
This is Trestle startup=2C seeing if there might
be shared memory av= >ailable between the X client and server.
>
If $DISPLAY is set=2C to specify the server=2C it wants to compare
t= >hat against "current"=2C the client.
You know=2C if I set DISPLAY=3D:0.0= > or localhost:0.0=2C don't penalize perf=2C
but if it really is remote= >=2C then do penalize perf.
>
/Something/ like that.
>I hardly read the code..
>
 =3B- Jay

>=3B To: jay.krell at cornell.edu
>=3B Date: M= >on=2C 12 Jan 2009 01:06:30 -0800
>=3B From: mika at async.caltech.edu
= >>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] Juno (X) = >networking problem on AMD64_FREEBSD
>=3B
>=3B Jay=2C
>=3B <= >BR>>=3B I think the problem here is actually in the caller. Why does a>>=3B caller need "GetHostAddr()"? It is probably doing this for the
&= >gt=3B purpose of calling listen() or some such thing. What the caller
&g= >t=3B probably *really* wants is INADDR_ANY=2C and not the IP address of
= >>=3B some arbitrarily chosen interface on the host.
>=3B
>=3B = >I'm guessing it works on the Mac because the Mac libraries do
>=3B som= >ething complicated when you ask for the host's name (i.e.=2C they
>=3B= > somehow generate a hostname that always maps to the IP address of
>= >=3B an interface on the computer).
>=3B
>=3B Mika
>=3B
= >>=3B Jay writes:
>=3B >=3B--_b00371fe-730b-4981-9051-a874361296d7_= >
>=3B >=3BContent-Type: text/plain=3B charset=3D"iso-8859-1"
>= >=3B >=3BContent-Transfer-Encoding: quoted-printable
>=3B >=3B
&= >gt=3B >=3B
>=3B >=3BDo you know the right way?
>=3B >=3B=3D= >20
>=3B >=3BPPC_LINUX "just worked"=3D2C and I can check Solaris and= > Darwin.
>=3B >=3B=3D20
>=3B >=3BI don't want to edit /etc/ho= >sts -- I use DHCP.
>=3B >=3BThough DHCP has been bothering me -- onl= >y for some of my machines do names =3D
>=3B >=3Bresolve=3D2C so I en= >d using IP addresses=3D2C which change sometimes=3D2C and I l=3D
>=3B = >>=3Boop over them running ssh to all of them and "see what I get"=3D2C no= >t ideal.
>=3B >=3B=3D20
>=3B >=3B - Jay>=3B To: jay.krell at c= >ornell.edu>=3B Date: Sun=3D2C 11 Jan 2009 08:02:18 -0800>=3B=3D
>= >=3B >=3B From: mika at async.caltech.edu>=3B CC: m3devel at elegosoft.com>= >=3B Subject: Re: [M3d=3D
>=3B >=3Bevel] Juno (X) networking problem = >on AMD64_FREEBSD>=3B >=3B This is a screwy thin=3D
>=3B >=3Bg in= > Modula-3. A bug I would call it.>=3B >=3B I've noticed a lot of networ= >king M=3D
>=3B >=3B3 programs don't work right unless>=3B the retu= >rn value of Unix's "hostname" m=3D
>=3B >=3Baps to a real IP address= > via>=3B gethostbyname. I accomplish it in practice by=3D
>=3B >= >=3B adding my hostname>=3B to /etc/hosts.>=3B >=3B This is obviously = >not the right way =3D
>=3B >=3Bto fix it... >=3B >=3B Mika>=3B= > >=3B Jay writes:>=3B >=3B--_9e67232c-a064-417d-879e-227a77e31=3D
= >>=3B >=3B0f9_>=3B >=3BContent-Type: text/plain=3D3B charset=3D3D"is= >o-8859-1">=3B >=3BContent-Transfe=3D
>=3B >=3Br-Encoding: quoted= >-printable>=3B >=3B>=3B >=3B>=3B >=3BHi. Unix network programmi= >ng question.=3D
>=3B >=3B.>=3B >=3BAMD64_FREEBSD:>=3B >=3B$D= >ISPLAY is set to point back to Cygwin host.It works =3D
>=3B >=3Bfor= > PPC_LINUX.>=3B >=3B[jay at fbsdamd64a /cm3/bin]$ ./Juno>=3B >=3B*****= >* runtime error:*=3D
>=3B >=3B** Exception "IPError.FatalError" not = >in RAISES li=3D3D>=3B >=3Bst*** file "../src/=3D
>=3B >=3Bcommon= >/IPError.m3"=3D3D2C line 27***>=3B >=3BAbort trap: 6 (core dumped)[jay@= >fbsdam=3D
>=3B >=3Bd64a /cm3/bin]$>=3B >=3BIP.m3:>=3B >=3B= >=3D3D20>=3B >=3BPROCEDURE GetHostAddr(): Address =3D3D3D V=3D
>=3B= > >=3BAR hname: ARRAY [0..255] OF CHAR=3D3D3B =3D3D>=3B >=3B BEGIN LOC= >K mu DO IF Unix.getho=3D
>=3B >=3Bstname(ADR(hname[0])=3D3D2C BYTESI= >ZE(hna=3D3D>=3B >=3Bme)) # 0 THEN IPError.Die ()=3D3D=3D
>=3B >= >=3B3B END=3D3D3B VAR h :=3D3D3D Unetdb.g=3D3D>=3B >=3Bethostbyname(ADR(= >hname[0]))=3D3D3B BEG=3D
>=3B >=3BIN IF h =3D3D3D NIL THEN IPError.D= >ie()=3D3D>=3B >=3B=3D3D3B END=3D3D3B RETURN GetAddress(=3D
>=3B &g= >t=3Bh)=3D3D3B END=3D3D3B END=3D3D3B END GetHos=3D3D>=3B >=3BtAddr=3D3D3= >B>=3B >=3BPROCEDURE GetAddress=3D
>=3B >=3B (ent: Unetdb.struct_= >hostent_star): Address =3D3D3D VAR ua=3D3D>=3B >=3B: Uin.struct_=3D
= >>=3B >=3Bin_addr=3D3D3B BEGIN <=3B* ASSERT ent.h_length <=3B=3D3D3D= > BYTESIZE(Addr=3D3D>=3B >=3Bess) *>=3B=3D
>=3B >=3B ua :=3D3D3= >D LOOPHOLE(ent.h_addr_list=3D3D2C UNTRACED =3D3D>=3B >=3BREF UNTRACED R= >EF Ui=3D
>=3B >=3Bn.struct_in_addr)^^=3D3D3B RETURN LOOPHOLE(ua.s_ad= >dr=3D3D2C A=3D3D>=3B >=3Bddress)=3D3D3B=3D
>=3B >=3B END GetAddr= >ess=3D3D3B>=3B >=3B=3D3D20>=3B >=3Bgethostbyname is failing.>=3B = >>=3B=3D3D20>=3B >=3BAnalogou=3D
>=3B >=3Bs C code also fails:&= >gt=3B >=3B=3D3D20>=3B >=3B[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c#includ= >e=3D
>=3B >=3B <=3Bassert.h>=3B#include <=3Bnetdb.h>=3B#i=3D= >3D>=3B >=3Bnclude <=3Bstdio.h>=3B#include <=3Berrno.h>=3Btype= >=3D
>=3B >=3Bdef struct hostent hostent_t=3D3D3B>=3B >=3B=3D3D20= >>=3B >=3Bint main(){ char hostname[200]=3D
>=3B >=3B=3D3D3B host= >ent_t* h=3D3D3B int i=3D3D3B>=3B >=3B i =3D3D3D gethostname(hostname=3D= >3D2C 200=3D
>=3B >=3B)=3D3D3B assert(i =3D3D3D=3D3D3D 0)=3D3D3B prin= >tf("hostna=3D3D>=3B >=3Bme: %s\n"=3D3D2C hostn=3D
>=3B >=3Bame)= >=3D3D3B h =3D3D3D gethostbyname(hostname)=3D3D3B herror("foo")=3D3D3B=3D3D&= >gt=3B >=3B pri=3D
>=3B >=3Bntf("%p %d %d\n"=3D3D2C h=3D3D2C errno= >=3D3D2C h_errno)=3D3D3B assert(h)=3D3D3B return=3D
>=3B >=3B 0=3D3D3= >B}>=3B >=3B=3D3D20>=3B >=3Bherror says "unknown host".>=3B >=3B= >Stack is:>=3B >=3B at ../src/run=3D
>=3B >=3Btime/ex_frame/RTExF= >rame.m3:58#13 0x0000000801a7f2b3 in RTH=3D3D>=3B >=3Books__Raise=3D
= >>=3B >=3B (M3_AJWxb1_ex=3D3D3DError accessing memory address 0x8000ffff= >d278: =3D3D>=3B >=3BBad=3D
>=3B >=3B address.) at ../src/runtime= >/common/RTHooks.m3:79#14 0x000000080169c8=3D3D>=3B >=3B=3D
>=3B &g= >t=3Bd3 in IPError__Die () at ../src/common/IPError.m3:27#15 0x0000000801698= >a3e =3D
>=3B >=3B=3D3D>=3B >=3Bin IP__GetHostAddr (M3_BCxjPn__re= >sult=3D3D3DError accessing memory addr=3D
>=3B >=3Bess 0x80=3D3D>= >=3B >=3B00ffffd338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x00000=3D<= >BR>>=3B >=3B008012133d0=3D3D>=3B >=3B in XSharedMem__SameHost (M3_A= >Quuui_trsl=3D3D3DError accessi=3D
>=3B >=3Bng memory address 0=3D3D&= >gt=3B >=3Bx8000ffffd4d8: Bad address.) at ../src/xvbt/XShare=3D
>=3B= > >=3BdMem.m3:96#17 0x000000=3D3D>=3B >=3B0801212ab7 in XSharedMem__In= >itXClient (M3_AQuuu=3D
>=3B >=3Bi_v=3D3D3DError accessing memory=3D3= >D>=3B >=3B address 0x8000ffffd648: Bad address.) =3D
>=3B >=3Bat= > ../src/xvbt/XSharedMem.m3:29#1=3D3D>=3B >=3B8 0x0000000801211819 in XE= >xtensions_=3D
>=3B >=3B_InitXClient (M3_AQuuui_xclient=3D3D3DError= >=3D3D>=3B >=3B accessing memory address 0x=3D
>=3B >=3B8000ffffd= >7f8: Bad address.) at ../src/xvbt/X=3D3D>=3B >=3BExtensions.m3:14#19 0x= >000=3D
>=3B >=3B00008012467a4 in XClientF__Connect (M3_Bd56fi_inst= >=3D3D>=3B >=3B=3D3D3D0x1879b=3D3D2C M=3D
>=3B >=3B3_AQuuui_trsl= >=3D3D3D0x6) at ../src/xvbt/XClientF.m3:583---Typ=3D3D>=3B >=3Be <=3Br= >eturn>=3B=3D
>=3B >=3B to continue=3D3D2C or q <=3Breturn>=3B = >to quit---(More stack frames follow=3D3D>=3B >=3B..=3D
>=3B >=3B= >.)(gdb)>=3B >=3B(* return TRUE if server and client are on same host *)= >PROCEDURE =3D
>=3B >=3BSameHost (=3D3D>=3B >=3Btrsl: XClient.T):= > BOOLEAN =3D3D3D VAR display :=3D3D3D DisplayH=3D
>=3B >=3B=3D3D>= >=3B >=3Bost(trsl)=3D3D3B displayAddr: IP.Address=3D3D3B BEGIN IF display = >=3D3D3D NI=3D
>=3B >=3BL THE=3D3D>=3B >=3BN RETURN TRUE=3D3D3B E= >ND=3D3D3B>=3B >=3B TRY IF NOT IP.GetHostByName(displ=3D
>=3B >= >=3Bay=3D3D2C displayAddr) THEN RETURN FA=3D3D>=3B >=3BLSE=3D3D3B END=3D= >3D3B RETURN displayAd=3D
>=3B >=3Bdr =3D3D3D IP.GetHostAddr()=3D3D3B= > EXCEPT =3D3D>=3B >=3B| IP.Error =3D3D3D>=3B RETURN FALSE=3D
>= >=3B >=3B=3D3D3B END=3D3D3B END SameHost=3D3D3B>=3B >=3B=3D3D20>=3B = >>=3BThoughts?>=3B >=3B=3D3D20>=3B >=3BPerhaps my n=3D
>=3B &= >gt=3Betwork isn't setup well=3D3D2C like I should add the local machine =3D= >3D>=3B >=3Bto /=3D
>=3B >=3Betc/hosts.I think this can be made t= >o fail gracefully though.It seems l=3D3D>=3B=3D
>=3B >=3B >=3Bik= >e it has nothing to do with AMD64_FREEBSD=3D3D2C but could have to do wit= >=3D
>=3B >=3Bh Fr=3D3D>=3B >=3BeeBSD.>=3B >=3B=3D3D20>=3B = >>=3BSeems like SocketPosix has nearly the exact same=3D
>=3B >=3B = >code but appearsmore forgi=3D3D>=3B >=3Bving.. IOError instead of Fatal= >?>=3B >=3B=3D3D20>=3B =3D
>=3B >=3B>=3BSocketPosix.m3:>=3B= > >=3B=3D3D20>=3B >=3BPROCEDURE GetHostAddr (): Address RAISES {OSErro= >=3D
>=3B >=3Br.E} =3D3D3D VAR host : AR=3D3D>=3B >=3BRAY [0..255= >] OF CHAR=3D3D3B info : Unetdb.struc=3D
>=3B >=3Bt_hostent_star=3D3D= >3B ua : U=3D3D>=3B >=3Bin.struct_in_addr=3D3D3B BEGIN IF Unix.gethos=3D= >
>=3B >=3Btname (ADR (host[0])=3D3D2C BYTESI=3D3D>=3B >=3BZE (ho= >st)) # 0 THEN IOError (Unexpect=3D
>=3B >=3Bed)=3D3D3B END=3D3D3B>= >=3B >=3B info :=3D3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3D3B =3D>>=3B >=3BIF info =3D3D3D NIL TH=3D3D>=3B >=3BEN IOError (Unexpecte= >d)=3D3D3B END=3D3D3B <=3B* ASSERT i=3D
>=3B >=3Bnfo.h_length <= >=3B=3D3D3D BYTESIZE =3D3D>=3B >=3B(Address) *>=3B>=3B >=3B ua := >=3D3D3D LOOPHOLE(info.=3D
>=3B >=3Bh_addr_list=3D3D2C UNTRACED REF U= >NT=3D3D>=3B >=3BRACED REF Uin.struct_in_addr)^^=3D3D3B=3D
>=3B >= >=3B RETURN LOOPHOLE (ua.s_addr=3D3D2C Address=3D3D>=3B >=3B)=3D3D3B END= > GetHostAddr=3D3D3B>=3B =3D
>=3B >=3B>=3B=3D3D20>=3B >=3B=3D= >3D20>=3B >=3BIt is again disappointing to see such code duplication.>= >=3B >=3B=3D
>=3B >=3B=3D3D20>=3B >=3B=3D3D20>=3B >=3BI gue= >ss SameHost can duplicate the logic to predict the err=3D
>=3B >=3Bo= >r state and ret=3D3D>=3B >=3Burn false upon error?>=3B >=3BDuplicat= >ing the logic for a t=3D
>=3B >=3Bhird time. :(>=3B >=3B=3D3D20&= >gt=3B >=3B - Jay=3D3D>=3B >=3B>=3B >=3B--_9e67232c-a064-417d-879e= >-227a77e31=3D
>=3B >=3B0f9_>=3B >=3BContent-Type: text/html=3D3B= > charset=3D3D"iso-8859-1">=3B >=3BContent-Transfer=3D
>=3B >=3B-= >Encoding: quoted-printable>=3B >=3B>=3B >=3B<=3Bhtml>=3B>=3B = >>=3B<=3Bhead>=3B>=3B >=3B<=3Bstyle>=3B>=3B >=3B.hmmessage= > P>=3B =3D
>=3B >=3B>=3B{>=3B >=3Bmargin:0px=3D3D3B>=3B &g= >t=3Bpadding:0px>=3B >=3B}>=3B >=3Bbody.hmmessage>=3B >=3B{>= >=3B >=3Bfont-size: 10=3D
>=3B >=3Bpt=3D3D3B>=3B >=3Bfont-famil= >y:Verdana>=3B >=3B}>=3B >=3B<=3B/style>=3B>=3B >=3B<=3B/h= >ead>=3B>=3B >=3B<=3Bbody class=3D3D3D'h=3D
>=3B >=3Bmmessage= >'>=3B>=3B >=3BHi. Unix network programming question..<=3BBR>=3B&g= >t=3B >=3B<=3BBR>=3BAMD64_FREEBS=3D
>=3B >=3BD:<=3BBR>=3B&g= >t=3B >=3B<=3BBR>=3B$DISPLAY is set to point back to Cygwin host.<= >=3BBR>=3BIt works for =3D
>=3B >=3BPPC_LINUX=3D3D>=3B >=3B.<= >=3BBR>=3B>=3B >=3B<=3BBR>=3B[jay at fbsdamd64a /cm3/bin]$ ./Juno<= >=3BBR>=3B>=3B >=3B<=3BBR>=3B***<=3B=3D
>=3B >=3BBR>=3B= >*** runtime error:<=3BBR>=3B***&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&= >=3Bnbsp=3D3D3B Exception "IPE=3D
>=3B >=3B=3D3D>=3B >=3Brror.Fat= >alError" not in RAISES list<=3BBR>=3B***&=3Bnbsp=3D3D3B&=3Bnbsp= >=3D3D3B&=3Bnbsp=3D
>=3B >=3B=3D3D3B file "..=3D3D>=3B >=3B/sr= >c/common/IPError.m3"=3D3D2C line 27<=3BBR>=3B***<=3BBR>=3B>=3B &g= >t=3B<=3BBR>=3BA=3D
>=3B >=3Bbort trap: 6 (core dumped)<=3BBR&g= >t=3B[jay at fbsdamd64a /cm3/bin]$<=3BBR>=3B>=3B >=3B<=3BBR>=3BIP.m= >3:<=3BB=3D
>=3B >=3BR>=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR= >>=3B>=3B >=3BPROCEDURE GetHostAddr(): Address =3D3D3D<=3BBR>=3B&a= >mp=3Bnbsp=3D3D3B =3D
>=3B >=3BVAR hname: ARRAY [0..255] =3D3D>=3B = >OF CHAR=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B BEGIN<=3BBR>=3B&=3Bnb= >sp=3D3D=3D
>=3B >=3B3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B LOCK mu D= >O<=3BBR>=3B&=3Bnbs=3D3D>=3B >=3Bp=3D3D3B&=3Bnbsp=3D3D3B&= >=3Bnbsp=3D3D3B&=3Bn=3D
>=3B >=3Bbsp=3D3D3B&=3Bnbsp=3D3D3B IF U= >nix.gethostname(ADR(hname[0])=3D3D2C B=3D3D>=3B >=3BYTESIZE(hn=3D
&g= >t=3B >=3Bame)) # 0 THEN<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B= >&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D
>= >=3B >=3B=3D3D>=3B >=3B=3D3D3B&=3Bnbsp=3D3D3B IPError.Die ()=3D3D3B= ><=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B=3D
= >>=3B >=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B E=3D3D>=3B >=3BND=3D3= >D3B<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&= >=3Bnbsp=3D
>=3B >=3B=3D3D3B&=3Bnbsp=3D3D3B VAR h :=3D3D3D Unetdb.= >gethost=3D3D>=3B >=3Bbyname(ADR(hname[0]))=3D3D3B=3D
>=3B >=3B B= >EGIN<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&am= >p=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3B=3D3D>=3B >=3Bnbsp=3D3D3=3D
= >>=3B >=3BB&=3Bnbsp=3D3D3B IF h =3D3D3D NIL THEN IPError.Die()=3D3D3B= > END=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bn=3D
>=3B >=3Bbsp= >=3D3D>=3B >=3B=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D= >3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B RETURN Get=3D
>=3B >=3BAddr= >ess(h)=3D3D3B<=3BBR>=3B&=3Bnbs=3D3D>=3B >=3Bp=3D3D3B&=3Bnbsp= >=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B=3D
>=3B = >>=3B END=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bn= >bsp=3D3D3B END=3D3D>=3B >=3B=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B EN= >=3D
>=3B >=3BD GetHostAddr=3D3D3B<=3BBR>=3B>=3B >=3B<=3BBR= >>=3BPROCEDURE GetAddress (ent: Unetdb.struct_hoste=3D
>=3B >=3Bnt_= >star): Address =3D3D3D<=3BBR>=3B=3D3D>=3B >=3B&=3Bnbsp=3D3D3B VA= >R ua: Uin.struct_in_addr=3D3D3B=3D
>=3B >=3B<=3BBR>=3B&=3Bnbs= >p=3D3D3B BEGIN<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D>=3B >=3B= >=3D3D3B&=3Bnbsp=3D3D3B &=3Blt=3D3D3B* ASSE=3D
>=3B >=3BRT ent.= >h_length &=3Blt=3D3D3B=3D3D3D BYTESIZE(Address) *&=3Bgt=3D3D3B=3D3D&g= >t=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3D=3D
>=3B >=3B3B&=3Bnbsp= >=3D3D3B&=3Bnbsp=3D3D3B ua :=3D3D3D LOOPHOLE(ent.h_addr_list=3D3D2C<=3B= >BR>=3B&=3Bnbsp=3D3D>=3B=3D
>=3B >=3B >=3B=3D3D3B&=3Bnbsp= >=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D= >3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D=3D
>=3B >=3B3B&=3Bnbsp=3D3= >D3B&=3Bnbsp=3D3D3B=3D3D>=3B >=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B= >&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D
>=3B >=3B=3D3D3B&= >amp=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B UN= >=3D3D>=3B >=3BTRACED REF UNTRACED R=3D
>=3B >=3BEF Uin.struct_in= >_addr)^^=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbs= >p=3D3D>=3B >=3B=3D3D3B RETUR=3D
>=3B >=3BN LOOPHOLE(ua.s_addr=3D= >3D2C Address)=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B END GetAddress=3D3D3B&= >lt=3B=3D
>=3B >=3B=3D3D>=3B >=3BBR>=3B>=3B >=3B&=3Bnbsp= >=3D3D3B<=3BBR>=3B>=3B >=3Bgethostbyname is failing.<=3BBR>=3B&g= >t=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3D3B=3D
>=3B >=3B<=3BBR>= >=3B>=3B >=3BAnalogous C code also fails:<=3BBR>=3B>=3B >=3B&= >=3Bnbsp=3D3D3B<=3BBR>=3B>=3B >=3B<=3BBR>=3B[jay at fbsdamd=3D
&= >gt=3B >=3B64a /cm3/bin]$ cat ~/5.c<=3BBR>=3B#include &=3Blt=3D3D3B= >assert.h&=3Bgt=3D3D3B<=3BB=3D3D>=3B >=3BR>=3B#inc=3D
>=3B &= >gt=3Blude &=3Blt=3D3D3Bnetdb.h&=3Bgt=3D3D3B<=3BBR>=3B#include &am= >p=3Blt=3D3D3Bstdio.h&=3Bgt=3D3D3B<=3BBR>=3B#includ=3D
>=3B >= >=3Be =3D3D>=3B >=3B&=3Blt=3D3D3Berrno.h&=3Bgt=3D3D3B<=3BBR>= >=3Btypedef struct hostent hostent_t=3D3D3B<=3BBR=3D
>=3B >=3B>= >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B>=3B >=3Bint main()<= >=3BBR>=3B{<=3BBR>=3B&=3Bnbsp=3D3D3Bchar hostname[200]=3D3D3B<=3B= >B=3D
>=3B >=3BR>=3B&=3Bnbsp=3D3D3Bhostent_t* h=3D3D3B=3D3D>= >=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3D3Bint i=3D3D3B<=3BBR>=3B>=3B = >>=3B&=3Bnbsp=3D3D3=3D
>=3B >=3BBi =3D3D3D gethostname(hostname= >=3D3D2C 200)=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3Bassert(i =3D3D3D=3D3D=3D= >
>=3B >=3B3D 0)=3D3D>=3B >=3B=3D3D3B<=3BBR>=3B&=3Bnbsp=3D= >3D3Bprintf("hostname: %s\n"=3D3D2C hostname)=3D3D3B<=3BB=3D
>=3B >= >=3BR>=3B&=3Bnbsp=3D3D3Bh =3D3D3D get=3D3D>=3B >=3Bhostbyname(hostn= >ame)=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3Bherror(=3D
>=3B >=3B"foo"= >)=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3Bprintf("%p %=3D3D>=3B >=3Bd %d\= >n"=3D3D2C h=3D3D2C errno=3D3D2C h=3D
>=3B >=3B_errno)=3D3D3B<=3BBR= >>=3B&=3Bnbsp=3D3D3Bassert(h)=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3Bret= >=3D3D>=3B >=3Burn 0=3D3D3B<=3BB=3D
>=3B >=3BR>=3B}<=3BBR&g= >t=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B>=3B >=3Bherror says "= >unknown host".<=3BBR>=3B>=3B >=3B<=3BBR>=3BStack is:<=3B=3DR>>=3B >=3BBR>=3B>=3B >=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&am= >p=3Bnbsp=3D3D3B at ../src/runtime/ex_frame/RTExFrame.m=3D
>=3B >=3B3= >:58<=3BBR>=3B#13 =3D3D>=3B >=3B0x0000000801a7f2b3 in RTHooks__Raise= > (M3_AJWxb1_ex=3D3D3DEr=3D
>=3B >=3Bror accessing memory=3D3D>=3B = >>=3B ad<=3BBR>=3Bdress 0x8000ffffd278: Bad address.<=3BBR>=3B)<= >=3BBR=3D
>=3B >=3B>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bn= >bsp=3D3D3B =3D3D>=3B >=3Bat ../src/runtime/common/RTHooks.m3:7=3D
&g= >t=3B >=3B9<=3BBR>=3B#14 0x000000080169c8d3 in IPError=3D3D>=3B >= >=3B__Die () at ../src/common/IPErr=3D
>=3B >=3Bor.m3:27<=3BBR>= >=3B#15 0x0000000801698a3e in IP__Ge=3D3D>=3B >=3BtHostAddr (M3_BCxjPn__= >res=3D
>=3B ult=3D3D3DError accessing mem<=3BBR>=3Bory address 0x8= >000fff=3D3D>=3B >=3Bfd338: Bad addres=3D
>=3B >=3Bs.<=3BBR>= >=3B)<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B at= > ../src/POSIX/IP.m3:=3D3D>=3B >=3B82<=3BBR=3D
>=3B >=3B>=3B#= >16 0x00000008012133d0 in XSharedMem__SameHost (M3_AQuuui_trsl=3D3D3DErro=3D= >3D=3D
>=3B >=3B>=3B >=3Br accessing m<=3BBR>=3Bemory address= > 0x8000ffffd4d8: Bad address.<=3BBR>=3B)<=3BBR>=3B&=3Bnbs=3D
= >>=3B >=3Bp=3D3D>=3B >=3B=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B= > at ../src/xvbt/XSharedMem.m3:96<=3BBR>=3B#17 0x0=3D
>=3B >=3B00= >0000801212a=3D3D>=3B >=3Bb7 in XSharedMem__InitXClient (M3_AQuuui_v=3D3= >D3DError acc=3D
>=3B >=3Bessing m<=3BBR>=3Bemory add=3D3D>=3B = >>=3Bress 0x8000ffffd648: Bad address.<=3BBR>=3B)<=3BBR>=3B&=3B= >nbsp=3D
>=3B >=3B=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B at ../s= >r=3D3D>=3B >=3Bc/xvbt/XSharedMem.m3:29<=3BBR>=3B#18 0x00=3D
>= >=3B >=3B00000801211819 in XExtensions__InitXClie=3D3D>=3B >=3Bnt (M3_= >AQuuui_xclient=3D3D3DErr=3D
>=3B >=3Bor acce<=3BBR>=3Bssing memo= >ry address 0x8000ffffd7f8: =3D3D>=3B >=3BBad address.<=3BBR>=3B)<= >=3BBR>=3B=3D
>=3B >=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bn= >bsp=3D3D3B at ../src/xvbt/XExtensions.m3=3D3D>=3B >=3B:14<=3BBR>=3B= >#1=3D
>=3B >=3B9 0x00000008012467a4 in XClientF__Connect (M3_Bd56fi_= >inst=3D3D3D0x1879=3D3D>=3B >=3Bb=3D
>=3B >=3B=3D3D2C<=3BBR>= >=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B M3_AQuuui_trsl=3D= >3D3D0x6) at ../src/x=3D
>=3B >=3Bvbt/XClie=3D3D>=3B >=3BntF.m3:5= >83<=3BBR>=3B---Type &=3Blt=3D3D3Breturn&=3Bgt=3D3D3B to continue= >=3D3D2=3D
>=3B >=3BC or q &=3Blt=3D3D3Breturn&=3Bg=3D3D>=3B = >>=3Bt=3D3D3B to quit---<=3BBR>=3B(More stack frames follow=3D
>= >=3B >=3B...)<=3BBR>=3B(gdb)<=3BBR>=3B>=3B >=3B<=3BBR>=3B(= >* return TRUE if server and client are on same hos=3D
>=3B >=3Bt *)&= >lt=3BBR>=3BPROCEDURE Sa=3D3D>=3B >=3BmeHost (trsl: XClient.T): BOOLEA= >N =3D3D3D<=3BBR>=3B&=3Bnbsp=3D
>=3B >=3B=3D3D3B VAR<=3BBR&g= >t=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bn=3D3D>=3B >=3Bbsp=3D3D3= >B display&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D=3D
>=3B >=3B3B&=3Bnbs= >p=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp= >=3D3D3B&=3Bnbsp=3D3D>=3B >=3B=3D3D3B&=3Bnbsp=3D
>=3B >=3B= >=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D= >3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B=3D
>=3B := >=3D3D3D Di=3D3D>=3B >=3BsplayHost(trsl)=3D3D3B<=3BBR>=3B&=3Bnbsp= >=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B disp=3D
>=3B >=3BlayAddr= >: IP.Address=3D3D3B<=3BB=3D3D>=3B >=3BR>=3B&=3Bnbsp=3D3D3B BEGIN= ><=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3B=3D
>=3B >= >=3Bnbsp=3D3D3B IF display =3D3D3D NIL THEN RETURN=3D3D>=3B >=3B TRUE=3D= >3D3B END=3D3D3B<=3BBR>=3B>=3B >=3B&=3B=3D
>=3B >=3Bnbsp= >=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B TRY<=3BBR>=3B&=3Bnbsp=3D= >3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D=3D
>=3B >= >=3B3B&=3Bnbsp=3D3D3B IF=3D3D>=3B >=3B NOT IP.GetHostByName(display= >=3D3D2C displayAddr) THEN R=3D
>=3B >=3BETURN FALSE=3D3D3B END=3D3D3= >B<=3BB=3D3D>=3B >=3BR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&= >=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B=3D
>=3B >=3B&=3Bnbsp=3D3D3B RETU= >RN displayAddr =3D3D3D IP.GetHos=3D3D>=3B >=3BtAddr()=3D3D3B<=3BBR>= >=3B&=3Bnbsp=3D3D=3D
>=3B >=3B3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D= >3B EXCEPT<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D= >3B |=3D3D>=3B >=3B IP.=3D
>=3B >=3BError =3D3D3D&=3Bgt=3D3D3B= > RETURN FALSE=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&= >=3Bnbsp=3D3D3B END=3D
>=3B >=3B=3D3D3B<=3BBR>=3B&=3B=3D3D>= >=3B >=3Bnbsp=3D3D3B END SameHost=3D3D3B<=3BBR>=3B>=3B >=3B&=3B= >nbsp=3D3D3B<=3BBR>=3B>=3B >=3BThoughts=3D
>=3B >=3B?<=3BBR= >>=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B>=3B >=3B<=3BBR>= >=3BPerhaps my network isn't setup well=3D3D2C like =3D
>=3B >=3BI sh= >ould add the local mach=3D3D>=3B >=3Bine to /etc/hosts.<=3BBR>=3BI = >think this can be =3D
>=3B >=3Bmade to fail gracefully though.<=3B= >B=3D3D>=3B >=3BR>=3BIt seems like it has nothing to do=3D
>=3B &= >gt=3B with AMD64_FREEBSD=3D3D2C but could have t=3D3D>=3B >=3Bo do with= > FreeBSD.<=3BBR>=3B>=3B >=3B<=3BBR=3D
>=3B >=3B>=3B&= >=3Bnbsp=3D3D3B<=3BBR>=3B>=3B >=3BSeems like SocketPosix has nearly = >the exact same code but=3D
>=3B >=3B appears<=3BBR>=3Bmore f=3D3= >D>=3B >=3Borgiving.. IOError instead of Fatal?<=3BBR>=3B>=3B >= >=3B&=3Bnbsp=3D3D=3D
>=3B >=3B3B<=3BBR>=3B>=3B >=3B<=3BB= >R>=3BSocketPosix.m3:<=3BBR>=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR= >>=3B>=3B >=3B<=3BBR>=3BPROCEDURE GetHostAd=3D
>=3B >=3Bdr = >(): Address<=3BBR>=3B&=3Bnbsp=3D3D3B RAISES {OSError.E} =3D3D3D<= >=3BBR=3D3D>=3B >=3B>=3B&=3Bnbsp=3D3D3B V=3D
>=3B >=3BAR<= >=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B host : AR= >RAY [0..255] OF CHAR=3D3D3B<=3B=3D3D=3D
>=3B >=3B>=3B >=3BBR&g= >t=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B info : Unetdb.st= >ruct_hostent_star=3D3D3B=3D
>=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3D&= >gt=3B >=3B=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B ua&=3Bnbsp=3D3D3= >B&=3Bnbsp=3D3D3B : Uin.struc=3D
>=3B >=3Bt_in_addr=3D3D3B<=3BBR= >>=3B&=3Bnbsp=3D3D3B =3D3D>=3B >=3BBEGIN<=3BBR>=3B&=3Bnbsp= >=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B =3D
>=3B >=3BIF Unix.get= >hostname (ADR (host[0])=3D3D2C BYT=3D3D>=3B >=3BESIZE (host)) # 0 THEN&= >lt=3BBR>=3B=3D
>=3B >=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&= >=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B IOError =3D3D>=3B >= >=3B(Unexpecte=3D
>=3B >=3Bd)=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B&= >amp=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B END=3D3D3B<=3BBR>=3B>=3B >=3B&a= >mp=3Bnbsp=3D3D3B&=3Bnbsp=3D3D=3D
>=3B >=3B3B&=3Bnbsp=3D3D3B in= >fo :=3D3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3D3B<=3B=3D3D>=3B &g= >t=3BBR=3D
>=3B >=3B>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3B= >nbsp=3D3D3B IF info =3D3D3D NIL THEN IOError (Unexpected)=3D
>=3B >= >=3B=3D3D3B EN=3D3D>=3B >=3BD=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B&= >=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B &=3Blt=3D3D3B* ASSERT inf=3D
>=3B = >>=3Bo.h_length &=3Blt=3D3D3B=3D3D3D BYT=3D3D>=3B >=3BESIZE (Addres= >s) *&=3Bgt=3D3D3B<=3BBR>=3B>=3B >=3B&=3Bnbsp=3D3D3=3D
>= >=3B >=3BB&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B ua :=3D3D3D LOOPHOLE(info.h= >_addr_list=3D3D2C<=3BBR>=3B&=3Bnbsp=3D3D3=3D
>=3B >=3BB&= >=3Bn=3D3D>=3B >=3Bbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3B= >nbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D=3D
>= >=3B >=3B3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D>=3B >= >=3B=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp= >=3D
>=3B >=3B=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp= >=3D3D3B UNTRACED REF UN=3D3D>=3B >=3BTRACED REF Uin.str=3D
>=3B &g= >t=3Buct_in_addr)^^=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B= >&=3Bnbsp=3D3D3B RETURN LOOP=3D3D>=3B >=3BHOLE=3D
>=3B >=3B (u= >a.s_addr=3D3D2C Address)=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B END GetHost= >Addr=3D3D3B<=3BBR>=3B>=3B >=3B&=3Bnb=3D
>=3B >=3Bsp=3D3D3= >B<=3BBR>=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B>=3B >=3BIt= > is again disappointing to see such code d=3D
>=3B >=3Buplication.&l= >t=3BBR>=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B>=3B >=3B&= >=3Bnbsp=3D3D3B<=3BBR>=3B>=3B >=3BI guess&=3Bnbsp=3D3D3BSameHo=3D= >
>=3B >=3Bst can duplicate the logic to predict the error state =3D3= >D>=3B >=3Band return fals=3D
>=3B >=3Be&=3Bnbsp=3D3D3Bupon er= >ror?<=3BBR>=3B>=3B >=3BDuplicating the logic for a third time. :(&l= >t=3BBR>=3B=3D
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>= >=3B>=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3D3B- Jay<=3BBR>=3B<=3BBR= >>=3B<=3B/body>=3B>=3B >=3B<=3B/html>=3B=3D3D>=3B >=3B>= >=3B >=3B--=3D
>=3B >=3B_9e67232c-a064-417d-879e-227a77e310f9_--=3D= >
>=3B >=3B
>=3B >=3B--_b00371fe-730b-4981-9051-a874361296d7_<= >BR>>=3B >=3BContent-Type: text/html=3B charset=3D"iso-8859-1"
>=3B= > >=3BContent-Transfer-Encoding: quoted-printable
>=3B >=3B
>= >=3B >=3B<=3Bhtml>=3B
>=3B >=3B<=3Bhead>=3B
>=3B >= >=3B<=3Bstyle>=3B
>=3B >=3B.hmmessage P
>=3B >=3B{
>= >=3B >=3Bmargin:0px=3D3B
>=3B >=3Bpadding:0px
>=3B >=3B}
= >>=3B >=3Bbody.hmmessage
>=3B >=3B{
>=3B >=3Bfont-size: 10= >pt=3D3B
>=3B >=3Bfont-family:Verdana
>=3B >=3B}
>=3B >= >=3B<=3B/style>=3B
>=3B >=3B<=3B/head>=3B
>=3B >=3B<= >=3Bbody class=3D3D'hmmessage'>=3B
>=3B >=3BDo you know the right w= >ay?<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B = >>=3BPPC_LINUX "just worked"=3D2C and I can check Solaris and Darwin.<= >=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B= >I don't want to edit /etc/hosts -- I use DHCP.<=3BBR>=3B
>=3B >= >=3BThough DHCP has been bothering me -- only for some of my machines do nam= >es =3D
>=3B >=3Bresolve=3D2C so I end using IP addresses=3D2C which = >change sometimes=3D2C and I l=3D
>=3B >=3Boop over them running ssh = >to all of them and "see what I get"=3D2C not ideal.=3D
>=3B >=3B<= >=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B= >&=3Bnbsp=3D3B- Jay<=3BBR>=3B<=3BBR>=3B<=3BBR>=3B&=3Bgt=3D= >3B To: jay.krell at cornell.edu<=3BBR>=3B&=3Bgt=3D3B Date: S=3D
>= >=3B >=3Bun=3D2C 11 Jan 2009 08:02:18 -0800<=3BBR>=3B&=3Bgt=3D3B Fr= >om: mika at async.caltech.edu<=3BBR>=3B=3D
>=3B >=3B&=3Bgt=3D3B = >CC: m3devel at elegosoft.com<=3BBR>=3B&=3Bgt=3D3B Subject: Re: [M3devel= >] Juno (X) =3D
>=3B >=3Bnetworking problem on AMD64_FREEBSD<=3BBR&= >gt=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B This is a screwy t=3D
&= >gt=3B >=3Bhing in Modula-3. A bug I would call it.<=3BBR>=3B&=3Bgt= >=3D3B <=3BBR>=3B&=3Bgt=3D3B I've noticed =3D
>=3B >=3Ba lot o= >f networking M3 programs don't work right unless<=3BBR>=3B&=3Bgt=3D3= >B the retur=3D
>=3B >=3Bn value of Unix's "hostname" maps to a real = >IP address via<=3BBR>=3B&=3Bgt=3D3B gethos=3D
>=3B >=3Btbynam= >e. I accomplish it in practice by adding my hostname<=3BBR>=3B&=3Bgt= >=3D3B to /et=3D
>=3B >=3Bc/hosts.<=3BBR>=3B&=3Bgt=3D3B <=3B= >BR>=3B&=3Bgt=3D3B This is obviously not the right way to fix it=3D
= >>=3B >=3B... <=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B = >Mika<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Jay writes:&l= >t=3BBR>=3B&=3Bgt=3D3B &=3B=3D
>=3B >=3Bgt=3D3B--_9e67232c-a0= >64-417d-879e-227a77e310f9_<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BConten= >t-Type:=3D
>=3B >=3B text/plain=3D3B charset=3D3D"iso-8859-1"<=3BB= >R>=3B&=3Bgt=3D3B &=3Bgt=3D3BContent-Transfer-Enco=3D
>=3B >= >=3Bding: quoted-printable<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BB= >R>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3BHi=3D
>=3B >=3B. Unix network programming question..<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3BAMD64_FREEBSD:<=3BBR>=3B&=3Bgt=3D>>=3B >=3B=3D3B &=3Bgt=3D3B$DISPLAY is set to point back to Cygwin h= >ost.It works for PPC_LIN=3D
>=3B >=3BUX.<=3BBR>=3B&=3Bgt=3D3B= > &=3Bgt=3D3B[jay at fbsdamd64a /cm3/bin]$ ./Juno<=3BBR>=3B&=3Bgt=3D3= >B &=3Bgt=3D3B*****=3D
>=3B >=3B* runtime error:*** Exception "IPE= >rror.FatalError" not in RAISES li=3D3D<=3BBR>=3B&=3B=3D
>=3B &g= >t=3Bgt=3D3B &=3Bgt=3D3Bst*** file "../src/common/IPError.m3"=3D3D2C line= > 27***<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >=3B &=3Bgt=3D3BAbort = >trap: 6 (core dumped)[jay at fbsdamd64a /cm3/bin]$<=3BBR>=3B&=3Bgt=3D3B= > &=3Bgt=3D
>=3B >=3B=3D3BIP.m3:<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BPROCEDURE GetHo= >stAddr(): Ad=3D
>=3B >=3Bdress =3D3D3D VAR hname: ARRAY [0..255] OF = >CHAR=3D3D3B =3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B BEG=3D
>= >=3B >=3BIN LOCK mu DO IF Unix.gethostname(ADR(hname[0])=3D3D2C BYTESIZE(h= >na=3D3D<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &=3Bgt=3D3Bme)) = ># 0 THEN IPError.Die ()=3D3D3B END=3D3D3B VAR h :=3D3D3D Unetdb.g=3D
>= >=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bethostbyname(ADR(= >hname[0]))=3D3D3B BEGIN IF h =3D3D3D NIL T=3D
>=3B >=3BHEN IPError.D= >ie()=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D3B END=3D3D3B RETU= >RN GetAddress(h)=3D3D=3D
>=3B >=3B3B END=3D3D3B END=3D3D3B END GetHo= >s=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BtAddr=3D3D3B<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3BPROCEDURE GetAddress (ent:= > Unetdb.struct_hostent_star): Address =3D3D3D VA=3D
>=3B >=3BR ua=3D= >3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B: Uin.struct_in_addr=3D3D3B BE= >GIN &=3Blt=3D3B* ASSERT ent.=3D
>=3B >=3Bh_length &=3Blt=3D3B= >=3D3D3D BYTESIZE(Addr=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bess) *= >&=3Bgt=3D3B ua :=3D3D3=3D
>=3B >=3BD LOOPHOLE(ent.h_addr_list=3D3= >D2C UNTRACED =3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BREF UNTRACED R= >=3D
>=3B >=3BEF Uin.struct_in_addr)^^=3D3D3B RETURN LOOPHOLE(ua.s_ad= >dr=3D3D2C A=3D3D<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >=3B &=3Bgt= >=3D3Bddress)=3D3D3B END GetAddress=3D3D3B<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B= >=3D3Bgethostbyname is failing.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B= >=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAnalogou=3D
>=3B >= >=3Bs C code also fails:<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20&l= >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B[jay at fbsdamd64a =3D
>=3B >= >=3B/cm3/bin]$ cat ~/5.c#include &=3Blt=3D3Bassert.h&=3Bgt=3D3B#includ= >e &=3Blt=3D3Bnetdb.h&=3Bgt=3D
>=3B >=3B=3D3B#i=3D3D<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3Bnclude &=3Blt=3D3Bstdio.h&=3Bgt=3D3B#= >include &=3Blt=3D3Berrno.h&=3Bg=3D
>=3B >=3Bt=3D3Btypedef stru= >ct hostent hostent_t=3D3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D= >20<=3BBR>=3B&=3Bgt=3D3B &=3B=3D
>=3B >=3Bgt=3D3Bint main()= >{ char hostname[200]=3D3D3B hostent_t* h=3D3D3B int i=3D3D3B<=3BBR>=3B&= >amp=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B i =3D3D3D gethostname(host= >name=3D3D2C 200)=3D3D3B assert(i =3D3D3D=3D3D3D=3D
>=3B >=3B 0)=3D3D= >3B printf("hostna=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bme: %s\n"= >=3D3D2C hostname)=3D3D3B h =3D
>=3B >=3B=3D3D3D gethostbyname(hostna= >me)=3D3D3B herror("foo")=3D3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3B p=3D
>=3B >=3Brintf("%p %d %d\n"=3D3D2C h=3D3D2C errno=3D3D2C = >h_errno)=3D3D3B assert(h)=3D3D3B retu=3D
>=3B >=3Brn 0=3D3D3B}<=3B= >BR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &a= >mp=3Bgt=3D3Bherror says "unknown host"=3D
>=3B >=3B.<=3BBR>=3B&a= >mp=3Bgt=3D3B &=3Bgt=3D3BStack is:<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3B at ../src/runtime/ex_frame/RTE=3D
>=3B >=3BxFrame.m3:58#13 0x0= >000000801a7f2b3 in RTH=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Books_= >_Raise (M=3D
>=3B >=3B3_AJWxb1_ex=3D3D3DError accessing memory addre= >ss 0x8000ffffd278: =3D3D<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &a= >mp=3Bgt=3D3BBad address.) at ../src/runtime/common/RTHooks.m3:79#14 0x00000= >00=3D
>=3B >=3B80169c8=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3Bd3 in IPError__Die () at ../src/common/IPError.m=3D
>=3B >=3B3:27#= >15 0x0000000801698a3e =3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bin IP= >__GetHostAddr (M3_BCxjP=3D
>=3B >=3Bn__result=3D3D3DError accessing = >memory address 0x80=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B00ffff= >=3D
>=3B >=3Bd338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x00000= >008012133d0=3D3D<=3BBR>=3B&=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt= >=3D3B in XSharedMem__SameHost (M3_AQuuui_trsl=3D3D3DError accessing mem=3D<= >BR>>=3B >=3Bory address 0=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3Bx8000ffffd4d8: Bad address.) at ../src/xvb=3D
>=3B >=3Bt/XSharedMe= >m.m3:96#17 0x000000=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B0801212a= >b7 in XSharedMem_=3D
>=3B >=3B_InitXClient (M3_AQuuui_v=3D3D3DError = >accessing memory=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B ad=3D
&= >gt=3B >=3Bdress 0x8000ffffd648: Bad address.) at ../src/xvbt/XSharedMem.m= >3:29#1=3D3D<=3BBR=3D
>=3B >=3B>=3B&=3Bgt=3D3B &=3Bgt=3D3B8= > 0x0000000801211819 in XExtensions__InitXClient (M3_AQuuui_x=3D
>=3B &= >gt=3Bclient=3D3D3DError=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B acc= >essing memory address 0x8000ffffd7f=3D
>=3B >=3B8: Bad address.) at = >../src/xvbt/X=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BExtensions.m3:= >14#19 0x=3D
>=3B >=3B00000008012467a4 in XClientF__Connect (M3_Bd56f= >i_inst=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D
>=3B >=3B= >=3D3D3D0x1879b=3D3D2C M3_AQuuui_trsl=3D3D3D0x6) at ../src/xvbt/XClientF.m3:= >583---=3D
>=3B >=3BTyp=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3Be &=3Blt=3D3Breturn&=3Bgt=3D3B to continue=3D3D2C or q &=3Blt=3D= >3Bret=3D
>=3B >=3Burn&=3Bgt=3D3B to quit---(More stack frames fol= >low=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B...)(gdb)<=3B=3D
&g= >t=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B(* return TRUE if server an= >d client are on same host *)PROC=3D
>=3B >=3BEDURE SameHost (=3D3D&l= >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Btrsl: XClient.T): BOOLEAN =3D3D3D = >VAR dis=3D
>=3B >=3Bplay :=3D3D3D DisplayH=3D3D<=3BBR>=3B&=3B= >gt=3D3B &=3Bgt=3D3Bost(trsl)=3D3D3B displayAddr: IP.Addr=3D
>=3B &g= >t=3Bess=3D3D3B BEGIN IF display =3D3D3D NIL THE=3D3D<=3BBR>=3B&=3Bgt= >=3D3B &=3Bgt=3D3BN RETURN TRUE=3D3D=3D
>=3B >=3B3B END=3D3D3B<= >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B TRY IF NOT IP.GetHostByName(displa= >y=3D3D2C displ=3D
>=3B >=3BayAddr) THEN RETURN FA=3D3D<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3BLSE=3D3D3B END=3D3D3B RETURN displayA=3D
&g= >t=3B >=3Bddr =3D3D3D IP.GetHostAddr()=3D3D3B EXCEPT =3D3D<=3BBR>=3B&a= >mp=3Bgt=3D3B &=3Bgt=3D3B| IP.Error =3D3D3D=3D
>=3B >=3B&=3Bgt= >=3D3B RETURN FALSE=3D3D3B END=3D3D3B END SameHost=3D3D3B<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BB=3D
>=3B >=3BR>=3B&=3Bgt= >=3D3B &=3Bgt=3D3BThoughts?<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D= >3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BPerhaps my n=3D
>=3B &g= >t=3Betwork isn't setup well=3D3D2C like I should add the local machine =3D3= >D<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &=3Bgt=3D3Bto /etc/hos= >ts.I think this can be made to fail gracefully though.=3D
>=3B >=3BI= >t seems l=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bike it has nothing= > to do with AMD64_FREEBSD=3D
>=3B >=3B=3D3D2C but could have to do w= >ith Fr=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BeeBSD.<=3BBR>=3B&= >amp=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B=3D3D20<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3BSeems like SocketPosix has nearly the exact same c= >=3D
>=3B >=3Bode but appearsmore forgi=3D3D<=3BBR>=3B&=3Bgt= >=3D3B &=3Bgt=3D3Bving.. IOError instead of Fata=3D
>=3B >=3Bl?<= >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B= > &=3Bgt=3D3BSocketPosix.m3:<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B= >=3D
>=3B >=3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BPROCE= >DURE GetHostAddr (): Address RAISES {OSError.E} =3D
>=3B >=3B=3D3D3D= > VAR host : AR=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BRAY [0..255] = >OF CHAR=3D3D3B info : Une=3D
>=3B >=3Btdb.struct_hostent_star=3D3D3B= > ua : U=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bin.struct_in_addr=3D= >3D=3D
>=3B >=3B3B BEGIN IF Unix.gethostname (ADR (host[0])=3D3D2C BY= >TESI=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D
>=3B >=3BZE = >(host)) # 0 THEN IOError (Unexpected)=3D3D3B END=3D3D3B<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B inf=3D
>=3B >=3Bo :=3D3D3D Unetdb.gethostb= >yname (ADR (host[0]))=3D3D3B IF info =3D3D3D NIL TH=3D3D<=3B=3D
>=3B= > >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BEN IOError (Unexpected)=3D3D3B = >END=3D3D3B &=3Blt=3D3B* ASSERT info.h=3D
>=3B >=3B_length &=3B= >lt=3D3B=3D3D3D BYTESIZE =3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B(Ad= >dress) *&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &= >=3Bgt=3D3B ua :=3D3D3D LOOPHOLE(info.h_addr_list=3D3D2C UNTRACED REF UNT=3D= >3D<=3BBR>=3B=3D
>=3B >=3B&=3Bgt=3D3B &=3Bgt=3D3BRACED REF = >Uin.struct_in_addr)^^=3D3D3B RETURN LOOPHOLE (ua.s_add=3D
>=3B >=3Br= >=3D3D2C Address=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B)=3D3D3B END= > GetHostAddr=3D3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D
>=3B >= >=3B=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR&g= >t=3B&=3Bgt=3D3B &=3Bgt=3D3BIt is again disappointing to=3D
>=3B = >>=3B see such code duplication.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3= >B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B=3D= >
>=3B >=3B&=3Bgt=3D3B &=3Bgt=3D3BI guess SameHost can duplicat= >e the logic to predict the error =3D
>=3B >=3Bstate and ret=3D3D<= >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Burn false upon error?<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3BDupl=3D
>=3B >=3Bicating the logic for = >a third time. :(<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR&= >gt=3B&=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B - Jay=3D3D<=3BBR&g= >t=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3= >B--_9e67232c-a064-417d-879e-22=3D
>=3B >=3B7a77e310f9_<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3BContent-Type: text/html=3D3B charset=3D3D"iso-= >8859-=3D
>=3B >=3B1"<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BConte= >nt-Transfer-Encoding: quoted-printable<=3BBR>=3B&=3Bgt=3D3B &=3Bg= >=3D
>=3B >=3Bt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Blt=3D3Bhtml&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Blt=3D3Bhead&=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3= >B &=3Bgt=3D3B&=3Blt=3D3Bstyle&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D= >3B &=3Bgt=3D3B.hmmessage P<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D= >
>=3B >=3B{<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bmargin:0px=3D3= >D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bpadding:0px<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B}<=3BBR>=3B&=3Bgt=3D3B = >&=3Bgt=3D3Bbody.hmmessage<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B{<= >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfont-=3D
>=3B >=3Bsize: 10pt= >=3D3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfont-family:Verdana<=3B= >BR>=3B&=3Bgt=3D3B &=3Bgt=3D3B}<=3BBR>=3B&=3Bg=3D
>=3B &= >gt=3Bt=3D3B &=3Bgt=3D3B&=3Blt=3D3B/style&=3Bgt=3D3B<=3BBR>=3B&= >amp=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3B/head&=3Bgt=3D3B<=3BBR>=3B= >&=3Bgt=3D3B &=3B=3D
>=3B >=3Bgt=3D3B&=3Blt=3D3Bbody class= >=3D3D3D'hmmessage'&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B= >Hi. Unix networ=3D
>=3B >=3Bk programming question..&=3Blt=3D3BBR= >&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3BBR&a= >mp=3Bgt=3D3BAMD64_=3D
>=3B >=3BFREEBSD:&=3Blt=3D3BBR&=3Bgt=3D3= >B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3BBR&=3Bgt=3D3B$= >DISPLAY is set to poi=3D
>=3B >=3Bnt back to Cygwin host.&=3Blt= >=3D3BBR&=3Bgt=3D3BIt works for PPC_LINUX=3D3D<=3BBR>=3B&=3Bgt=3D3= >B &=3Bg=3D
>=3B >=3Bt=3D3B.&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR= >>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3BBR&=3Bgt=3D3B[jay at fbsda= >md64a /cm3/bin]=3D
>=3B >=3B$ ./Juno&=3Blt=3D3BBR&=3Bgt=3D3B&l= >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3BBR&=3Bgt=3D3B***&= >amp=3Blt=3D3BBR&=3Bgt=3D3B*** r=3D
>=3B >=3Buntime error:&=3Bl= >t=3D3BBR&=3Bgt=3D3B***&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D= >3B&=3Bamp=3D3Bnbsp=3D
>=3B >=3B=3D3D3B Exception "IPE=3D3D<=3BB= >R>=3B&=3Bgt=3D3B &=3Bgt=3D3Brror.FatalError" not in RAISES list=3D<= >BR>>=3B >=3B&=3Blt=3D3BBR&=3Bgt=3D3B***&=3Bamp=3D3Bnbsp=3D3D3B= >&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B file "..=3D
>=3B = >>=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B/src/common/IPError.m= >3"=3D3D2C line 27&=3Blt=3D3BBR&=3Bgt=3D3B***&=3Bl=3D
>=3B >= >=3Bt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3B= >lt=3D3BBR&=3Bgt=3D3BAbort trap: 6 (core dumped)&=3Blt=3D
>=3B &g= >t=3B=3D3BBR&=3Bgt=3D3B[jay at fbsdamd64a /cm3/bin]$&=3Blt=3D3BBR&=3Bg= >t=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3BB=3D
>= >=3B >=3BR&=3Bgt=3D3BIP.m3:&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&= >=3Bgt=3D3B<=3B=3D
>=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BPR= >OCEDURE GetHostAddr(): Address =3D3D3D&=3Blt=3D3BBR&=3Bgt=3D3B&=3B= >amp=3D3B=3D
>=3B >=3Bnbsp=3D3D3B VAR hname: ARRAY [0..255] =3D3D<= >=3BBR>=3B&=3Bgt=3D3B OF CHAR=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D
>= >=3B >=3B=3D3B&=3Bamp=3D3Bnbsp=3D3D3B BEGIN&=3Blt=3D3BBR&=3Bgt=3D= >3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D
>= >=3B >=3B=3D3Bnbsp=3D3D3B LOCK mu DO&=3Blt=3D3BBR&=3Bgt=3D3B&=3Ba= >mp=3D3Bnbs=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bp=3D3D3B&=3Ba= >=3D
>=3B >=3Bmp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp= >=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B IF Unix.geth=3D
>=3B >=3B= >ostname(ADR(hname[0])=3D3D2C B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3BYTESIZE(hname)) # 0 THEN&=3Blt=3D
>=3B >=3B=3D3BBR&=3Bgt= >=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbs= >p=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B=3D
>=3B >=3B&=3Bamp=3D3Bnbsp= >=3D3D3B&=3Bamp=3D3Bnbsp=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B= >=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B IPErro=3D
>=3B >=3Br.Die ()=3D3D3B= >&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp= >=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B=3D
>=3B >=3B&=3Bamp=3D3Bnbsp=3D= >3D3B&=3Bamp=3D3Bnbsp=3D3D3B E=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3BND=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B=3D
>=3B >=3B&=3Bamp= >=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3B= >amp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D
>=3B >=3B=3D3D3B VAR h := >=3D3D3D Unetdb.gethost=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bbynam= >e(ADR(hname[0]))=3D
>=3B >=3B=3D3D3B BEGIN&=3Blt=3D3BBR&=3Bgt= >=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbs= >p=3D3D3B&=3Ba=3D
>=3B >=3Bmp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp= >=3D3D3B&=3Bamp=3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bnbsp= >=3D3D3B&=3Bamp=3D3Bnb=3D
>=3B >=3Bsp=3D3D3B IF h =3D3D3D NIL THEN= > IPError.Die()=3D3D3B END=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D= >
>=3B >=3B=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnb= >sp=3D
>=3B >=3B=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp= >=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B RETURN GetAddress(h)=3D
>=3B >=3B= >=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbs=3D3D<=3BBR>=3B&= >amp=3Bgt=3D3B &=3Bgt=3D3Bp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D= >
>=3B >=3B=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bn= >bsp=3D3D3B END=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bn=3D
&= >gt=3B >=3Bbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B = >END=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D3B&=3Blt=3D3B=3D= >
>=3B >=3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B END GetHostAddr= >=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D
>=3B >=3B=3D3B&=3Blt=3D3BBR&=3Bgt=3D3BPROCEDURE GetAddress= > (ent: Unetdb.struct_hostent_star): Ad=3D
>=3B >=3Bdress =3D3D3D&= >=3Blt=3D3BBR&=3Bgt=3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >amp=3Bamp=3D3Bnbsp=3D3D3B VAR ua: Uin.s=3D
>=3B >=3Btruct_in_addr=3D= >3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B BEGIN&=3Blt= >=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3B=3D
>=3B >=3Bnbsp=3D3D3B&=3Ba= >mp=3D3Bnbsp=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D3B&=3Bam= >p=3D3Bnbsp=3D3D3B &=3Bamp=3D3Blt=3D3D3=3D
>=3B >=3BB* ASSERT ent.= >h_length &=3Bamp=3D3Blt=3D3D3B=3D3D3D BYTESIZE(Address) *&=3Bamp=3D3B= >gt=3D3D3=3D
>=3B >=3BB=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnb= >sp=3D3D3B&=3Bamp=3D3Bn=3D
>=3B >=3Bbsp=3D3D3B ua :=3D3D3D LOOPHOL= >E(ent.h_addr_list=3D3D2C&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp= >=3D
>=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D3B= >&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3= >D3B&=3Ba=3D
>=3B >=3Bmp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B= >&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D<= >BR>>=3B >=3B=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B=3D3D<=3BBR>=3B&=3B= >gt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&= >amp=3Ba=3D
>=3B >=3Bmp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D
&= >gt=3B >=3B=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B UN= >=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BTRACED REF UNTR=3D
>= >=3B ACED REF Uin.struct_in_addr)^^=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbs=3D
>=3B >=3Bp=3D3D3B&=3B= >amp=3D3Bnbsp=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D3B RETURN = >LOOPHOLE(ua.s_addr=3D3D2C A=3D
>=3B >=3Bddress)=3D3D3B&=3Blt=3D3B= >BR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B END GetAddress=3D3D3B&=3Blt= >=3D3B=3D3D<=3BBR>=3B=3D
>=3B >=3B&=3Bgt=3D3B &=3Bgt=3D3BBR= >&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbs= >p=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D
>=3B = >>=3B=3D3B &=3Bgt=3D3Bgethostbyname is failing.&=3Blt=3D3BBR&=3Bg= >t=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3BBR&=3B=3D= >
>=3B >=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&=3Bgt= >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAnalogous C code also f=3D<= >BR>>=3B >=3Bails:&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt= >=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3= >B<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &=3Bgt=3D3B&=3Blt= >=3D3BBR&=3Bgt=3D3B[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c&=3Blt=3D3BBR&a= >mp=3Bgt=3D3B#=3D
>=3B >=3Binclude &=3Bamp=3D3Blt=3D3D3Bassert.h&a= >mp=3Bamp=3D3Bgt=3D3D3B&=3Blt=3D3BB=3D3D<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3BR&=3Bgt=3D
>=3B >=3B=3D3B#include &=3Bamp=3D3Blt=3D3= >D3Bnetdb.h&=3Bamp=3D3Bgt=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B#include &a= >mp=3Bamp=3D
>=3B >=3B=3D3Blt=3D3D3Bstdio.h&=3Bamp=3D3Bgt=3D3D3B&a= >mp=3Blt=3D3BBR&=3Bgt=3D3B#include =3D3D<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B&=3B=3D
>=3B >=3Bamp=3D3Blt=3D3D3Berrno.h&=3Bamp=3D3= >Bgt=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3Btypedef struct hostent host=3D
&= >gt=3B >=3Bent_t=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3B= >gt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&=3Bgt= >=3D3B<=3BBR>=3B=3D
>=3B >=3B&=3Bgt=3D3B &=3Bgt=3D3Bint mai= >n()&=3Blt=3D3BBR&=3Bgt=3D3B{&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp= >=3D3Bnbsp=3D3D3Bchar ho=3D
>=3B >=3Bstname[200]=3D3D3B&=3Blt=3D3B= >BR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3Bhostent_t* h=3D3D3B=3D3D<=3BBR&= >gt=3B&=3Bgt=3D
>=3B >=3B=3D3B &=3Bgt=3D3B&=3Blt=3D3BBR&= >=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3Bint i=3D3D3B&=3Blt=3D3BBR&=3Bgt= >=3D3B<=3BBR>=3B&=3Bgt=3D3B =3D
>=3B >=3B&=3Bgt=3D3B&=3B= >amp=3D3Bnbsp=3D3D3Bi =3D3D3D gethostname(hostname=3D3D2C 200)=3D3D3B&=3B= >lt=3D3BBR&=3Bg=3D
>=3B >=3Bt=3D3B&=3Bamp=3D3Bnbsp=3D3D3Bassert= >(i =3D3D3D=3D3D3D 0)=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D3B= >&=3Blt=3D3BBR=3D
>=3B >=3B&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3= >Bprintf("hostname: %s\n"=3D3D2C hostname)=3D3D3B&=3Blt=3D3BBR&=3Bg=3D= >
>=3B >=3Bt=3D3B&=3Bamp=3D3Bnbsp=3D3D3Bh =3D3D3D get=3D3D<=3BBR= >>=3B&=3Bgt=3D3B &=3Bgt=3D3Bhostbyname(hostname)=3D3D3=3D
>=3B = >>=3BB&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3Bherror("foo"= >)=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D
>=3B >= >=3B=3D3D3Bprintf("%p %=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bd %d\= >n"=3D3D2C h=3D3D2C errno=3D3D2C h_errno=3D
>=3B >=3B)=3D3D3B&=3Bl= >t=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3Bassert(h)=3D3D3B&=3Blt= >=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D
>=3B >=3B=3D3D3Bret=3D3D= ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Burn 0=3D3D3B&=3Blt=3D3BBR&= >=3Bgt=3D3B}&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D
>= >=3B >=3B=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&am= >p=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bherror says "unkno=3D= >
>=3B >=3Bwn host".&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3BBR&=3Bgt=3D3BStack is:&=3Blt= >=3D3BBR&=3Bgt=3D
>=3B >=3B=3D3B<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D= >3Bnbsp=3D3D3B at ../=3D
>=3B >=3Bsrc/runtime/ex_frame/RTExFrame.m3:5= >8&=3Blt=3D3BBR&=3Bgt=3D3B#13 =3D3D<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B0=3D
>=3B >=3Bx0000000801a7f2b3 in RTHooks__Raise (M3_AJWx= >b1_ex=3D3D3DError accessing memor=3D
>=3B >=3By=3D3D<=3BBR>=3B&a= >mp=3Bgt=3D3B &=3Bgt=3D3B ad&=3Blt=3D3BBR&=3Bgt=3D3Bdress 0x8000fff= >fd278: Bad address.&=3Blt=3D
>=3B >=3B=3D3BBR&=3Bgt=3D3B)&= >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3= >D3B&=3Bamp=3D3Bnbsp=3D3D3B =3D
>=3B >=3B=3D3D<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3Bat ../src/runtime/common/RTHooks.m3:79&=3Blt=3D= >3BBR&=3Bgt=3D3B#14=3D
>=3B >=3B 0x000000080169c8d3 in IPError=3D3= >D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B__Die () at ../src/common=3D>>=3B >=3B/IPError.m3:27&=3Blt=3D3BBR&=3Bgt=3D3B#15 0x00000008016= >98a3e in IP__Ge=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3B=3D
>=3B >= >=3Bgt=3D3BtHostAddr (M3_BCxjPn__result=3D3D3DError accessing mem&=3Blt= >=3D3BBR&=3Bgt=3D3Bory =3D
>=3B >=3Baddress 0x8000fff=3D3D<=3BBR= >>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfd338: Bad address.&=3Blt=3D3BBR&= >=3Bgt=3D3B)&=3Blt=3D
>=3B >=3B=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3= >Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B at ../src/= >POSIX=3D
>=3B >=3B/IP.m3:=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3B82&=3Blt=3D3BBR&=3Bgt=3D3B#16 0x00000008012133d0 in XShare=3D>>=3B >=3BdMem__SameHost (M3_AQuuui_trsl=3D3D3DErro=3D3D<=3BBR>=3B&= >amp=3Bgt=3D3B &=3Bgt=3D3Br accessing m&=3Blt=3D
>=3B >=3B=3D3B= >BR&=3Bgt=3D3Bemory address 0x8000ffffd4d8: Bad address.&=3Blt=3D3BBR&= >amp=3Bgt=3D3B)&=3Blt=3D3BB=3D
>=3B >=3BR&=3Bgt=3D3B&=3Bamp= >=3D3Bnbsp=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D3B&=3Bamp= >=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B=3D
>=3B >=3B at ../src/xv= >bt/XSharedMem.m3:96&=3Blt=3D3BBR&=3Bgt=3D3B#17 0x0000000801212a=3D3D&= >lt=3BBR>=3B&=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3Bb7 in XShared= >Mem__InitXClient (M3_AQuuui_v=3D3D3DError accessing m=3D
>=3B >=3B&a= >mp=3Blt=3D3BBR&=3Bgt=3D3Bemory add=3D3D<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3Bress 0x8000ffffd648: Bad address=3D
>=3B >=3B.&=3Blt=3D= >3BBR&=3Bgt=3D3B)&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B= >&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D
>=3B >=3B=3D3D3B at= > ../sr=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bc/xvbt/XSharedMem.m3:= >29&=3Blt=3D3BBR&=3Bgt=3D3B#18 =3D
>=3B >=3B0x0000000801211819 = >in XExtensions__InitXClie=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bnt= > (M3_AQuu=3D
>=3B >=3Bui_xclient=3D3D3DError acce&=3Blt=3D3BBR&am= >p=3Bgt=3D3Bssing memory address 0x8000ffffd7f8:=3D
>=3B >=3B =3D3D&l= >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BBad address.&=3Blt=3D3BBR&= >=3Bgt=3D3B)&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D
>=3B &= >gt=3B=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B at ../src/= >xvbt/XExtensions.m3=3D3D<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &a= >mp=3Bgt=3D3B:14&=3Blt=3D3BBR&=3Bgt=3D3B#19 0x00000008012467a4 in XCli= >entF__Connect (M=3D
>=3B >=3B3_Bd56fi_inst=3D3D3D0x1879=3D3D<=3BBR= >>=3B&=3Bgt=3D3B &=3Bgt=3D3Bb=3D3D2C&=3Blt=3D3BBR&=3Bgt=3D3B&a= >mp=3Bamp=3D3Bnbsp=3D
>=3B >=3B=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B M3_AQuuui_trsl=3D3D3D0x6) at ../src/xvb=3D
>=3B= > >=3Bt/XClie=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BntF.m3:583&am= >p=3Blt=3D3BBR&=3Bgt=3D3B---Type &=3Bamp=3D3Blt=3D3D3Bre=3D
>=3B = >>=3Bturn&=3Bamp=3D3Bgt=3D3D3B to continue=3D3D2C or q &=3Bamp=3D3Bl= >t=3D3D3Breturn&=3Bamp=3D3Bg=3D3D<=3BBR=3D
>=3B >=3B>=3B&= >=3Bgt=3D3B &=3Bgt=3D3Bt=3D3D3B to quit---&=3Blt=3D3BBR&=3Bgt=3D3B(= >More stack frames follow...)&=3B=3D
>=3B >=3Blt=3D3BBR&=3Bgt= >=3D3B(gdb)&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B&=3Blt=3D3BBR&=3Bgt=3D3B(* return TR=3D
>=3B >=3BUE = >if server and client are on same host *)&=3Blt=3D3BBR&=3Bgt=3D3BPROCE= >DURE Sa=3D3D<=3BBR=3D
>=3B >=3B>=3B&=3Bgt=3D3B &=3Bgt=3D3B= >meHost (trsl: XClient.T): BOOLEAN =3D3D3D&=3Blt=3D3BBR&=3Bgt=3D3B&= >=3Bamp=3D3Bn=3D
>=3B >=3Bbsp=3D3D3B VAR&=3Blt=3D3BBR&=3Bgt=3D3= >B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bn=3D3D&= >lt=3BBR>=3B&=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3Bbsp=3D3D3B di= >splay&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbs= >p=3D3D3B=3D
>=3B >=3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp= >=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bn= >bsp=3D
>=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3= >D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp= >=3D3D3B&=3Ba=3D
>=3B >=3Bmp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D= >3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp= >=3D
>=3B >=3B=3D3D3B :=3D3D3D Di=3D3D<=3BBR>=3B&=3Bgt=3D3B &a= >mp=3Bgt=3D3BsplayHost(trsl)=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp= >=3D
>=3B >=3B=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D= >3Bnbsp=3D3D3B displayAddr: IP.Address=3D3D3B&=3Bl=3D
>=3B >=3Bt= >=3D3BB=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BR&=3Bgt=3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B BEGIN&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3B= >=3D
>=3B >=3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbs= >p=3D3D3B IF display =3D3D3D NIL THEN RETURN=3D
>=3B >=3B=3D3D<=3BB= >R>=3B&=3Bgt=3D3B &=3Bgt=3D3B TRUE=3D3D3B END=3D3D3B&=3Blt=3D3BBR= >&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D
&= >gt=3B >=3B=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp= >=3D3D3B TRY&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D
>=3B &= >gt=3B=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp= >=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B IF=3D3D=3D
>=3B >=3B<= >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B NOT IP.GetHostByName(display=3D3D2= >C displayAddr) THEN RETUR=3D
>=3B >=3BN FALSE=3D3D3B END=3D3D3B&= >=3Blt=3D3BB=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BR&=3Bgt=3D3B&= >amp=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D
>=3B >=3B=3D3Bnbsp=3D3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B = >RETURN display=3D
>=3B >=3BAddr =3D3D3D IP.GetHos=3D3D<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3BtAddr()=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&a= >mp=3Bamp=3D3Bnb=3D
>=3B >=3Bsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B EXCEPT&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bn= >bsp=3D3D3=3D
>=3B >=3BB&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp= >=3D3D3B |=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B IP.Error =3D3D3D&= >amp=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D3B RETURN FALSE=3D3D3B&=3Blt=3D= >3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&= >=3B=3D
>=3B >=3Bamp=3D3Bnbsp=3D3D3B END=3D3D3B&=3Blt=3D3BBR&= >=3Bgt=3D3B&=3Bamp=3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bnb= >sp=3D3D3B =3D
>=3B >=3BEND SameHost=3D3D3B&=3Blt=3D3BBR&=3Bgt= >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&= >amp=3Blt=3D3BBR&=3Bgt=3D
>=3B >=3B=3D3B<=3BBR>=3B&=3Bgt=3D= >3B &=3Bgt=3D3BThoughts?&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3=3D
>=3B >=3BB&= >=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Blt=3D3BBR&=3Bgt=3D3BPerhaps my network isn't setu=3D
>=3B >=3B= >p well=3D3D2C like I should add the local mach=3D3D<=3BBR>=3B&=3Bgt= >=3D3B &=3Bgt=3D3Bine to /etc=3D
>=3B >=3B/hosts.&=3Blt=3D3BBR&= >amp=3Bgt=3D3BI think this can be made to fail gracefully though.&=3Blt= >=3D
>=3B >=3B=3D3BB=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BR= >&=3Bgt=3D3BIt seems like it has nothing to do with AMD6=3D
>=3B >= >=3B4_FREEBSD=3D3D2C but could have t=3D3D<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3Bo do with FreeBSD.&=3Blt=3D3B=3D
>=3B >=3BBR&=3Bgt= >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3BBR&=3Bgt= >=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B= >&=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3BSeems like SocketPosix has= > nearly the exact same code but appear=3D
>=3B >=3Bs&=3Blt=3D3BBR= >&=3Bgt=3D3Bmore f=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Borgivin= >g.. IOError instead of Fata=3D
>=3B >=3Bl?&=3Blt=3D3BBR&=3Bgt= >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&= >amp=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3B=3D
>= >=3B >=3Bgt=3D3B&=3Blt=3D3BBR&=3Bgt=3D3BSocketPosix.m3:&=3Blt=3D3= >BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3B= >nbs=3D
>=3B >=3Bp=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3BBR&=3Bgt=3D3BPROCEDURE GetHos= >tAddr ()=3D
>=3B >=3B: Address&=3Blt=3D3BBR&=3Bgt=3D3B&=3Ba= >mp=3D3Bnbsp=3D3D3B RAISES {OSError.E} =3D3D3D&=3Blt=3D3BBR=3D3D=3D
&g= >t=3B >=3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B&=3B= >amp=3D3Bnbsp=3D3D3B VAR&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D= >3D3B&=3Ba=3D
>=3B >=3Bmp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3= >B host : ARRAY [0..255] OF CHAR=3D3D3B&=3Blt=3D3B=3D3D<=3B=3D
>= >=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BBR&=3Bgt=3D3B&=3Bamp= >=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B in=3D<= >BR>>=3B >=3Bfo : Unetdb.struct_hostent_star=3D3D3B&=3Blt=3D3BBR&= >=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D<=3BBR>=3B&=3Bgt=3D3B =3D
>= >=3B >=3B&=3Bgt=3D3B=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbs= >p=3D3D3B ua&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D
>=3B >= >=3B=3D3D3B : Uin.struct_in_addr=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3B= >amp=3D3Bnbsp=3D3D3B =3D3D<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >=3B &= >amp=3Bgt=3D3BBEGIN&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&= >amp=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B =3D
>=3B >=3BIF = >Unix.gethostname (ADR (host[0])=3D3D2C BYT=3D3D<=3BBR>=3B&=3Bgt=3D3B= > &=3Bgt=3D3BESIZE (host)=3D
>=3B >=3B) # 0 THEN&=3Blt=3D3BBR&a= >mp=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp= >=3D3Bnbsp=3D3D3B&=3Bam=3D
>=3B >=3Bp=3D3Bnbsp=3D3D3B&=3Bamp=3D= >3Bnbsp=3D3D3B IOError =3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B(Unex= >pected)=3D3D3B=3D
>=3B >=3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp= >=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B END=3D= >3D3B&=3Blt=3D
>=3B >=3B=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3B= >gt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&= >amp=3Bamp=3D3Bnbsp=3D3D3=3D
>=3B >=3BB info :=3D3D3D Unetdb.gethostb= >yname (ADR (host[0]))=3D3D3B&=3Blt=3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B= > =3D
>=3B >=3B&=3Bgt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D= >3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B IF info =3D3D3=3D>>=3B >=3BD NIL THEN IOError (Unexpected)=3D3D3B EN=3D3D<=3BBR>=3B&= >amp=3Bgt=3D3B &=3Bgt=3D3BD=3D3D3B&=3Blt=3D3BBR&=3Bg=3D
>=3B &= >gt=3Bt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp= >=3D3Bnbsp=3D3D3B &=3Bamp=3D3Blt=3D3D3B* ASSERT=3D
>=3B >=3B info.= >h_length &=3Bamp=3D3Blt=3D3D3B=3D3D3D BYT=3D3D<=3BBR>=3B&=3Bgt=3D= >3B &=3Bgt=3D3BESIZE (Address) *=3D
>=3B >=3B&=3Bamp=3D3Bgt=3D3= >D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3= >B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D=3D
>=3B >=3B3B&a= >mp=3Bamp=3D3Bnbsp=3D3D3B ua :=3D3D3D LOOPHOLE(info.h_addr_list=3D3D2C&= >=3Blt=3D3BBR&=3Bgt=3D3B&=3Ba=3D
>=3B >=3Bmp=3D3Bnbsp=3D3D3B&am= >p=3Bamp=3D3Bn=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bbsp=3D3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnb=3D
>=3B >=3Bsp=3D3D3B&=3B= >amp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D
>=3B >=3B=3D3Bnbsp=3D3D3B&=3B= >amp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D<=3BBR>=3B&=3Bgt=3D3B &am= >p=3Bgt=3D3B=3D3D3B&=3Bamp=3D3Bnbsp=3D
>=3B >=3B=3D3D3B&=3Bamp= >=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3B= >amp=3D3Bnbsp=3D3D3B&=3Bamp=3D
>=3B >=3B=3D3Bnbsp=3D3D3B&=3Bamp= >=3D3Bnbsp=3D3D3B UNTRACED REF UN=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3BTRACED REF =3D
>=3B >=3BUin.struct_in_addr)^^=3D3D3B&=3Blt= >=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&a= >mp=3Bam=3D
>=3B >=3Bp=3D3Bnbsp=3D3D3B RETURN LOOP=3D3D<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3BHOLE (ua.s_addr=3D3D2C Address)=3D
>=3B &= >gt=3B=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B END Ge= >tHostAddr=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3B=3D
&= >gt=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BB= >R&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnb= >sp=3D3D3B=3D
>=3B >=3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&a= >mp=3Bgt=3D3B &=3Bgt=3D3BIt is again disappointing to see such code d=3D<= >BR>>=3B >=3Buplication.&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&=3Bg= >t=3D3B<=3BBR=3D
>=3B >=3B>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt= >=3D3B &=3Bgt=3D3BI guess&=3Bamp=3D3B=3D
>=3B >=3Bnbsp=3D3D3BSa= >meHost can duplicate the logic to predict the error state =3D3D<=3BBR=3D<= >BR>>=3B >=3B>=3B&=3Bgt=3D3B &=3Bgt=3D3Band return false&=3Ba= >mp=3D3Bnbsp=3D3D3Bupon error?&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B= >=3D
>=3B >=3B&=3Bgt=3D3B &=3Bgt=3D3BDuplicating the logic for = >a third time. :(&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bg=3D
= >>=3B >=3Bt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BB= >R&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3BBR&= >amp=3Bgt=3D3B&=3Bam=3D
>=3B >=3Bp=3D3Bnbsp=3D3D3B- Jay&=3Blt= >=3D3BBR&=3Bgt=3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Blt=3D3B/body&= >=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3B=3D
>=3B >=3Bgt=3D3B&a= >mp=3Blt=3D3B/html&=3Bgt=3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B--_9e67232c-a064=3D
>= >=3B >=3B-417d-879e-227a77e310f9_--<=3BBR>=3B<=3BBR>=3B<=3B/body= >>=3B
>=3B >=3B<=3B/html>=3B=3D
>=3B >=3B
>=3B >= >=3B--_b00371fe-730b-4981-9051-a874361296d7_--

>= > >--_b0c10337-0e1c-414e-aae5-e611dcd4be8a_-- From jay.krell at cornell.edu Mon Jan 12 10:46:24 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 09:46:24 +0000 Subject: [M3devel] SPARC32_LINUX Message-ID: SPARC32_LINUX is looking pretty decent now. min and std archives at: http://modula3.elegosoft.com/cm3/uploaded-archives/ There is something funny I saw where generated OSConfig.i3 had extra stuff at the end. But I rebuilt and it went away. System builds itself, Juno, formsedit, mentor come up. After a while on the splash screen, making progress, Juno exits with: Fatal error: cannot open or create "Untitled.juno" in the current directory Hm. That might be a real problem. Maybe time to unclone the stat header.. I have write access and AMD64_FREEBSD worked ok. (Ok to have "32" in the processor name?) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 10:56:43 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 09:56:43 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: <200901120934.n0C9YOs8074851@camembert.async.caltech.edu> References: Your message of "Mon, 12 Jan 2009 08:47:17 GMT." <200901120934.n0C9YOs8074851@camembert.async.caltech.edu> Message-ID: Yes, generating the headers is viable. I thought I mentioned that a few times. They could be generated in any build "that can". i.e. a native build, that has a working C development system and checked against the checked in ones. So then porting is: copy the generator to new system, run it, copy results back, proceed Maybe a good compromise. Not good for "embedded systems", but heck, is there any such thing any longer? Doesn't everything have megs of RAM and gigs of persistant storage? :) You don't need Scheme. Just Quake + compiling and running C code. Assuming a native build system. I've done stuff in cross build systems like: typedef struct foo_t {int i; int j; } foo_t; extern const int xi = offsetof(foo_t, i); compile that, and read the value of xi out of the .obj file. The .obj file reader was written in Perl. :) (Python not available.) but to do that here, I'd have to support multiple .obj file formats. - Jay> To: jay.krell at cornell.edu> Date: Mon, 12 Jan 2009 01:34:24 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?> > > You present it as a true tragic Dilemma.> > But isn't there a Third Way---to wit, can't you "Ask the Computer"> to do the work for you?> > Generate the code somehow... Parsing the C headers is an obvious> way but there may be others that are simpler, such as writing a> Modula-3 program to generate the cloned M3 headers, sorry, interfaces.> > If I had to do this I would use my Scheme interpreter that's coded> in Modula-3 to write a Scheme program to generate the headers. This> program could pull whatever tricks are deemed necessary and suitable,> down to the point of generating and compiling and running C programs> as necessary (or parsing C code, or reading tea leaves). But the> end result would be a set of interfaces written in "Pure Modula-3".> The process of running the header generator would also have very> few dependencies on anything outside the M3 distribution.> > Mika> > Jay writes:> >--_6117a048-9185-4c03-badb-ef8f93402268_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >This is what you "have to" chose between.> >Header cloning or C code (and C headers).> >=20> >CONST or VAR (or functions?)> >=20> >I'm going to likely make the Uerror change tonight.> >You can still veto it (er=2C vote against it :) )> >=20> >Possibly some convuluted C (enum/#undef)=2C or splitting the Modula-3> >at boundaries that weren't previously believed "natural".> >(See how SetupHandlers is ~two lines in Modula-3 and the rest in C=3B> >this is partly out of ignorance. I don't know how to write those> >two lines in C=3B and laziness=2C I didn't look into how).> >=20> >=20> >=20> >Remember I'm still staying away from mainstream platforms=2C> >so the value isn't what it might appear to be=2C but it is "stage setting"=> >=2C> >and the show might go on. :)> >=20> >=20> >Also=2C the dilemna does get more difficult now=2C with the little C header=> > cloning that remains.> >=20> >For example=2C look at Upthreads.i3.> >Mainly=2C look at function prototypes.> >Constants and types are "known problems".> >Prototypes are gray. They actually tend to be portable.> >=20> >For example:> >=20> >TYPE pid_t =3D INTEGER=3B> ><*EXTERNAL "m3_getpid*> PROCEDURE getpid():pid_t=3B> >=20> >or leave it alone?> >getpid is probably the worst example.> >It is so very portable declared in Modula-3.> >But still=2C imagine pid_t might be 16bits or 32 or 64.> >Writing a wrapper is more portable -- as long as the pid isn't stuff into s=> >ome record that the system defines.> >=20> >=20> >Again=2C Upthreads.i3.> >Would you like to see it reduced=2C or left alone?> >Only deal with the types and initializers=2C or also the prototypes?> >You know=2C I could write a little portable layer=2C where all the types ar=> >e pointers=2C always null initialized.> >It would buy /some/ portability=2C and cost some.> >=20> >=20> >Do you like the sem_t change? Partly? Not at all?> >There is one sem_t in the system. So I moved it to be in C code.> >Or=2C as I had it before=2C declared as the max size/align of all the platf=> >orms -- getting that right is the same work as getting it right "the old wa=> >y"=2C except if you make a mistake=2C odds are still good of it being ok.> >=20> >=20> >Should the line be drawn at generating the remaining headers=2C rather than=> > eliminating them?> >Uerror.i3 is easily generated. Good enough?> >=20> >Upthread.i3's types can be generated generally as records with opaque array=> >s with the right size and alignment.> >=20> >Other stuff can be generated or at least checked.> >e.g. to check that getpid is declared correctly=2C you can assign it to a f=> >unction pointer and see if that compiles.> >=20> >Perf on Uerror arguably doesn't matter.> >Is it only error handling code?Or do sockets often go down "error" paths=2C=> > because they are slow and you are waiting for more data?> >=20> >Anyway=2C point is=2C I agree for sure this is valuable=2C but I might be h=> >itting the "tail" of the approach and should switch=2C I'm not sure. I keep=> > saying that though=2C and then press further.> >=20> >=20> > - Jay> >> >> >> >From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon=2C 12 Jan 200=> >9 19:24:50 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a=> > type's existance but not enough to instantiate it?> >> >> >Point taken. We live in a C universe and so need to interact. I do think => >your work with the headers is useful=2C and I want it to continue. Especia=> >lly in simplifying ports.> >> >> >On 12 Jan 2009=2C at 19:18=2C Jay wrote:> >> >I don't think a development system without C headers is interesting.. Is it=> > really? The transform I apply at times is wherever there is interaction wi=> >th C code that is described by system-dependent headers=2C or perhaps even => >fairly system-independent headers outside the Modula-3 tree=2C either write=> > wrapper functions for the functionality in the headers (e.g. stat=2C waitp=> >id)=2C which can be done in a system-independent way=2C or move the Modula-=> >3<->C transition higher=2C which is also usually system-independent=2C e.g.=> > ThreadPThreadC_SetupHandlers. It is either that or clone the headers=2C wh=> >ich seems like the worse evil. There is always going to be a Modula-3<->C t=> >ransition=2C it is just a matter of where it occurs. - Jay> >> >CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.e=> >duSubject: Re: [M3devel] declaring a type's existance but not enough to ins=> >tantiate it?Date: Mon=2C 12 Jan 2009 12:32:15 +1100> >> >> >Jay=2C I really think you are bending over backwards too far just to be abl=> >e to shoe-horn things into C. I *like* having the transpar of C header fil=> >es expressed in Modula-3=2C *particularly* for system calls=2C where you mi=> >ght even be trying to build on a system that does not have the C header fil=> >es installed=2C even though the libraries exist and can be linked to. Fund=> >amentally=2C I think anytime the Modula-3 code is made less transparent you=> > should think hard about what you are doing. The same with the change of c=> >onstants to variables.> >> >I am getting very nervous that the changes you are making are destroying th=> >e clarity of the Modula-3 run-time code.> >> >In this particular case=2C you are wanting to use a Modula-3 parameter pass=> >ing mechanism on something that is not declared in Modula-3. Seems kind of=> > dubious to me. Also=2C I really don't like the idea of accessing external=> > variables in C.> >> >-- Tony> >> >On 12 Jan 2009=2C at 11:55=2C Jay wrote:> >> >I considered ADDRESS.However I think it still doesn't satisfy. I want to be=> > able to do this: TYPE Foo_t =3D something=3B<* EXTERNAL *> VAR Foo1=2C Foo=> >2:Foo_t=3B<* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t)=> >=3B (* Modula-3=2C not external *)PROCEDURE x()=3DBEGIN UseFoo(Foo1)=3B U=> >seFoo(Foo2)=3BEND x=3B AND I want any use of:VAR Foo3:Foo3_t=3B (* Modula-3=> >=2C not external *)to error. This is sem_t and sigset_t in particular. Poss=> >ibly renaming is the thing.They used to be declared in Modula-3=2C system-d=> >ependently=2C butI moved them to portable C. I could remove the types entir=> >ely and change UseFoo to take an address=2Cand declare mask and ackSem to b=> >e integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END=3B That would sat=> >isfy but I thought it might be nicer to still provide the namedtypes to ref=> >er to the external variables. - Jay> >> >From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon=2C 12 Jan 200=> >9 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a=> > type's existance but not enough to instantiate it?What's wrong with using => >ADDRESS for references to opaque values? If sigset_t is never instantiated=> > in Modula-3=2C then why do you need it declared there?> >> >> >> >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=2C at 01:44=2C Jay wrote:> >> >Is there a way in Modula-3 to declare that a type exists=2C and there are <=> >*external*> instances of it=2C without "fully" declaring it=2C so that no M=> >odula-3 can instantiate it? I have done this for sigset_t and sem_t=2C but => >they could erroneously be instantiated by Modula-3 and I'd like to remove t=> >hat ability to mess up so easily. (* This type is not declared correctly. I=> >t is only instantiated in C code. *) sigset_t =3D RECORD END=3B(* This typ=> >e is not declared correctly. It is only instantiated in C code. *) sem_t => >=3D RECORD END=3BIn C I believe you can do this=2C like: typedef struct fo=> >o foo_t=3B extern foo_t foo=3B void UseFoo(foo_t*)=3B foo_t* GetFoo=> >(void)=3B Thanks=2C - Jay=> >> >--_6117a048-9185-4c03-badb-ef8f93402268_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >> >This is what you "have to" chose between.
> >Header cloning or C code (and C headers).
> > =3B
> >CONST or VAR (or functions?)
> > =3B
> >I'm going to likely make the Uerror change tonight.
> >You can still veto it (er=2C vote against it :) )
> > =3B
> >Possibly some convuluted C (enum/#undef)=2C or splitting the Modula-3
> >at boundaries that weren't previously believed "natural".
> >(See how SetupHandlers is ~two lines in Modula-3 and the rest in C=3B
> >this is partly out of ignorance. I don't know how to write those
> >two lines in C=3B and laziness=2C I didn't look into how).
> > =3B
> > =3B
> > =3B
> >Remember I'm still staying away from mainstream platforms=2C
> >so the value isn't what it might appear to be=2C but it is "stage setting"=> >=2C
> >and the show might go on. :)
> > =3B
> > =3B
> >Also=2C the dilemna does get more difficult now=2C with the little C header=> > cloning that remains.
> > =3B
> >For example=2C look at Upthreads.i3.
> >Mainly=2C look at function prototypes.
> >Constants and types are "known problems".
> >Prototypes are gray. They actually tend to be portable.
> > =3B
> >For example:
> > =3B
> >TYPE pid_t =3D INTEGER=3B
> ><=3B*EXTERNAL "m3_getpid*>=3B PROCEDURE getpid():pid_t=3B
> > =3B
> >or leave it alone?
> >getpid is probably the worst example.
> >It is so very portable declared in Modula-3.
> >But still=2C imagine pid_t might be 16bits or 32 or 64.
> >Writing a wrapper is more portable -- as long as the pid isn't stuff into s=> >ome record that the system defines.
> > =3B
> > =3B
> >Again=2C Upthreads.i3.
> >Would you like to see it reduced=2C or left alone?
> >Only deal with the types and initializers=2C or also the prototypes?
> >You know=2C I could write a little portable layer=2C where all the types ar=> >e pointers=2C always null initialized.
> >It would buy /some/ portability=2C and cost some.
> > =3B
> > =3B
> >Do you like the sem_t change? Partly? Not at all?
> >There is one sem_t in the system. So I moved it to be in C code.
> >Or=2C as I had it before=2C declared as the max size/align of all the platf=> >orms -- getting that right is the same work as getting it right "the old wa=> >y"=2C except if you make a mistake=2C odds are still good of it being ok. >R>> > =3B
> > =3B
> >Should the line be drawn at generating the remaining headers=2C rather than=> > eliminating them?
> >Uerror.i3 is easily generated. Good enough?
> > =3B
> >Upthread.i3's types can be generated generally as records with opaque array=> >s with the right size and alignment.
> > =3B
> >Other stuff can be generated or at least checked.
> >e.g. to check that getpid is declared correctly=2C you can assign it to a f=> >unction pointer and see if that compiles.
> > =3B
> >Perf on Uerror arguably doesn't matter.
> >Is it only error handling code?
Or do sockets often go down "error" path=> >s=2C because they are slow and you are waiting for more data?
> > =3B
> >Anyway=2C point is=2C I agree for sure this is valuable=2C but I might be h=> >itting the "tail" of the approach and should switch=2C I'm not sure. I keep=> > saying that though=2C and then press further.
> > =3B
> > =3B
> > =3B- Jay

> >> >
>
> >From: hosking at cs.purdue.edu
To: jay.krell at cornell.edu
Date: Mon=2C 12=> > Jan 2009 19:24:50 +1100
CC: m3devel at elegosoft.com
Subject: Re: [M3de=> >vel] declaring a type's existance but not enough to instantiate it?

=> >
> >
>12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-IND=> >ENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPS=> >E: separate">> >
>e=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B C=> >OLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-S=> >PACING: normal=3B BORDER-COLLAPSE: separate"> >pan style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: n=> >one=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B => >LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate"> >-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRAN=> >SFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: no=> >rmal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate"> >EC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B T=> >EXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-S=> >PACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate"> >class=3DEC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvet=> >ica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B=> > WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate=> >"> >x Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT=> >: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: => >separate"> >ONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEX=> >T-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-CO=> >LLAPSE: separate"> >0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0=> >)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B B=> >ORDER-COLLAPSE: separate">> >
Point taken.  =3BWe live in a C universe and so need to interact. => > =3BI do think your work with the headers is useful=2C and I want it to=> > continue.  =3BEspecially in simplifying ports.
> >

 >V>
> >
> >
On 12 Jan 2009=2C at 19:18=2C Jay wrote:

>erchange-newline>> >
> FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B T=> >EXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-=> >COLLAPSE: separate">> >
>>I don't think a development system without C headers is interesting.. Is i=> >t really?
 =3B
The transform I apply at times is wherever there i=> >s interaction with C code that is described by system-dependent headers=2C => >or perhaps even fairly system-independent headers outside the Modula-3 tree=> >=2C either write wrapper functions for the functionality in the headers (e.=> >g. stat=2C waitpid)=2C which =3Bcan be done in a system-independent way=> >=2C =3Bor move the Modula-3<=3B->=3BC transition higher=2C which is=> > also usually system-independent=2C e.g. ThreadPThreadC_SetupHandlers.
&=> >nbsp=3B
It is either that or clone the headers=2C which seems like the w=> >orse evil.
 =3B
There is always going to be a Modula-3<=3B->=> >=3BC transition=2C it is just a matter of where it occurs.
 =3B
&=> >nbsp=3B- Jay

> >
> >
CC: =3B >lto:m3devel at elegosoft.com">m3devel at elegosoft.com
From: >EC_Apple-converted-space> =3B >.edu">hosking at cs.purdue.edu
To: >e> =3Bjay.krell at cornell=> >.edu
Subject: Re: [M3devel] declaring a type's existance but not eno=> >ugh to instantiate it?
Date: Mon=2C 12 Jan 2009 12:32:15 +1100

>R>>
>T: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-=> >INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLL=> >APSE: separate">> >
>tyle=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=> >=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LET=> >TER-SPACING: normal=3B BORDER-COLLAPSE: separate"> >-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRAN=> >SFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: no=> >rmal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate"> >EC_EC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=> >=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WH=> >ITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate"><=> >SPAN class=3DEC_EC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12p=> >x Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT=> >: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: => >separate"> >=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=> >=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BO=> >RDER-COLLAPSE: separate"> >-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb=> >(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: n=> >ormal=3B BORDER-COLLAPSE: separate"> >yle=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B=> > COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER=> >-SPACING: normal=3B BORDER-COLLAPSE: separate"> >yle-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFO=> >RM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: norma=> >l=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate">> >
Jay=2C I really think you are bending over backwards too far just to b=> >e able to shoe-horn things into C.  =3BI *like* having the transpar of => >C header files expressed in Modula-3=2C *particularly* for system calls=2C => >where you might even be trying to build on a system that does not have the => >C header files installed=2C even though the libraries exist and can be link=> >ed to.  =3BFundamentally=2C I think anytime the Modula-3 code is made l=> >ess transparent you should think hard about what you are doing.  =3BThe=> > same with the change of constants to variables.
> >

> >
I am getting very nervous that the changes you are making are destroyi=> >ng the clarity of the Modula-3 run-time code.
> >

> >
In this particular case=2C you are wanting to use a Modula-3 parameter=> > passing mechanism on something that is not declared in Modula-3.  =3BS=> >eems kind of dubious to me.  =3BAlso=2C I really don't like the idea of=> > accessing external variables in C.
> >

> >
-- Tony
<=> >/DIV>

> >
> >
On 12 Jan 2009=2C at 11:55=2C Jay wrote:

>interchange-newline>> >
>=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=> >=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BO=> >RDER-COLLAPSE: separate">> >
>na">I considered ADDRESS.
However I think it still doesn't satisfy.
&=> >nbsp=3B
I want to be able to do this:
 =3B
TYPE =3BFoo_t => >=3D something=3B
<=3B* EXTERNAL *>=3B VAR Foo1=2C Foo2:Foo_t=3B
&=> >lt=3B* EXTERNAL *>=3B PROCEDURE =3BUseFoo(READONLY (* or VAR *) foo:F=> >oo_t)=3B
 =3B
(* Modula-3=2C not external *)
PROCEDURE x()=3D<=> >BR>BEGIN
 =3B UseFoo(Foo1)=3B
 =3B UseFoo(Foo2)=3B
END x=> >=3B
 =3B
AND I want any use of:
VAR Foo3:Foo3_t=3B (* Modula-3=> >=2C not external *)

to error. This is sem_t and sigset_t in particul=> >ar.
 =3B
Possibly renaming is the thing.
They used to be decla=> >red in Modula-3=2C system-dependently=2C but
I moved them to portable C.=> >
 =3B
I could remove the types entirely and change UseFoo to take=> > an address=2C
and declare mask and ackSem to be integers or I guess. >><=3B*EXTERNAL>=3B VAR ackSem =3B: RECORD END=3B
 =3B
Tha=> >t would satisfy but I thought it might be nicer to still provide the named<=> >BR>types to refer to the external variables.
 =3B
 =3B- Jay >R>
> >
> >
From: =3B >=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu
To: >ss=3DEC_EC_Apple-converted-space> =3B >@cornell.edu">jay.krell at cornell.edu
Date: Mon=2C 12 Jan 2009 11:13:0=> >0 +1100
CC: =3B >ref=3D"mailto:m3devel at elegosoft.com">m3devel at elegosoft.com
Subject: => >Re: [M3devel] declaring a type's existance but not enough to instantiate it=> >?

What's wrong with using ADDRESS for references to opaque values? &=> >nbsp=3BIf sigset_t is never instantiated in Modula-3=2C then why do you nee=> >d it declared there?
> >

> >
>FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TE=> >XT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-C=> >OLLAPSE: separate">> >
>n style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: non=> >e=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LE=> >TTER-SPACING: normal=3B BORDER-COLLAPSE: separate"> >pple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-=> >TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE=> >: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate"> >s=3DEC_EC_EC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helv=> >etica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=> >=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separ=> >ate"> >FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TE=> >XT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-C=> >OLLAPSE: separate"> >ACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=> >=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: nor=> >mal=3B BORDER-COLLAPSE: separate"> >tyle=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=> >=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LET=> >TER-SPACING: normal=3B BORDER-COLLAPSE: separate"> >ple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-T=> >RANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE:=> > normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate"> >=3DEC_EC_EC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helve=> >tica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=> >=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separ=> >ate">> >
>EC_EC_EC_Apple-style-span face=3D"Gill Sans"> >tyle-span style=3D"COLOR: rgb(0=2C0=2C255)=3B FONT-FAMILY: 'Gill Sans'"> >AN class=3DEC_EC_EC_Apple-style-span style=3D"COLOR: rgb(0=2C0=2C255)=3B FO=> >NT-FAMILY: 'Gill Sans'">Antony Hosking >ss=3DEC_EC_EC_Apple-style-span face=3D"Gill Sans"> >ple-style-span style=3D"FONT-FAMILY: 'Gill Sans'"> >ple-style-span style=3D"FONT-FAMILY: 'Gill Sans'"> >-converted-space> =3B|=> > =3B >=3D"FONT-FAMILY: 'Gill Sans'"> >=3D"FONT-FAMILY: 'Gill Sans'">Associate Professor >=3DEC_EC_EC_Apple-style-span style=3D"FONT-FAMILY: 'Gill Sans'"> >=3DEC_EC_EC_Apple-style-span style=3D"FONT-FAMILY: 'Gill Sans'"> =3B| C=> >omputer Science | Purdue University
> >
>ass=3DEC_EC_EC_Apple-style-span style=3D"FONT-FAMILY: GillSans-Light">305 N=> >. University Street | West Lafayette | IN 47907 | USA
> >
>00ff> >5)=3B FONT-FAMILY: 'Gill Sans'"> >le=3D"COLOR: rgb(0=2C0=2C255)=3B FONT-FAMILY: 'Gill Sans'">Office >PAN> >PAN class=3DEC_EC_EC_Apple-style-span style=3D"FONT-FAMILY: GillSans-Light"=> >> >ht"> =3B+1 765 494 6001 |&nbs=> >p=3B >e=3D"Gill Sans" color=3D#0000ff> >le=3D"COLOR: rgb(0=2C0=2C255)=3B FONT-FAMILY: 'Gill Sans'"> >_EC_EC_Apple-style-span style=3D"COLOR: rgb(0=2C0=2C255)=3B FONT-FAMILY: 'G=> >ill Sans'">Mobile >an face=3DGillSans-Light> >ONT-FAMILY: GillSans-Light"> >=3D"FONT-FAMILY: GillSans-Light">=> > =3B+1 765 427 5484
> >

>s=3DEC_EC_EC_khtml-block-placeholder>
 >AN>
>AN>

> >
> >
On 12 Jan 2009=2C at 01:44=2C Jay wrote:

>le-interchange-newline>> >
>0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0=> >)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B B=> >ORDER-COLLAPSE: separate">> >
>rdana">Is there a way in Modula-3 to declare that =3Ba type exists=2C a=> >nd there are <=3B*external*>=3B instances of it=2C without "fully" decl=> >aring it=2C so that no Modula-3 can instantiate it?
 =3B
I have d=> >one this for sigset_t and sem_t=2C but they could erroneously be instantiat=> >ed by Modula-3 and I'd like to remove that ability to mess up so easily. >> =3B
(* This type is not declared correctly. It is only instantiate=> >d in C code. *)
 =3B sigset_t =3D RECORD END=3B

(* This type => >is not declared correctly. It is only instantiated in C code. *)
 => >=3B sem_t =3D RECORD END=3B

In C I believe you can do this=2C like:<=> >BR> =3B =3Btypedef struct foo foo_t=3B =3B >C_Apple-converted-space> =3B
 =3B =3Bextern foo_t foo=> >=3B =3B =3B
=> > =3B
 =3Bvoid UseFoo(foo_t*)=3B >erted-space> =3B
 =3B foo_t* GetFoo(void)=3B >=3DEC_EC_EC_Apple-converted-space> =3B
 =3B
Thanks=2C<=> >BR> =3B- Jay




<=> >/DIV>
=> >

>V>
> >=> >> >--_6117a048-9185-4c03-badb-ef8f93402268_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Jan 12 11:13:25 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 12 Jan 2009 02:13:25 -0800 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: Your message of "Mon, 12 Jan 2009 09:56:43 GMT." Message-ID: <200901121013.n0CADQE0075969@camembert.async.caltech.edu> I think you're misunderstanding me a bit. You don't need C either. I would use a Lisp-based language for the "top level" just because they are good at handling things like parse trees, if one gets to that. The objectives are: * A finished system in Pure Modula-3 (no executable C) * Make it as self-contained as possible You'd start by simply bundling the existing headers with m3bundle and printing them out. Then you'd find duplication (what you've been doing) and express that programmatically. Then you might find things that might conceivably change in the OS headers and use whatever tricks were necessary to figure them out automatically. Does this involve C? Maybe on some architecture it does, maybe on another it doesn't. On some it might not involve running C but merely parsing C headers. Perhaps the program is just hand-written and just a way of distilling all the duplication into one place where it can be clearly described and documented. Since this is a Modula-3 distribution, obviously the program I'm talking about is written in Modula-3, not in C or Perl or Python. Mika Jay writes: >--_2e194b09-14b6-4301-9116-a9e4d1e522b4_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Yes=2C generating the headers is viable. >I thought I mentioned that a few times. >They could be generated in any build "that can". i.e. a native build=2C th= >at has a working C development system and checked against the checked in o= >nes. > So then porting is: copy the generator to new system=2C run it=2C copy r= >esults back=2C proceed=20 > Maybe a good compromise. Not good for "embedded systems"=2C but heck=2C i= >s there any such thing any longer? Doesn't everything have megs of RAM and= > gigs of persistant storage? :) >You don't need Scheme. >Just Quake + compiling and running C code. >Assuming a native build system. >I've done stuff in cross build systems like: >typedef struct foo_t {int i=3B int j=3B } foo_t=3B >extern const int xi =3D offsetof(foo_t=2C i)=3B >=20 >compile that=2C and read the value of xi out of the .obj file. >=20 > The .obj file reader was written in Perl. :)=20 > (Python not available.) > but to do that here=2C I'd have to support multiple .obj file formats. >=20 > - Jay> To: jay.krell at cornell.edu> Date: Mon=2C 12 Jan 2009 01:34:24 -0800>= > From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3d= >evel] declaring a type's existance but not enough to instantiate it?> > > Y= >ou present it as a true tragic Dilemma.> > But isn't there a Third Way---to= > wit=2C can't you "Ask the Computer"> to do the work for you?> > Generate t= >he code somehow... Parsing the C headers is an obvious> way but there may b= >e others that are simpler=2C such as writing a> Modula-3 program to generat= >e the cloned M3 headers=2C sorry=2C interfaces.> > If I had to do this I wo= >uld use my Scheme interpreter that's coded> in Modula-3 to write a Scheme p= >rogram to generate the headers. This> program could pull whatever tricks ar= >e deemed necessary and suitable=2C> down to the point of generating and com= >piling and running C programs> as necessary (or parsing C code=2C or readin= >g tea leaves). But the> end result would be a set of interfaces written in = >"Pure Modula-3".> The process of running the header generator would also ha= >ve very> few dependencies on anything outside the M3 distribution.> > Mika>= > > Jay writes:> >--_6117a048-9185-4c03-badb-ef8f93402268_> >Content-Type: t= >ext/plain=3B charset=3D"iso-8859-1"> >Content-Transfer-Encoding: quoted-pri= >ntable> >> >> >This is what you "have to" chose between.> >Header cloning o= >r C code (and C headers).> >=3D20> >CONST or VAR (or functions?)> >=3D20> >= >I'm going to likely make the Uerror change tonight.> >You can still veto it= > (er=3D2C vote against it :) )> >=3D20> >Possibly some convuluted C (enum/#= >undef)=3D2C or splitting the Modula-3> >at boundaries that weren't previous= >ly believed "natural".> >(See how SetupHandlers is ~two lines in Modula-3 a= >nd the rest in C=3D3B> >this is partly out of ignorance. I don't know how t= >o write those> >two lines in C=3D3B and laziness=3D2C I didn't look into ho= >w).> >=3D20> >=3D20> >=3D20> >Remember I'm still staying away from mainstre= >am platforms=3D2C> >so the value isn't what it might appear to be=3D2C but = >it is "stage setting"=3D> >=3D2C> >and the show might go on. :)> >=3D20> >= >=3D20> >Also=3D2C the dilemna does get more difficult now=3D2C with the lit= >tle C header=3D> > cloning that remains.> >=3D20> >For example=3D2C look at= > Upthreads.i3.> >Mainly=3D2C look at function prototypes.> >Constants and t= >ypes are "known problems".> >Prototypes are gray. They actually tend to be = >portable.> >=3D20> >For example:> >=3D20> >TYPE pid_t =3D3D INTEGER=3D3B> >= ><*EXTERNAL "m3_getpid*> PROCEDURE getpid():pid_t=3D3B> >=3D20> >or leave it= > alone?> >getpid is probably the worst example.> >It is so very portable de= >clared in Modula-3.> >But still=3D2C imagine pid_t might be 16bits or 32 or= > 64.> >Writing a wrapper is more portable -- as long as the pid isn't stuff= > into s=3D> >ome record that the system defines.> >=3D20> >=3D20> >Again=3D= >2C Upthreads.i3.> >Would you like to see it reduced=3D2C or left alone?> >O= >nly deal with the types and initializers=3D2C or also the prototypes?> >You= > know=3D2C I could write a little portable layer=3D2C where all the types a= >r=3D> >e pointers=3D2C always null initialized.> >It would buy /some/ porta= >bility=3D2C and cost some.> >=3D20> >=3D20> >Do you like the sem_t change? = >Partly? Not at all?> >There is one sem_t in the system. So I moved it to be= > in C code.> >Or=3D2C as I had it before=3D2C declared as the max size/alig= >n of all the platf=3D> >orms -- getting that right is the same work as gett= >ing it right "the old wa=3D> >y"=3D2C except if you make a mistake=3D2C odd= >s are still good of it being ok.> >=3D20> >=3D20> >Should the line be drawn= > at generating the remaining headers=3D2C rather than=3D> > eliminating the= >m?> >Uerror.i3 is easily generated. Good enough?> >=3D20> >Upthread.i3's ty= >pes can be generated generally as records with opaque array=3D> >s with the= > right size and alignment.> >=3D20> >Other stuff can be generated or at lea= >st checked.> >e.g. to check that getpid is declared correctly=3D2C you can = >assign it to a f=3D> >unction pointer and see if that compiles.> >=3D20> >P= >erf on Uerror arguably doesn't matter.> >Is it only error handling code?Or = >do sockets often go down "error" paths=3D2C=3D> > because they are slow and= > you are waiting for more data?> >=3D20> >Anyway=3D2C point is=3D2C I agree= > for sure this is valuable=3D2C but I might be h=3D> >itting the "tail" of = >the approach and should switch=3D2C I'm not sure. I keep=3D> > saying that = >though=3D2C and then press further.> >=3D20> >=3D20> > - Jay> >> >> >> >Fro= >m: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon=3D2C 12 Jan 200= >=3D> >9 19:24:50 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] decla= >ring a=3D> > type's existance but not enough to instantiate it?> >> >> >Poi= >nt taken. We live in a C universe and so need to interact. I do think =3D> = >>your work with the headers is useful=3D2C and I want it to continue. Espec= >ia=3D> >lly in simplifying ports.> >> >> >On 12 Jan 2009=3D2C at 19:18=3D2C= > Jay wrote:> >> >I don't think a development system without C headers is in= >teresting.. Is it=3D> > really? The transform I apply at times is wherever = >there is interaction wi=3D> >th C code that is described by system-dependen= >t headers=3D2C or perhaps even =3D> >fairly system-independent headers outs= >ide the Modula-3 tree=3D2C either write=3D> > wrapper functions for the fun= >ctionality in the headers (e.g. stat=3D2C waitp=3D> >id)=3D2C which can be = >done in a system-independent way=3D2C or move the Modula-=3D> >3<->C transi= >tion higher=3D2C which is also usually system-independent=3D2C e.g.=3D> > T= >hreadPThreadC_SetupHandlers. It is either that or clone the headers=3D2C wh= >=3D> >ich seems like the worse evil. There is always going to be a Modula-3= ><->C t=3D> >ransition=3D2C it is just a matter of where it occurs. - Jay> >= >> >CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornel= >l.e=3D> >duSubject: Re: [M3devel] declaring a type's existance but not enou= >gh to ins=3D> >tantiate it?Date: Mon=3D2C 12 Jan 2009 12:32:15 +1100> >> >>= > >Jay=3D2C I really think you are bending over backwards too far just to be= > abl=3D> >e to shoe-horn things into C. I *like* having the transpar of C h= >eader fil=3D> >es expressed in Modula-3=3D2C *particularly* for system call= >s=3D2C where you mi=3D> >ght even be trying to build on a system that does = >not have the C header fil=3D> >es installed=3D2C even though the libraries = >exist and can be linked to. Fund=3D> >amentally=3D2C I think anytime the Mo= >dula-3 code is made less transparent you=3D> > should think hard about what= > you are doing. The same with the change of c=3D> >onstants to variables.> = >>> >I am getting very nervous that the changes you are making are destroyin= >g th=3D> >e clarity of the Modula-3 run-time code.> >> >In this particular = >case=3D2C you are wanting to use a Modula-3 parameter pass=3D> >ing mechani= >sm on something that is not declared in Modula-3. Seems kind of=3D> > dubio= >us to me. Also=3D2C I really don't like the idea of accessing external=3D> = >> variables in C.> >> >-- Tony> >> >On 12 Jan 2009=3D2C at 11:55=3D2C Jay w= >rote:> >> >I considered ADDRESS.However I think it still doesn't satisfy. I= > want to be=3D> > able to do this: TYPE Foo_t =3D3D something=3D3B<* EXTERN= >AL *> VAR Foo1=3D2C Foo=3D> >2:Foo_t=3D3B<* EXTERNAL *> PROCEDURE UseFoo(RE= >ADONLY (* or VAR *) foo:Foo_t)=3D> >=3D3B (* Modula-3=3D2C not external *)P= >ROCEDURE x()=3D3DBEGIN UseFoo(Foo1)=3D3B U=3D> >seFoo(Foo2)=3D3BEND x=3D3B = >AND I want any use of:VAR Foo3:Foo3_t=3D3B (* Modula-3=3D> >=3D2C not exter= >nal *)to error. This is sem_t and sigset_t in particular. Poss=3D> >ibly re= >naming is the thing.They used to be declared in Modula-3=3D2C system-d=3D> = >>ependently=3D2C butI moved them to portable C. I could remove the types en= >tir=3D> >ely and change UseFoo to take an address=3D2Cand declare mask and = >ackSem to b=3D> >e integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END= >=3D3B That would sat=3D> >isfy but I thought it might be nicer to still pro= >vide the namedtypes to ref=3D> >er to the external variables. - Jay> >> >Fr= >om: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon=3D2C 12 Jan 200= >=3D> >9 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] decla= >ring a=3D> > type's existance but not enough to instantiate it?What's wrong= > with using =3D> >ADDRESS for references to opaque values? If sigset_t is n= >ever instantiated=3D> > in Modula-3=3D2C then why do you need it declared t= >here?> >> >> >> >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 200= >9=3D2C at 01:44=3D2C Jay wrote:> >> >Is there a way in Modula-3 to declare = >that a type exists=3D2C and there are <=3D> >*external*> instances of it=3D= >2C without "fully" declaring it=3D2C so that no M=3D> >odula-3 can instanti= >ate it? I have done this for sigset_t and sem_t=3D2C but =3D> >they could e= >rroneously be instantiated by Modula-3 and I'd like to remove t=3D> >hat ab= >ility to mess up so easily. (* This type is not declared correctly. I=3D> >= >t is only instantiated in C code. *) sigset_t =3D3D RECORD END=3D3B(* This = >typ=3D> >e is not declared correctly. It is only instantiated in C code. *)= > sem_t =3D> >=3D3D RECORD END=3D3BIn C I believe you can do this=3D2C like:= > typedef struct fo=3D> >o foo_t=3D3B extern foo_t foo=3D3B void UseFoo(foo_= >t*)=3D3B foo_t* GetFoo=3D> >(void)=3D3B Thanks=3D2C - Jay=3D> >> >--_6117a0= >48-9185-4c03-badb-ef8f93402268_> >Content-Type: text/html=3B charset=3D"iso= >-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >= >> >> ><= >/head>> >> >This is what you "have to" chose be= >tween.
> >Header cloning or C code (and C headers).
> > =3D3B
= >> >CONST or VAR (or functions?)
> > =3D3B
> >I'm going to likely = >make the Uerror change tonight.
> >You can still veto it (er=3D2C vote a= >gainst it :) )
> > =3D3B
> >Possibly some convuluted C (enum/#und= >ef)=3D2C or splitting the Modula-3
> >at boundaries that weren't previou= >sly believed "natural".
> >(See how SetupHandlers is ~two lines in Modul= >a-3 and the rest in C=3D3B
> >this is partly out of ignorance. I don't k= >now how to write those
> >two lines in C=3D3B and laziness=3D2C I didn't= > look into how).
> > =3D3B
> > =3D3B
> > =3D3B
> >R= >emember I'm still staying away from mainstream platforms=3D2C
> >so the = >value isn't what it might appear to be=3D2C but it is "stage setting"=3D> >= >=3D2C
> >and the show might go on. :)
> > =3D3B
> > =3D3B<= >BR>> >Also=3D2C the dilemna does get more difficult now=3D2C with the littl= >e C header=3D> > cloning that remains.
> > =3D3B
> >For example= >=3D2C look at Upthreads.i3.
> >Mainly=3D2C look at function prototypes.<= >BR>> >Constants and types are "known problems".
> >Prototypes are gray. = >They actually tend to be portable.
> > =3D3B
> >For example:
>= > > =3D3B
> >TYPE pid_t =3D3D INTEGER=3D3B
> ><=3D3B*EXTERNAL "m= >3_getpid*>=3D3B PROCEDURE getpid():pid_t=3D3B
> > =3D3B
> >or l= >eave it alone?
> >getpid is probably the worst example.
> >It is so v= >ery portable declared in Modula-3.
> >But still=3D2C imagine pid_t might= > be 16bits or 32 or 64.
> >Writing a wrapper is more portable -- as long= > as the pid isn't stuff into s=3D> >ome record that the system defines.
= >> > =3D3B
> > =3D3B
> >Again=3D2C Upthreads.i3.
> >Would y= >ou like to see it reduced=3D2C or left alone?
> >Only deal with the type= >s and initializers=3D2C or also the prototypes?
> >You know=3D2C I could= > write a little portable layer=3D2C where all the types ar=3D> >e pointers= >=3D2C always null initialized.
> >It would buy /some/ portability=3D2C a= >nd cost some.
> > =3D3B
> > =3D3B
> >Do you like the sem_t= > change? Partly? Not at all?
> >There is one sem_t in the system. So I m= >oved it to be in C code.
> >Or=3D2C as I had it before=3D2C declared as = >the max size/align of all the platf=3D> >orms -- getting that right is the = >same work as getting it right "the old wa=3D> >y"=3D2C except if you make a= > mistake=3D2C odds are still good of it being ok. >R>> > =3D3B>> > =3D3B
> >Should the line be drawn at generating the remaining h= >eaders=3D2C rather than=3D> > eliminating them?
> >Uerror.i3 is easily g= >enerated. Good enough?
> > =3D3B
> >Upthread.i3's types can be ge= >nerated generally as records with opaque array=3D> >s with the right size a= >nd alignment.
> > =3D3B
> >Other stuff can be generated or at lea= >st checked.
> >e.g. to check that getpid is declared correctly=3D2C you = >can assign it to a f=3D> >unction pointer and see if that compiles.
> >&= >nbsp=3D3B
> >Perf on Uerror arguably doesn't matter.
> >Is it only er= >ror handling code?
Or do sockets often go down "error" path=3D> >s=3D2C = >because they are slow and you are waiting for more data?
> > =3D3BR>> >Anyway=3D2C point is=3D2C I agree for sure this is valuable=3D2C but I= > might be h=3D> >itting the "tail" of the approach and should switch=3D2C I= >'m not sure. I keep=3D> > saying that though=3D2C and then press further.R>> > =3D3B
> > =3D3B
> > =3D3B- Jay

> >> >
=3D3DstopSpelling>>
> >From: hosking at cs.purdue.edu
To: jay.krell at cor= >nell.edu
Date: Mon=3D2C 12=3D> > Jan 2009 19:24:50 +1100
CC: m3devel@= >elegosoft.com
Subject: Re: [M3de=3D> >vel] declaring a type's existance = >but not enough to instantiate it?

=3D> >
> >
EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: =3D> >12px Helv= >etica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-IN= >D=3D> >ENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B B= >ORDER-COLLAPS=3D> >E: separate">> >
<= >SPAN class=3D3DEC_Apple-style-span styl=3D> >e=3D3D"WORD-SPACING: 0px=3D3B = >FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B C=3D> >OLOR: rgb(0=3D2C= >0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-S=3D> >= >PACING: normal=3D3B BORDER-COLLAPSE: separate">le-s=3D> >pan style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B T= >EXT-TRANSFORM: n=3D> >one=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: = >0px=3D3B WHITE-SPACE: normal=3D3B =3D> >LETTER-SPACING: normal=3D3B BORDER-= >COLLAPSE: separate"> >-style-span style=3D3D"WO= >RD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRAN=3D> >SFORM: none= >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: no= >=3D> >rmal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate">N class=3D3D=3D> >EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FON= >T: 12px Helvetica=3D3B T=3D> >EXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0= >=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-S=3D> >PACE: normal=3D3B LETTER-SP= >ACING: normal=3D3B BORDER-COLLAPSE: separate"> >class=3D3DEC_Appl= >e-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvet=3D> >ica= >=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT:= > 0px=3D3B=3D> > WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER= >-COLLAPSE: separate=3D> >">ORD-SPACING: 0px=3D3B FONT: 12p=3D> >x Helvetica=3D3B TEXT-TRANSFORM: none= >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT=3D> >: 0px=3D3B WHITE-SPAC= >E: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: =3D> >separate"= >>> >ONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D= >2C0)=3D3B TEX=3D> >T-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACI= >NG: normal=3D3B BORDER-CO=3D> >LLAPSE: separate">tyle-span style=3D3D"WORD-SPACING: =3D> >0px=3D3B FONT: 12px Helvetica=3D3B= > TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0=3D> >)=3D3B TEXT-INDENT= >: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B B=3D> >ORDE= >R-COLLAPSE: separate">> >
Point taken.  =3D3BWe live in a C univers= >e and so need to interact. =3D> > =3D3BI do think your work with the he= >aders is useful=3D2C and I want it to=3D> > continue.  =3D3BEspecially = >in simplifying ports.
> >

SPAN> >V>
> >
> >
On 12 Ja= >n 2009=3D2C at 19:18=3D2C Jay wrote:

>e= >rchange-newline>> >
3D"WORD-SPACING: 0px=3D3B=3D> > FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: n= >one=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B T=3D> >EXT-INDENT: 0px=3D3B WHITE-S= >PACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-=3D> >COLLAPSE: separa= >te">> >
ILY: Verdana"=3D> >>I don't think a development system without C headers is= > interesting.. Is i=3D> >t really?
 =3D3B
The transform I apply a= >t times is wherever there i=3D> >s interaction with C code that is describe= >d by system-dependent headers=3D2C =3D> >or perhaps even fairly system-inde= >pendent headers outside the Modula-3 tree=3D> >=3D2C either write wrapper f= >unctions for the functionality in the headers (e.=3D> >g. stat=3D2C waitpid= >)=3D2C which =3D3Bcan be done in a system-independent way=3D> >=3D2C&nb= >sp=3D3Bor move the Modula-3<=3D3B->=3D3BC transition higher=3D2C which = >is=3D> > also usually system-independent=3D2C e.g. ThreadPThreadC_SetupHand= >lers.
&=3D> >nbsp=3D3B
It is either that or clone the headers=3D2C wh= >ich seems like the w=3D> >orse evil.
 =3D3B
There is always going= > to be a Modula-3<=3D3B->=3D> >=3D3BC transition=3D2C it is just a matt= >er of where it occurs.
 =3D3B
&=3D> >nbsp=3D3B- Jay

> > id=3D3DEC_stopSpelling>> >
CC:= > =3D3B >lto:m3devel at elegosoft.com">m3devel at e= >legosoft.com
From: >EC_Apple-converted-space>&nb= >sp=3D3B >.edu">hosking at cs.p= >urdue.edu
To: >e> =3D= >3Bjay.krell at cornell=3D> >= >.edu
Subject: Re: [M3devel] declaring a type's existance but not eno= >=3D> >ugh to instantiate it?
Date: Mon=3D2C 12 Jan 2009 12:32:15 +1100R>
>R>>
RD-SPACING: 0px=3D3B FON=3D> >T: 12px Helvetica=3D3B TEXT-TRANSFORM: none= >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-=3D> >INDENT: 0px=3D3B WHITE-SPAC= >E: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLL=3D> >APSE: separate"= >>> >
e-span s=3D> >tyle=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TE= >XT-TRANSFORM: none=3D> >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0= >px=3D3B WHITE-SPACE: normal=3D3B LET=3D> >TER-SPACING: normal=3D3B BORDER-C= >OLLAPSE: separate"> >-style-span style=3D3D"= >WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRAN=3D> >SFORM: none= >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: no= >=3D> >rmal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate">N class=3D3D=3D> >EC_EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B = >FONT: 12px Helvetica=3D> >=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C= >0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WH=3D> >ITE-SPACE: normal=3D3B LETTER-S= >PACING: normal=3D3B BORDER-COLLAPSE: separate"><=3D> >SPAN class=3D3DEC_EC_= >Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12p=3D> >x Helveti= >ca=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDEN= >T=3D> >: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORD= >ER-COLLAPSE: =3D> >separate">=3D3D"WORD-SPACING: 0px=3D> >=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM= >: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D> >=3D3B TEXT-INDENT: 0px=3D3B WHIT= >E-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BO=3D> >RDER-COLLAPSE: sep= >arate"> >-SPACING= >: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb= >=3D> >(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B L= >ETTER-SPACING: n=3D> >ormal=3D3B BORDER-COLLAPSE: separate">DEC_EC_Apple-style-span st=3D> >yle=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px = >Helvetica=3D3B TEXT-TRANSFORM: none=3D3B=3D> > COLOR: rgb(0=3D2C0=3D2C0)=3D= >3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER=3D> >-SPACING: nor= >mal=3D3B BORDER-COLLAPSE: separate"> >yle= >-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRAN= >SFO=3D> >RM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B= > WHITE-SPACE: norma=3D> >l=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE= >: separate">> >
Jay=3D2C I really think you are bending over backwards = >too far just to b=3D> >e able to shoe-horn things into C.  =3D3BI *like= >* having the transpar of =3D> >C header files expressed in Modula-3=3D2C *p= >articularly* for system calls=3D2C =3D> >where you might even be trying to = >build on a system that does not have the =3D> >C header files installed=3D2= >C even though the libraries exist and can be link=3D> >ed to.  =3D3BFun= >damentally=3D2C I think anytime the Modula-3 code is made l=3D> >ess transp= >arent you should think hard about what you are doing.  =3D3BThe=3D> > s= >ame with the change of constants to variables.
> >

> >IV>I am getting very nervous that the changes you are making are destroyi= >=3D> >ng the clarity of the Modula-3 run-time code.
> >

= >> >
In this particular case=3D2C you are wanting to use a Modula-3 para= >meter=3D> > passing mechanism on something that is not declared in Modula-3= >.  =3D3BS=3D> >eems kind of dubious to me.  =3D3BAlso=3D2C I really= > don't like the idea of=3D> > accessing external variables in C.
> >IV>
> >
-- Tony
><=3D> >/DIV>

> >
> >
On 12 Jan 2009= >=3D2C at 11:55=3D2C Jay wrote:

>interch= >ange-newline>> >
3D"WORD-SPACING: 0px=3D> >=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: n= >one=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D> >=3D3B TEXT-INDENT: 0px=3D3B WHITE-S= >PACE: normal=3D3B LETTER-SPACING: normal=3D3B BO=3D> >RDER-COLLAPSE: separa= >te">> >
FAMILY: Verda=3D> >na">I considered ADDRESS.
However I think it still do= >esn't satisfy.
&=3D> >nbsp=3D3B
I want to be able to do this:
&nbs= >p=3D3B
TYPE =3D3BFoo_t =3D> >=3D3D something=3D3B
<=3D3B* EXTER= >NAL *>=3D3B VAR Foo1=3D2C Foo2:Foo_t=3D3B
&=3D> >lt=3D3B* EXTERNAL *&g= >t=3D3B PROCEDURE =3D3BUseFoo(READONLY (* or VAR *) foo:F=3D> >oo_t)=3D3= >B
 =3D3B
(* Modula-3=3D2C not external *)
PROCEDURE x()=3D3D<= >=3D> >BR>BEGIN
 =3D3B UseFoo(Foo1)=3D3B
 =3D3B UseFoo(Foo2)= >=3D3B
END x=3D> >=3D3B
 =3D3B
AND I want any use of:
VAR Fo= >o3:Foo3_t=3D3B (* Modula-3=3D> >=3D2C not external *)

to error. This= > is sem_t and sigset_t in particul=3D> >ar.
 =3D3B
Possibly renam= >ing is the thing.
They used to be decla=3D> >red in Modula-3=3D2C system= >-dependently=3D2C but
I moved them to portable C.=3D> >
 =3D3B>I could remove the types entirely and change UseFoo to take=3D> > an addre= >ss=3D2C
and declare mask and ackSem to be integers or I guess. >>= ><=3D3B*EXTERNAL>=3D3B VAR ackSem =3D3B: RECORD END=3D3B
 =3D= >3B
Tha=3D> >t would satisfy but I thought it might be nicer to still pro= >vide the named<=3D> >BR>types to refer to the external variables.
 = >=3D3B
 =3D3B- Jay >R>
> >
> ><= >BR>From: =3D3Bf=3D> >=3D3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu
To:= > >ss=3D3DEC_EC_Apple-converted-space> =3D3B=3D3D"mailto:jay.krell=3D> >@cornell.edu">jay.krell at cornell.edu
Date= >: Mon=3D2C 12 Jan 2009 11:13:0=3D> >0 +1100
CC:le-converted-space> =3D3B >ref=3D3D"mailto:m3devel at elego= >soft.com">m3devel at elegosoft.com
Subject: =3D> >Re: [M3devel] declari= >ng a type's existance but not enough to instantiate it=3D> >?

What's= > wrong with using ADDRESS for references to opaque values? &=3D> >nbsp=3D3B= >If sigset_t is never instantiated in Modula-3=3D2C then why do you nee=3D> = >>d it declared there?
> >

> >
-style-span style=3D3D"WORD-SPACING: 0px=3D3B =3D> >FONT: 12px Helvetica=3D= >3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TE=3D> >XT-INDE= >NT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-C= >=3D> >OLLAPSE: separate">> >
ass=3D3DEC_EC_EC_Apple-style-spa=3D> >n style=3D3D"WORD-SPACING: 0px=3D3B F= >ONT: 12px Helvetica=3D3B TEXT-TRANSFORM: non=3D> >e=3D3B COLOR: rgb(0=3D2C0= >=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LE=3D> >TTER-SP= >ACING: normal=3D3B BORDER-COLLAPSE: separate">> >pple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica= >=3D3B TEXT-=3D> >TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-I= >NDENT: 0px=3D3B WHITE-SPACE=3D> >: normal=3D3B LETTER-SPACING: normal=3D3B = >BORDER-COLLAPSE: separate"> >s=3D3DEC_EC_EC_Apple-style-span = >style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helv=3D> >etica=3D3B TEXT-TRAN= >SFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D> >=3D3B= > WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: sepa= >r=3D> >ate">NG: 0px=3D3B =3D> >FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLO= >R: rgb(0=3D2C0=3D2C0)=3D3B TE=3D> >XT-INDENT: 0px=3D3B WHITE-SPACE: normal= >=3D3B LETTER-SPACING: normal=3D3B BORDER-C=3D> >OLLAPSE: separate">ass=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SP=3D> >ACING: 0px=3D3B F= >ONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D> >=3D2C0= >=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING:= > nor=3D> >mal=3D3B BORDER-COLLAPSE: separate">e-style-span s=3D> >tyle=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica= >=3D3B TEXT-TRANSFORM: none=3D> >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-I= >NDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LET=3D> >TER-SPACING: normal=3D3B = >BORDER-COLLAPSE: separate"> >ple-style-span = >style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-T=3D> >RAN= >SFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE= >-SPACE:=3D> > normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: sepa= >rate"> >=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SPACI= >NG: 0px=3D3B FONT: 12px Helve=3D> >tica=3D3B TEXT-TRANSFORM: none=3D3B COLO= >R: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D> >=3D3B WHITE-SPACE: normal= >=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separ=3D> >ate">> >
= >D=3D> >EC_EC_EC_Apple-style-span face=3D3D"Gill Sans">_EC_Apple-s=3D> >tyle-span style=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=3D3B FONT= >-FAMILY: 'Gill Sans'"> >AN class=3D3DEC_EC_EC_Apple-style-span style= >=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=3D3B FO=3D> >NT-FAMILY: 'Gill Sans'">Anto= >ny Hosking >ss=3D3DEC_EC_EC_Apple-= >style-span face=3D3D"Gill Sans"> >ple-style-= >span style=3D3D"FONT-FAMILY: 'Gill Sans'"> >= >ple-style-span style=3D3D"FONT-FAMILY: 'Gill Sans'">pple=3D> >-converted-space> =3D3B|nverted-space>=3D> > =3D3B_Apple-style-span style=3D> >=3D3D"FONT-FAMILY: 'Gill Sans'">3DEC_EC_EC_Apple-style-span style=3D> >=3D3D"FONT-FAMILY: 'Gill Sans'">Asso= >ciate Professor >=3D3DEC_EC_EC_Apple-style-spa= >n style=3D3D"FONT-FAMILY: 'Gill Sans'"> >=3D3DEC_EC_EC_Apple= >-style-span style=3D3D"FONT-FAMILY: 'Gill Sans'"> =3D3B| C=3D> >omputer= > Science | Purdue University
> >
=3D3DEC_EC_EC_Apple-style-span face=3D3DGillSans-Light> >ass=3D= >3DEC_EC_EC_Apple-style-span style=3D3D"FONT-FAMILY: GillSans-Light">305 N= >=3D> >. University Street | West Lafayette | IN 47907 | USADIV>> >
color=3D3D#00=3D> >00ff>D"COLOR: rgb(0=3D2C0=3D2C25=3D> >5)=3D3B FONT-FAMILY: 'Gill Sans'">ass=3D3DEC_EC_EC_Apple-style-span sty=3D> >le=3D3D"COLOR: rgb(0=3D2C0=3D2C2= >55)=3D3B FONT-FAMILY: 'Gill Sans'">Office >PAN>lass=3D3DEC_EC_EC_Apple-style-span face=3D3DGillSans-Light> >PAN clas= >s=3D3DEC_EC_EC_Apple-style-span style=3D3D"FONT-FAMILY: GillSans-Light"=3D>= > >>ns-Lig=3D> >ht"> =3D3B+1 765 494 6001 |erted-space>&nbs=3D> >p=3D3BEC_EC_Apple-style-span fac=3D> >e=3D3D"Gill Sans" color=3D3D#0000ff>lass=3D3DEC_EC_EC_Apple-style-span sty=3D> >le=3D3D"COLOR: rgb(0=3D2C0=3D2C= >255)=3D3B FONT-FAMILY: 'Gill Sans'"> >_EC_EC_Apple-st= >yle-span style=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=3D3B FONT-FAMILY: 'G=3D> >i= >ll Sans'">Mobilep=3D> >an face=3D3DGillSans-Light> style=3D3D"F=3D> >ONT-FAMILY: GillSans-Light">le-style-span style=3D> >=3D3D"FONT-FAMILY: GillSans-Light">DEC_EC_Apple-converted-space>=3D> > =3D3B+1 765 427 5484<= >/SPAN>
> >
=3D3DGillSans-Light>
>s=3D3DEC_EC_EC_khtml-block-placeholder>FONT>
>AN>
=3D3DEC_EC_EC_Apple-interchange-newline> >AN>
>> >
> >
On 12 Jan 2009=3D2C at 01:44=3D2C Jay wrote:

s=3D3DEC_EC_EC_App=3D> >le-interchange-newline>> >
=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SPACING: =3D> >0px=3D3B FONT= >: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0=3D= >> >)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: no= >rmal=3D3B B=3D> >ORDER-COLLAPSE: separate">> >
sage style=3D3D"FONT-SIZE: 10pt=3D3B FONT-FAMILY: Ve=3D> >rdana">Is there a= > way in Modula-3 to declare that =3D3Ba type exists=3D2C a=3D> >nd ther= >e are <=3D3B*external*>=3D3B instances of it=3D2C without "fully" decl= >=3D> >aring it=3D2C so that no Modula-3 can instantiate it?
 =3D3BR>I have d=3D> >one this for sigset_t and sem_t=3D2C but they could erroneo= >usly be instantiat=3D> >ed by Modula-3 and I'd like to remove that ability = >to mess up so easily. >> =3D3B
(* This type is not declared c= >orrectly. It is only instantiate=3D> >d in C code. *)
 =3D3B sigset_= >t =3D3D RECORD END=3D3B

(* This type =3D> >is not declared correctly= >. It is only instantiated in C code. *)
 =3D> >=3D3B sem_t =3D3D REC= >ORD END=3D3B

In C I believe you can do this=3D2C like:<=3D> >BR>&nbs= >p=3D3B =3D3Btypedef struct foo foo_t=3D3B =3D3BC_E=3D> >C_Apple-converted-space> =3D3B
 =3D3B =3D3Be= >xtern foo_t foo=3D> >=3D3B =3D3Bd-space> =3D3B
=3D> > =3D3B
 =3D3Bvoid UseFoo(foo_= >t*)=3D3B >erted-space> =3D3BAN>
 =3D3B foo_t* GetFoo(void)=3D3B >=3D3DEC_EC_EC_Ap= >ple-converted-space> =3D3B
 =3D3B
Thanks=3D2C<=3D> >BR= >> =3D3B- Jay




<= >=3D> >/DIV>
E>
=3D> >

<= >/BLOCKQUOTE> >V>
> >=3D> >> >--_6117a048-9185-4c03= >-badb-ef8f93402268_--= > >--_2e194b09-14b6-4301-9116-a9e4d1e522b4_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Yes=2C generating the headers is viable.
>I thought I mentioned that a few times.
They could be generated in any build "that can".
 =3B i.e. a native = >build=2C that has a working C development system
 =3B and checked ag= >ainst the checked in ones.
> =3BSo then porting is:
 =3B copy the generator to new system= >=2C run it=2C copy results back=2C proceed
>
 =3BMaybe a good compromise.
 =3BNot good for "embedded sys= >tems"=2C but heck=2C is there any such thing
 =3B any longer? Doesn'= >t everything have megs of RAM and gigs of persistant storage? :)
>
You don't need =3BScheme.
>Just Quake =3B+ compiling and running C code.
>Assuming a native build system.
>I've done stuff in cross build systems like:
>typedef struct foo_t {int i=3B int j=3B } foo_t=3B
>extern const int xi =3D offsetof(foo_t=2C i)=3B
> =3B
>compile that=2C and read the value of xi out of the .obj file.
> =3B
> =3BThe .obj file reader was written in Perl. :)
> =3B (Python not available.)
> =3Bbut to do that here=2C I'd have to support multiple .obj file forma= >ts.
> =3B
> =3B- Jay

>=3B To: jay.krell at cornell.edu
>=3B Date: Mon= >=2C 12 Jan 2009 01:34:24 -0800
>=3B From: mika at async.caltech.edu
&g= >t=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] declaring a= > type's existance but not enough to instantiate it?
>=3B
>=3B R>>=3B You present it as a true tragic Dilemma.
>=3B
>=3B But = >isn't there a Third Way---to wit=2C can't you "Ask the Computer"
>=3B = >to do the work for you?
>=3B
>=3B Generate the code somehow... P= >arsing the C headers is an obvious
>=3B way but there may be others th= >at are simpler=2C such as writing a
>=3B Modula-3 program to generate = >the cloned M3 headers=2C sorry=2C interfaces.
>=3B
>=3B If I had= > to do this I would use my Scheme interpreter that's coded
>=3B in Mod= >ula-3 to write a Scheme program to generate the headers. This
>=3B pro= >gram could pull whatever tricks are deemed necessary and suitable=2C
>= >=3B down to the point of generating and compiling and running C programs>>=3B as necessary (or parsing C code=2C or reading tea leaves). But the<= >BR>>=3B end result would be a set of interfaces written in "Pure Modula-3= >".
>=3B The process of running the header generator would also have ve= >ry
>=3B few dependencies on anything outside the M3 distribution.
&= >gt=3B
>=3B Mika
>=3B
>=3B Jay writes:
>=3B >=3B--_6= >117a048-9185-4c03-badb-ef8f93402268_
>=3B >=3BContent-Type: text/pla= >in=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Encoding: quo= >ted-printable
>=3B >=3B
>=3B >=3B
>=3B >=3BThis is wha= >t you "have to" chose between.
>=3B >=3BHeader cloning or C code (an= >d C headers).
>=3B >=3B=3D20
>=3B >=3BCONST or VAR (or functi= >ons?)
>=3B >=3B=3D20
>=3B >=3BI'm going to likely make the Ue= >rror change tonight.
>=3B >=3BYou can still veto it (er=3D2C vote ag= >ainst it :) )
>=3B >=3B=3D20
>=3B >=3BPossibly some convulute= >d C (enum/#undef)=3D2C or splitting the Modula-3
>=3B >=3Bat boundar= >ies that weren't previously believed "natural".
>=3B >=3B(See how Se= >tupHandlers is ~two lines in Modula-3 and the rest in C=3D3B
>=3B >= >=3Bthis is partly out of ignorance. I don't know how to write those
>= >=3B >=3Btwo lines in C=3D3B and laziness=3D2C I didn't look into how).>>=3B >=3B=3D20
>=3B >=3B=3D20
>=3B >=3B=3D20
>=3B &= >gt=3BRemember I'm still staying away from mainstream platforms=3D2C
>= >=3B >=3Bso the value isn't what it might appear to be=3D2C but it is "sta= >ge setting"=3D
>=3B >=3B=3D2C
>=3B >=3Band the show might go = >on. :)
>=3B >=3B=3D20
>=3B >=3B=3D20
>=3B >=3BAlso=3D2= >C the dilemna does get more difficult now=3D2C with the little C header=3D<= >BR>>=3B >=3B cloning that remains.
>=3B >=3B=3D20
>=3B >= >=3BFor example=3D2C look at Upthreads.i3.
>=3B >=3BMainly=3D2C look = >at function prototypes.
>=3B >=3BConstants and types are "known prob= >lems".
>=3B >=3BPrototypes are gray. They actually tend to be portab= >le.
>=3B >=3B=3D20
>=3B >=3BFor example:
>=3B >=3B=3D2= >0
>=3B >=3BTYPE pid_t =3D3D INTEGER=3D3B
>=3B >=3B<=3B*EXTE= >RNAL "m3_getpid*>=3B PROCEDURE getpid():pid_t=3D3B
>=3B >=3B=3D20<= >BR>>=3B >=3Bor leave it alone?
>=3B >=3Bgetpid is probably the w= >orst example.
>=3B >=3BIt is so very portable declared in Modula-3.<= >BR>>=3B >=3BBut still=3D2C imagine pid_t might be 16bits or 32 or 64.R>>=3B >=3BWriting a wrapper is more portable -- as long as the pid isn= >'t stuff into s=3D
>=3B >=3Bome record that the system defines.
&= >gt=3B >=3B=3D20
>=3B >=3B=3D20
>=3B >=3BAgain=3D2C Upthread= >s.i3.
>=3B >=3BWould you like to see it reduced=3D2C or left alone?<= >BR>>=3B >=3BOnly deal with the types and initializers=3D2C or also the = >prototypes?
>=3B >=3BYou know=3D2C I could write a little portable l= >ayer=3D2C where all the types ar=3D
>=3B >=3Be pointers=3D2C always = >null initialized.
>=3B >=3BIt would buy /some/ portability=3D2C and = >cost some.
>=3B >=3B=3D20
>=3B >=3B=3D20
>=3B >=3BDo y= >ou like the sem_t change? Partly? Not at all?
>=3B >=3BThere is one = >sem_t in the system. So I moved it to be in C code.
>=3B >=3BOr=3D2C= > as I had it before=3D2C declared as the max size/align of all the platf=3D= >
>=3B >=3Borms -- getting that right is the same work as getting it = >right "the old wa=3D
>=3B >=3By"=3D2C except if you make a mistake= >=3D2C odds are still good of it being ok.
>=3B >=3B=3D20
>=3B &= >gt=3B=3D20
>=3B >=3BShould the line be drawn at generating the remai= >ning headers=3D2C rather than=3D
>=3B >=3B eliminating them?
>= >=3B >=3BUerror.i3 is easily generated. Good enough?
>=3B >=3B=3D20= >
>=3B >=3BUpthread.i3's types can be generated generally as records = >with opaque array=3D
>=3B >=3Bs with the right size and alignment.R>>=3B >=3B=3D20
>=3B >=3BOther stuff can be generated or at lea= >st checked.
>=3B >=3Be.g. to check that getpid is declared correctly= >=3D2C you can assign it to a f=3D
>=3B >=3Bunction pointer and see i= >f that compiles.
>=3B >=3B=3D20
>=3B >=3BPerf on Uerror argua= >bly doesn't matter.
>=3B >=3BIs it only error handling code?Or do so= >ckets often go down "error" paths=3D2C=3D
>=3B >=3B because they are= > slow and you are waiting for more data?
>=3B >=3B=3D20
>=3B &g= >t=3BAnyway=3D2C point is=3D2C I agree for sure this is valuable=3D2C but I = >might be h=3D
>=3B >=3Bitting the "tail" of the approach and should = >switch=3D2C I'm not sure. I keep=3D
>=3B >=3B saying that though=3D2= >C and then press further.
>=3B >=3B=3D20
>=3B >=3B=3D20
&g= >t=3B >=3B - Jay
>=3B >=3B
>=3B >=3B
>=3B >=3B
>= >=3B >=3BFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon=3D2= >C 12 Jan 200=3D
>=3B >=3B9 19:24:50 +1100CC: m3devel at elegosoft.comSu= >bject: Re: [M3devel] declaring a=3D
>=3B >=3B type's existance but n= >ot enough to instantiate it?
>=3B >=3B
>=3B >=3B
>=3B &g= >t=3BPoint taken. We live in a C universe and so need to interact. I do thin= >k =3D
>=3B >=3Byour work with the headers is useful=3D2C and I want = >it to continue. Especia=3D
>=3B >=3Blly in simplifying ports.
>= >=3B >=3B
>=3B >=3B
>=3B >=3BOn 12 Jan 2009=3D2C at 19:18=3D= >2C Jay wrote:
>=3B >=3B
>=3B >=3BI don't think a development = >system without C headers is interesting.. Is it=3D
>=3B >=3B really?= > The transform I apply at times is wherever there is interaction wi=3D
&= >gt=3B >=3Bth C code that is described by system-dependent headers=3D2C or= > perhaps even =3D
>=3B >=3Bfairly system-independent headers outside= > the Modula-3 tree=3D2C either write=3D
>=3B >=3B wrapper functions = >for the functionality in the headers (e.g. stat=3D2C waitp=3D
>=3B >= >=3Bid)=3D2C which can be done in a system-independent way=3D2C or move the = >Modula-=3D
>=3B >=3B3<=3B->=3BC transition higher=3D2C which is = >also usually system-independent=3D2C e.g.=3D
>=3B >=3B ThreadPThread= >C_SetupHandlers. It is either that or clone the headers=3D2C wh=3D
>= >=3B >=3Bich seems like the worse evil. There is always going to be a Modu= >la-3<=3B->=3BC t=3D
>=3B >=3Bransition=3D2C it is just a matter = >of where it occurs. - Jay
>=3B >=3B
>=3B >=3BCC: m3devel at eleg= >osoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.e=3D
>=3B &g= >t=3BduSubject: Re: [M3devel] declaring a type's existance but not enough to= > ins=3D
>=3B >=3Btantiate it?Date: Mon=3D2C 12 Jan 2009 12:32:15 +11= >00
>=3B >=3B
>=3B >=3B
>=3B >=3BJay=3D2C I really thin= >k you are bending over backwards too far just to be abl=3D
>=3B >=3B= >e to shoe-horn things into C. I *like* having the transpar of C header fil= >=3D
>=3B >=3Bes expressed in Modula-3=3D2C *particularly* for system= > calls=3D2C where you mi=3D
>=3B >=3Bght even be trying to build on = >a system that does not have the C header fil=3D
>=3B >=3Bes installe= >d=3D2C even though the libraries exist and can be linked to. Fund=3D
>= >=3B >=3Bamentally=3D2C I think anytime the Modula-3 code is made less tra= >nsparent you=3D
>=3B >=3B should think hard about what you are doing= >. The same with the change of c=3D
>=3B >=3Bonstants to variables.R>>=3B >=3B
>=3B >=3BI am getting very nervous that the changes = >you are making are destroying th=3D
>=3B >=3Be clarity of the Modula= >-3 run-time code.
>=3B >=3B
>=3B >=3BIn this particular case= >=3D2C you are wanting to use a Modula-3 parameter pass=3D
>=3B >=3Bi= >ng mechanism on something that is not declared in Modula-3. Seems kind of= >=3D
>=3B >=3B dubious to me. Also=3D2C I really don't like the idea = >of accessing external=3D
>=3B >=3B variables in C.
>=3B >=3B<= >BR>>=3B >=3B-- Tony
>=3B >=3B
>=3B >=3BOn 12 Jan 2009=3D2= >C at 11:55=3D2C Jay wrote:
>=3B >=3B
>=3B >=3BI considered AD= >DRESS.However I think it still doesn't satisfy. I want to be=3D
>=3B &= >gt=3B able to do this: TYPE Foo_t =3D3D something=3D3B<=3B* EXTERNAL *>= >=3B VAR Foo1=3D2C Foo=3D
>=3B >=3B2:Foo_t=3D3B<=3B* EXTERNAL *>= >=3B PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t)=3D
>=3B >=3B= >=3D3B (* Modula-3=3D2C not external *)PROCEDURE x()=3D3DBEGIN UseFoo(Foo1)= >=3D3B U=3D
>=3B >=3BseFoo(Foo2)=3D3BEND x=3D3B AND I want any use of= >:VAR Foo3:Foo3_t=3D3B (* Modula-3=3D
>=3B >=3B=3D2C not external *)t= >o error. This is sem_t and sigset_t in particular. Poss=3D
>=3B >=3B= >ibly renaming is the thing.They used to be declared in Modula-3=3D2C system= >-d=3D
>=3B >=3Bependently=3D2C butI moved them to portable C. I coul= >d remove the types entir=3D
>=3B >=3Bely and change UseFoo to take a= >n address=3D2Cand declare mask and ackSem to b=3D
>=3B >=3Be integer= >s or I guess.<=3B*EXTERNAL>=3B VAR ackSem : RECORD END=3D3B That would = >sat=3D
>=3B >=3Bisfy but I thought it might be nicer to still provid= >e the namedtypes to ref=3D
>=3B >=3Ber to the external variables. - = >Jay
>=3B >=3B
>=3B >=3BFrom: hosking at cs.purdue.eduTo: jay.kre= >ll at cornell.eduDate: Mon=3D2C 12 Jan 200=3D
>=3B >=3B9 11:13:00 +1100= >CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a=3D
>=3B &g= >t=3B type's existance but not enough to instantiate it?What's wrong with us= >ing =3D
>=3B >=3BADDRESS for references to opaque values? If sigset_= >t is never instantiated=3D
>=3B >=3B in Modula-3=3D2C then why do yo= >u need it declared there?
>=3B >=3B
>=3B >=3B
>=3B >= >=3B
>=3B >=3BAntony Hosking | Associate Professor | Computer Science= > | Purdue University
>=3B >=3B305 N. University Street | West Lafaye= >tte | IN 47907 | USA
>=3B >=3BOffice +1 765 494 6001 | Mobile +1 765= > 427 5484
>=3B >=3B
>=3B >=3B
>=3B >=3BOn 12 Jan 2009= >=3D2C at 01:44=3D2C Jay wrote:
>=3B >=3B
>=3B >=3BIs there a = >way in Modula-3 to declare that a type exists=3D2C and there are <=3B=3D<= >BR>>=3B >=3B*external*>=3B instances of it=3D2C without "fully" decla= >ring it=3D2C so that no M=3D
>=3B >=3Bodula-3 can instantiate it? I = >have done this for sigset_t and sem_t=3D2C but =3D
>=3B >=3Bthey cou= >ld erroneously be instantiated by Modula-3 and I'd like to remove t=3D
&= >gt=3B >=3Bhat ability to mess up so easily. (* This type is not declared = >correctly. I=3D
>=3B >=3Bt is only instantiated in C code. *) sigset= >_t =3D3D RECORD END=3D3B(* This typ=3D
>=3B >=3Be is not declared co= >rrectly. It is only instantiated in C code. *) sem_t =3D
>=3B >=3B= >=3D3D RECORD END=3D3BIn C I believe you can do this=3D2C like: typedef stru= >ct fo=3D
>=3B >=3Bo foo_t=3D3B extern foo_t foo=3D3B void UseFoo(foo= >_t*)=3D3B foo_t* GetFoo=3D
>=3B >=3B(void)=3D3B Thanks=3D2C - Jay=3D= >
>=3B >=3B
>=3B >=3B--_6117a048-9185-4c03-badb-ef8f93402268_<= >BR>>=3B >=3BContent-Type: text/html=3B charset=3D"iso-8859-1"
>=3B= > >=3BContent-Transfer-Encoding: quoted-printable
>=3B >=3B
>= >=3B >=3B<=3Bhtml>=3B
>=3B >=3B<=3Bhead>=3B
>=3B >= >=3B<=3Bstyle>=3B
>=3B >=3B.hmmessage P
>=3B >=3B{
>= >=3B >=3Bmargin:0px=3D3B
>=3B >=3Bpadding:0px
>=3B >=3B}
= >>=3B >=3Bbody.hmmessage
>=3B >=3B{
>=3B >=3Bfont-size: 10= >pt=3D3B
>=3B >=3Bfont-family:Verdana
>=3B >=3B}
>=3B >= >=3B<=3B/style>=3B
>=3B >=3B<=3B/head>=3B
>=3B >=3B<= >=3Bbody class=3D3D'hmmessage'>=3B
>=3B >=3BThis is what you "have = >to" chose between.<=3BBR>=3B
>=3B >=3BHeader cloning or C code (= >and C headers).<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>= >=3B
>=3B >=3BCONST or VAR (or functions?)<=3BBR>=3B
>=3B &g= >t=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BI'm going to likely make= > the Uerror change tonight.<=3BBR>=3B
>=3B >=3BYou can still vet= >o it (er=3D2C vote against it :) )<=3BBR>=3B
>=3B >=3B&=3Bnbs= >p=3D3B<=3BBR>=3B
>=3B >=3BPossibly some convuluted C (enum/#unde= >f)=3D2C or splitting the Modula-3<=3BBR>=3B
>=3B >=3Bat boundari= >es that weren't previously believed "natural".<=3BBR>=3B
>=3B >= >=3B(See how SetupHandlers is ~two lines in Modula-3 and the rest in C=3D3B&= >lt=3BBR>=3B
>=3B >=3Bthis is partly out of ignorance. I don't know= > how to write those<=3BBR>=3B
>=3B >=3Btwo lines in C=3D3B and l= >aziness=3D2C I didn't look into how).<=3BBR>=3B
>=3B >=3B&=3B= >nbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
&= >gt=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BRemember I'm sti= >ll staying away from mainstream platforms=3D2C<=3BBR>=3B
>=3B >= >=3Bso the value isn't what it might appear to be=3D2C but it is "stage sett= >ing"=3D
>=3B >=3B=3D2C<=3BBR>=3B
>=3B >=3Band the show mi= >ght go on. :)<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B<= >BR>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BAlso=3D2C th= >e dilemna does get more difficult now=3D2C with the little C header=3D
&= >gt=3B >=3B cloning that remains.<=3BBR>=3B
>=3B >=3B&=3Bnbs= >p=3D3B<=3BBR>=3B
>=3B >=3BFor example=3D2C look at Upthreads.i3.= ><=3BBR>=3B
>=3B >=3BMainly=3D2C look at function prototypes.<= >=3BBR>=3B
>=3B >=3BConstants and types are "known problems".<=3B= >BR>=3B
>=3B >=3BPrototypes are gray. They actually tend to be port= >able.<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>= >=3B >=3BFor example:<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3B= >BR>=3B
>=3B >=3BTYPE pid_t =3D3D INTEGER=3D3B<=3BBR>=3B
>= >=3B >=3B&=3Blt=3D3B*EXTERNAL "m3_getpid*&=3Bgt=3D3B PROCEDURE getpi= >d():pid_t=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B= >
>=3B >=3Bor leave it alone?<=3BBR>=3B
>=3B >=3Bgetpid is= > probably the worst example.<=3BBR>=3B
>=3B >=3BIt is so very po= >rtable declared in Modula-3.<=3BBR>=3B
>=3B >=3BBut still=3D2C i= >magine pid_t might be 16bits or 32 or 64.<=3BBR>=3B
>=3B >=3BWri= >ting a wrapper is more portable -- as long as the pid isn't stuff into s=3D= >
>=3B >=3Bome record that the system defines.<=3BBR>=3B
>= >=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B&l= >t=3BBR>=3B
>=3B >=3BAgain=3D2C Upthreads.i3.<=3BBR>=3B
>= >=3B >=3BWould you like to see it reduced=3D2C or left alone?<=3BBR>= >=3B
>=3B >=3BOnly deal with the types and initializers=3D2C or also = >the prototypes?<=3BBR>=3B
>=3B >=3BYou know=3D2C I could write a= > little portable layer=3D2C where all the types ar=3D
>=3B >=3Be poi= >nters=3D2C always null initialized.<=3BBR>=3B
>=3B >=3BIt would = >buy /some/ portability=3D2C and cost some.<=3BBR>=3B
>=3B >=3B&a= >mp=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B= >
>=3B >=3BDo you like the sem_t change? Partly? Not at all?<=3BBR&= >gt=3B
>=3B >=3BThere is one sem_t in the system. So I moved it to be= > in C code.<=3BBR>=3B
>=3B >=3BOr=3D2C as I had it before=3D2C d= >eclared as the max size/align of all the platf=3D
>=3B >=3Borms -- g= >etting that right is the same work as getting it right "the old wa=3D
&g= >t=3B >=3By"=3D2C except if you make a mistake=3D2C odds are still good of= > it being ok.<=3BB=3D
>=3B >=3BR>=3B
>=3B >=3B&=3Bnbsp= >=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>= >=3B >=3BShould the line be drawn at generating the remaining headers=3D2C= > rather than=3D
>=3B >=3B eliminating them?<=3BBR>=3B
>=3B = >>=3BUerror.i3 is easily generated. Good enough?<=3BBR>=3B
>=3B &= >gt=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BUpthread.i3's types can= > be generated generally as records with opaque array=3D
>=3B >=3Bs w= >ith the right size and alignment.<=3BBR>=3B
>=3B >=3B&=3Bnbsp= >=3D3B<=3BBR>=3B
>=3B >=3BOther stuff can be generated or at leas= >t checked.<=3BBR>=3B
>=3B >=3Be.g. to check that getpid is decla= >red correctly=3D2C you can assign it to a f=3D
>=3B >=3Bunction poin= >ter and see if that compiles.<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3= >B<=3BBR>=3B
>=3B >=3BPerf on Uerror arguably doesn't matter.<= >=3BBR>=3B
>=3B >=3BIs it only error handling code?<=3BBR>=3BOr= > do sockets often go down "error" path=3D
>=3B >=3Bs=3D2C because th= >ey are slow and you are waiting for more data?<=3BBR>=3B
>=3B >= >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BAnyway=3D2C point is=3D2C= > I agree for sure this is valuable=3D2C but I might be h=3D
>=3B >= >=3Bitting the "tail" of the approach and should switch=3D2C I'm not sure. I= > keep=3D
>=3B >=3B saying that though=3D2C and then press further.&l= >t=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >= >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B- Jay<= >=3BBR>=3B<=3BBR>=3B
>=3B >=3B
>=3B >=3B<=3BHR id=3D3D= >stopSpelling>=3B
>=3B <=3BBR>=3B
>=3B >=3BFrom: hosking at c= >s.purdue.edu<=3BBR>=3BTo: jay.krell at cornell.edu<=3BBR>=3BDate: Mon= >=3D2C 12=3D
>=3B >=3B Jan 2009 19:24:50 +1100<=3BBR>=3BCC: m3dev= >el at elegosoft.com<=3BBR>=3BSubject: Re: [M3de=3D
>=3B >=3Bvel] de= >claring a type's existance but not enough to instantiate it?<=3BBR>=3B&= >lt=3BBR>=3B=3D
>=3B >=3B<=3BBR>=3B
>=3B >=3B<=3BDIV&g= >t=3B<=3BSPAN class=3D3DEC_Apple-style-span style=3D3D"WORD-SPACING: 0px= >=3D3B FONT: =3D
>=3B >=3B12px Helvetica=3D3B TEXT-TRANSFORM: none=3D= >3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-IND=3D
>=3B >=3BENT: 0px=3D3B= > WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPS=3D
= >>=3B >=3BE: separate">=3B
>=3B >=3B<=3BDIV style=3D3D"WORD-W= RAP: break-word">=3B<=3BSPAN class=3D3DEC_Apple-style-span styl=3D
&= >gt=3B >=3Be=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TR= >ANSFORM: none=3D3B C=3D
>=3B >=3BOLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-= >INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-S=3D
>=3B >=3BPACIN= >G: normal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=3D3DEC_Appl= >e-style-s=3D
>=3B >=3Bpan style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12= >px Helvetica=3D3B TEXT-TRANSFORM: n=3D
>=3B >=3Bone=3D3B COLOR: rgb(= >0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B =3D
&= >gt=3B >=3BLETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate">=3B<= >=3BSPAN class=3D3DEC_Apple=3D
>=3B >=3B-style-span style=3D3D"WORD-S= >PACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRAN=3D
>=3B >=3BSFO= >RM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SP= >ACE: no=3D
>=3B >=3Brmal=3D3B LETTER-SPACING: normal=3D3B BORDER-COL= >LAPSE: separate">=3B<=3BSPAN class=3D3D=3D
>=3B >=3BEC_Apple-sty= >le-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B T=3D>>=3B >=3BEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-= >INDENT: 0px=3D3B WHITE-S=3D
>=3B >=3BPACE: normal=3D3B LETTER-SPACIN= >G: normal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN =3D
>=3B >= >=3Bclass=3D3DEC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12= >px Helvet=3D
>=3B >=3Bica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(= >0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B=3D
>=3B >=3B WHITE-SPACE: = >normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate=3D
>= >=3B >=3B">=3B<=3BSPAN class=3D3DEC_Apple-style-span style=3D3D"WORD-S= >PACING: 0px=3D3B FONT: 12p=3D
>=3B >=3Bx Helvetica=3D3B TEXT-TRANSFO= >RM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT=3D
>=3B >= >=3B: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-C= >OLLAPSE: =3D
>=3B >=3Bseparate">=3B<=3BSPAN class=3D3DEC_Apple-s= >tyle-span style=3D3D"WORD-SPACING: 0px=3D3B F=3D
>=3B >=3BONT: 12px = >Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEX= >=3D
>=3B >=3BT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPAC= >ING: normal=3D3B BORDER-CO=3D
>=3B >=3BLLAPSE: separate">=3B<=3B= >SPAN class=3D3DEC_Apple-style-span style=3D3D"WORD-SPACING: =3D
>=3B &= >gt=3B0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rg= >b(0=3D2C0=3D2C0=3D
>=3B >=3B)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE= >: normal=3D3B LETTER-SPACING: normal=3D3B B=3D
>=3B >=3BORDER-COLLAP= >SE: separate">=3B
>=3B >=3B<=3BDIV>=3BPoint taken. &=3Bnbsp= >=3D3BWe live in a C universe and so need to interact. =3D
>=3B >=3B&= >amp=3Bnbsp=3D3BI do think your work with the headers is useful=3D2C and I w= >ant it to=3D
>=3B >=3B continue. &=3Bnbsp=3D3BEspecially in simpl= >ifying ports.<=3B/DIV>=3B
>=3B >=3B<=3BDIV>=3B<=3BBR>=3B= ><=3B/DIV>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/S= >PAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>= >=3B<=3B/DI=3D
>=3B >=3BV>=3B<=3B/SPAN>=3B<=3B/DIV>=3B>>=3B >=3B<=3BDIV>=3B
>=3B >=3B<=3BDIV>=3BOn 12 Jan 2009= >=3D2C at 19:18=3D2C Jay wrote:<=3B/DIV>=3B<=3BBR class=3D3DEC_Apple-i= >nt=3D
>=3B >=3Berchange-newline>=3B
>=3B >=3B<=3BBLOCKQUO= >TE>=3B<=3BSPAN class=3D3DEC_Apple-style-span style=3D3D"WORD-SPACING: 0= >px=3D3B=3D
>=3B >=3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none= >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B T=3D
>=3B >=3BEXT-INDENT: 0px= >=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-=3D
&g= >t=3B >=3BCOLLAPSE: separate">=3B
>=3B >=3B<=3BDIV class=3D3DEC= >_hmmessage style=3D3D"FONT-SIZE: 10pt=3D3B FONT-FAMILY: Verdana"=3D
>= >=3B >=3B>=3BI don't think a development system without C headers is int= >eresting.. Is i=3D
>=3B >=3Bt really?<=3BBR>=3B&=3Bnbsp=3D3B&= >lt=3BBR>=3BThe transform I apply at times is wherever there i=3D
>= >=3B >=3Bs interaction with C code that is described by system-dependent h= >eaders=3D2C =3D
>=3B >=3Bor perhaps even fairly system-independent h= >eaders outside the Modula-3 tree=3D
>=3B >=3B=3D2C either write wrap= >per functions for the functionality in the headers (e.=3D
>=3B >=3Bg= >. stat=3D2C waitpid)=3D2C which&=3Bnbsp=3D3Bcan be done in a system-inde= >pendent way=3D
>=3B >=3B=3D2C&=3Bnbsp=3D3Bor move the Modula-3&am= >p=3Blt=3D3B-&=3Bgt=3D3BC transition higher=3D2C which is=3D
>=3B &g= >t=3B also usually system-independent=3D2C e.g. ThreadPThreadC_SetupHandlers= >.<=3BBR>=3B&=3B=3D
>=3B >=3Bnbsp=3D3B<=3BBR>=3BIt is eith= >er that or clone the headers=3D2C which seems like the w=3D
>=3B >= >=3Borse evil.<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3BThere is always go= >ing to be a Modula-3&=3Blt=3D3B-&=3Bgt=3D
>=3B >=3B=3D3BC tran= >sition=3D2C it is just a matter of where it occurs.<=3BBR>=3B&=3Bnbs= >p=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bnbsp=3D3B- Jay<=3BBR>=3B= ><=3BBR>=3B
>=3B >=3B<=3BHR id=3D3DEC_stopSpelling>=3B
>= >=3B >=3B<=3BBR>=3BCC:<=3BSPAN class=3D3DEC_Apple-converted-space>= >=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BA href=3D3D"mai=3D
>=3B >= >=3Blto:m3devel at elegosoft.com">=3Bm3devel at elegosoft.com<=3B/A>=3B<= >=3BBR>=3BFrom:<=3BSPAN class=3D3D=3D
>=3B >=3BEC_Apple-converted= >-space>=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BA href=3D3D"mailto:hoski= >ng at cs.purdue=3D
>=3B >=3B.edu">=3Bhosking at cs.purdue.edu<=3B/A>= >=3B<=3BBR>=3BTo:<=3BSPAN class=3D3DEC_Apple-converted-spac=3D
>= >=3B >=3Be>=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BA href=3D3D"mailto:= >jay.krell at cornell.edu">=3Bjay.krell at cornell=3D
>=3B >=3B.edu<=3B= >/A>=3B<=3BBR>=3BSubject: Re: [M3devel] declaring a type's existance b= >ut not eno=3D
>=3B >=3Bugh to instantiate it?<=3BBR>=3BDate: Mon= >=3D2C 12 Jan 2009 12:32:15 +1100<=3BBR>=3B<=3BBR>=3B<=3BB=3D
&= >gt=3B >=3BR>=3B
>=3B <=3BDIV>=3B<=3BSPAN class=3D3DEC_EC_App= >le-style-span style=3D3D"WORD-SPACING: 0px=3D3B FON=3D
>=3B >=3BT: 1= >2px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B= > TEXT-=3D
>=3B >=3BINDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-= >SPACING: normal=3D3B BORDER-COLL=3D
>=3B >=3BAPSE: separate">=3BR>>=3B >=3B<=3BDIV style=3D3D"WORD-WRAP: break-word">=3B<=3BSPAN = >class=3D3DEC_EC_Apple-style-span s=3D
>=3B >=3Btyle=3D3D"WORD-SPACIN= >G: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D
>=3B >= >=3B=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: = >normal=3D3B LET=3D
>=3B >=3BTER-SPACING: normal=3D3B BORDER-COLLAPSE= >: separate">=3B<=3BSPAN class=3D3DEC_EC_Apple=3D
>=3B >=3B-style= >-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRAN= >=3D
>=3B >=3BSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-IN= >DENT: 0px=3D3B WHITE-SPACE: no=3D
>=3B >=3Brmal=3D3B LETTER-SPACING:= > normal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=3D3D=3D
&g= >t=3B >=3BEC_EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 1= >2px Helvetica=3D
>=3B >=3B=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb= >(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WH=3D
>=3B >=3BITE-SPACE:= > normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate">=3B&l= >t=3B=3D
>=3B >=3BSPAN class=3D3DEC_EC_Apple-style-span style=3D3D"WO= >RD-SPACING: 0px=3D3B FONT: 12p=3D
>=3B >=3Bx Helvetica=3D3B TEXT-TRA= >NSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT=3D
>=3B &= >gt=3B: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER= >-COLLAPSE: =3D
>=3B >=3Bseparate">=3B<=3BSPAN class=3D3DEC_EC_Ap= >ple-style-span style=3D3D"WORD-SPACING: 0px=3D
>=3B >=3B=3D3B FONT: = >12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D<= >BR>>=3B >=3B=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER= >-SPACING: normal=3D3B BO=3D
>=3B >=3BRDER-COLLAPSE: separate">=3B&= >lt=3BSPAN class=3D3DEC_EC_Apple-style-span style=3D3D"WORD=3D
>=3B >= >=3B-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B C= >OLOR: rgb=3D
>=3B >=3B(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHI= >TE-SPACE: normal=3D3B LETTER-SPACING: n=3D
>=3B >=3Bormal=3D3B BORDE= >R-COLLAPSE: separate">=3B<=3BSPAN class=3D3DEC_EC_Apple-style-span st= >=3D
>=3B >=3Byle=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D= >3B TEXT-TRANSFORM: none=3D3B=3D
>=3B >=3B COLOR: rgb(0=3D2C0=3D2C0)= >=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER=3D
>=3B &g= >t=3B-SPACING: normal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class= >=3D3DEC_EC_Apple-st=3D
>=3B >=3Byle-span style=3D3D"WORD-SPACING: 0p= >x=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFO=3D
>=3B >=3BRM: none= >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: nor= >ma=3D
>=3B >=3Bl=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: s= >eparate">=3B
>=3B >=3B<=3BDIV>=3BJay=3D2C I really think you a= >re bending over backwards too far just to b=3D
>=3B >=3Be able to sh= >oe-horn things into C. &=3Bnbsp=3D3BI *like* having the transpar of =3D<= >BR>>=3B >=3BC header files expressed in Modula-3=3D2C *particularly* fo= >r system calls=3D2C =3D
>=3B >=3Bwhere you might even be trying to b= >uild on a system that does not have the =3D
>=3B >=3BC header files = >installed=3D2C even though the libraries exist and can be link=3D
>=3B= > >=3Bed to. &=3Bnbsp=3D3BFundamentally=3D2C I think anytime the Modula= >-3 code is made l=3D
>=3B >=3Bess transparent you should think hard = >about what you are doing. &=3Bnbsp=3D3BThe=3D
>=3B >=3B same with= > the change of constants to variables.<=3B/DIV>=3B
>=3B >=3B<= >=3BDIV>=3B<=3BBR>=3B<=3B/DIV>=3B
>=3B >=3B<=3BDIV>=3BI= > am getting very nervous that the changes you are making are destroyi=3D>>=3B >=3Bng the clarity of the Modula-3 run-time code.<=3B/DIV>=3B= >
>=3B >=3B<=3BDIV>=3B<=3BBR>=3B<=3B/DIV>=3B
>=3B &g= >t=3B<=3BDIV>=3BIn this particular case=3D2C you are wanting to use a Mo= >dula-3 parameter=3D
>=3B >=3B passing mechanism on something that is= > not declared in Modula-3. &=3Bnbsp=3D3BS=3D
>=3B >=3Beems kind o= >f dubious to me. &=3Bnbsp=3D3BAlso=3D2C I really don't like the idea of= >=3D
>=3B >=3B accessing external variables in C.<=3B/DIV>=3B
= >>=3B >=3B<=3BDIV>=3B<=3BBR>=3B<=3B/DIV>=3B
>=3B >=3B= ><=3BDIV>=3B-- Tony<=3B/DIV>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<= >=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPA= >N>=3B<=3B/SPAN>=3B<=3B=3D
>=3B >=3B/DIV>=3B<=3B/SPAN>= >=3B<=3B/DIV>=3B<=3BBR>=3B
>=3B >=3B<=3BDIV>=3B
>=3B= > >=3B<=3BDIV>=3BOn 12 Jan 2009=3D2C at 11:55=3D2C Jay wrote:<=3B/DI= >V>=3B<=3BBR class=3D3DEC_EC_Apple-=3D
>=3B >=3Binterchange-newli= >ne>=3B
>=3B >=3B<=3BBLOCKQUOTE>=3B<=3BSPAN class=3D3DEC_EC_A= >pple-style-span style=3D3D"WORD-SPACING: 0px=3D
>=3B >=3B=3D3B FONT:= > 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D= >
>=3B >=3B=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTE= >R-SPACING: normal=3D3B BO=3D
>=3B >=3BRDER-COLLAPSE: separate">=3B= >
>=3B >=3B<=3BDIV class=3D3DEC_EC_hmmessage style=3D3D"FONT-SIZE: = >10pt=3D3B FONT-FAMILY: Verda=3D
>=3B >=3Bna">=3BI considered ADDRE= >SS.<=3BBR>=3BHowever I think it still doesn't satisfy.<=3BBR>=3B&am= >p=3B=3D
>=3B >=3Bnbsp=3D3B<=3BBR>=3BI want to be able to do this= >:<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3BTYPE&=3Bnbsp=3D3BFoo_t =3D<= >BR>>=3B >=3B=3D3D something=3D3B<=3BBR>=3B&=3Blt=3D3B* EXTERNAL = >*&=3Bgt=3D3B VAR Foo1=3D2C Foo2:Foo_t=3D3B<=3BBR>=3B&=3B=3D
&g= >t=3B >=3Blt=3D3B* EXTERNAL *&=3Bgt=3D3B PROCEDURE&=3Bnbsp=3D3BUseFo= >o(READONLY (* or VAR *) foo:F=3D
>=3B >=3Boo_t)=3D3B<=3BBR>=3B&a= >mp=3Bnbsp=3D3B<=3BBR>=3B(* Modula-3=3D2C not external *)<=3BBR>=3BP= >ROCEDURE x()=3D3D<=3B=3D
>=3B >=3BBR>=3BBEGIN<=3BBR>=3B&= >=3Bnbsp=3D3B UseFoo(Foo1)=3D3B<=3BBR>=3B&=3Bnbsp=3D3B UseFoo(Foo2)= >=3D3B<=3BBR>=3BEND x=3D
>=3B >=3B=3D3B<=3BBR>=3B&=3Bnbsp= >=3D3B<=3BBR>=3BAND I want any use of:<=3BBR>=3BVAR Foo3:Foo3_t=3D3B= > (* Modula-3=3D
>=3B >=3B=3D2C not external *)<=3BBR>=3B<=3BBR= >>=3Bto error. This is sem_t and sigset_t in particul=3D
>=3B >=3Ba= >r.<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3BPossibly renaming is the thin= >g.<=3BBR>=3BThey used to be decla=3D
>=3B >=3Bred in Modula-3=3D= >2C system-dependently=3D2C but<=3BBR>=3BI moved them to portable C.=3D<= >BR>>=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3BI could remove = >the types entirely and change UseFoo to take=3D
>=3B >=3B an address= >=3D2C<=3BBR>=3Band declare mask and ackSem to be integers or I guess.&l= >t=3BBR=3D
>=3B >=3B>=3B&=3Blt=3D3B*EXTERNAL&=3Bgt=3D3B VAR a= >ckSem&=3Bnbsp=3D3B: RECORD END=3D3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BB= >R>=3BTha=3D
>=3B >=3Bt would satisfy but I thought it might be nic= >er to still provide the named<=3B=3D
>=3B >=3BBR>=3Btypes to ref= >er to the external variables.<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B&a= >mp=3Bnbsp=3D3B- Jay<=3BB=3D
>=3B >=3BR>=3B<=3BBR>=3B
>= >=3B >=3B<=3BHR id=3D3DEC_EC_stopSpelling>=3B
>=3B >=3B<=3BBR= >>=3BFrom:<=3BSPAN class=3D3DEC_EC_Apple-converted-space>=3B&=3Bnbs= >p=3D3B<=3B/SPAN>=3B<=3BA href=3D
>=3B >=3B=3D3D"mailto:hosking= >@cs.purdue.edu">=3Bhosking at cs.purdue.edu<=3B/A>=3B<=3BBR>=3BTo:&l= >t=3BSPAN cla=3D
>=3B >=3Bss=3D3DEC_EC_Apple-converted-space>=3B&am= >p=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BA href=3D3D"mailto:jay.krell=3D
>= >=3B >=3B at cornell.edu">=3Bjay.krell at cornell.edu<=3B/A>=3B<=3BBR>= >=3BDate: Mon=3D2C 12 Jan 2009 11:13:0=3D
>=3B >=3B0 +1100<=3BBR>= >=3BCC:<=3BSPAN class=3D3DEC_EC_Apple-converted-space>=3B&=3Bnbsp=3D3= >B<=3B/SPAN>=3B<=3BA h=3D
>=3B >=3Bref=3D3D"mailto:m3devel at eleg= >osoft.com">=3Bm3devel at elegosoft.com<=3B/A>=3B<=3BBR>=3BSubject: = >=3D
>=3B >=3BRe: [M3devel] declaring a type's existance but not enou= >gh to instantiate it=3D
>=3B >=3B?<=3BBR>=3B<=3BBR>=3BWhat's= > wrong with using ADDRESS for references to opaque values? &=3B=3D
&g= >t=3B >=3Bnbsp=3D3BIf sigset_t is never instantiated in Modula-3=3D2C then= > why do you nee=3D
>=3B >=3Bd it declared there?<=3BBR>=3B
&g= >t=3B >=3B<=3BDIV>=3B<=3BBR>=3B
>=3B >=3B<=3BDIV>=3B<= >=3BSPAN class=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D= >3B =3D
>=3B >=3BFONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B = >COLOR: rgb(0=3D2C0=3D2C0)=3D3B TE=3D
>=3B >=3BXT-INDENT: 0px=3D3B WH= >ITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-C=3D
>=3B &g= >t=3BOLLAPSE: separate">=3B
>=3B >=3B<=3BDIV style=3D3D"WORD-WRAP= >: break-word">=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-spa=3D
>= >=3B >=3Bn style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEX= >T-TRANSFORM: non=3D
>=3B >=3Be=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B T= >EXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LE=3D
>=3B >=3BTTER-SP= >ACING: normal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=3D3DEC_= >EC_EC_A=3D
>=3B >=3Bpple-style-span style=3D3D"WORD-SPACING: 0px=3D3= >B FONT: 12px Helvetica=3D3B TEXT-=3D
>=3B >=3BTRANSFORM: none=3D3B C= >OLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE=3D
>= >=3B >=3B: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separa= >te">=3B<=3BSPAN clas=3D
>=3B >=3Bs=3D3DEC_EC_EC_Apple-style-span= > style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helv=3D
>=3B >=3Betica= >=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT:= > 0px=3D
>=3B >=3B=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: norm= >al=3D3B BORDER-COLLAPSE: separ=3D
>=3B >=3Bate">=3B<=3BSPAN clas= >s=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B =3D
&g= >t=3B >=3BFONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0= >=3D2C0=3D2C0)=3D3B TE=3D
>=3B >=3BXT-INDENT: 0px=3D3B WHITE-SPACE: n= >ormal=3D3B LETTER-SPACING: normal=3D3B BORDER-C=3D
>=3B >=3BOLLAPSE:= > separate">=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-span style=3D3D"W= >ORD-SP=3D
>=3B >=3BACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TR= >ANSFORM: none=3D3B COLOR: rgb(0=3D
>=3B >=3B=3D2C0=3D2C0)=3D3B TEXT-= >INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: nor=3D
>=3B = >>=3Bmal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=3D3DEC_EC_E= >C_Apple-style-span s=3D
>=3B >=3Btyle=3D3D"WORD-SPACING: 0px=3D3B FO= >NT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D
>=3B >=3B=3D3B COLOR= >: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LE= >T=3D
>=3B >=3BTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate">= >=3B<=3BSPAN class=3D3DEC_EC_EC_Ap=3D
>=3B >=3Bple-style-span style= >=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-T=3D
>=3B = >>=3BRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px= >=3D3B WHITE-SPACE:=3D
>=3B >=3B normal=3D3B LETTER-SPACING: normal= >=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=3D
>=3B >=3B= >=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px= > Helve=3D
>=3B >=3Btica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0= >=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D
>=3B >=3B=3D3B WHITE-SPACE: n= >ormal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separ=3D
>=3B = >>=3Bate">=3B
>=3B >=3B<=3BDIV>=3B<=3BFONT class=3D3DEC_EC_= >EC_Apple-style-span color=3D3D#0000ff>=3B<=3BFONT class=3D3D=3D
>= >=3B >=3BEC_EC_EC_Apple-style-span face=3D3D"Gill Sans">=3B<=3BSPAN cl= >ass=3D3DEC_EC_EC_Apple-s=3D
>=3B >=3Btyle-span style=3D3D"COLOR: rgb= >(0=3D2C0=3D2C255)=3D3B FONT-FAMILY: 'Gill Sans'">=3B<=3BSP=3D
>=3B= > >=3BAN class=3D3DEC_EC_EC_Apple-style-span style=3D3D"COLOR: rgb(0=3D2C0= >=3D2C255)=3D3B FO=3D
>=3B >=3BNT-FAMILY: 'Gill Sans'">=3BAntony Ho= >sking<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/FONT>=3B<=3B/FONT>=3B&l= >t=3BFONT cla=3D
>=3B >=3Bss=3D3DEC_EC_EC_Apple-style-span face=3D3D"= >Gill Sans">=3B<=3BSPAN class=3D3DEC_EC_EC_Ap=3D
>=3B >=3Bple-sty= >le-span style=3D3D"FONT-FAMILY: 'Gill Sans'">=3B<=3BSPAN class=3D3DEC_E= >C_EC_Ap=3D
>=3B >=3Bple-style-span style=3D3D"FONT-FAMILY: 'Gill San= >s'">=3B<=3BSPAN class=3D3DEC_EC_Apple=3D
>=3B >=3B-converted-spa= >ce>=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B|<=3BSPAN class=3D3DEC_EC_Apple-= >converted-space>=3B=3D
>=3B >=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B&= >lt=3B/SPAN>=3B<=3B/SPAN>=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-= >span style=3D
>=3B >=3B=3D3D"FONT-FAMILY: 'Gill Sans'">=3B<=3BSP= >AN class=3D3DEC_EC_EC_Apple-style-span style=3D
>=3B >=3B=3D3D"FONT-= >FAMILY: 'Gill Sans'">=3BAssociate Professor<=3B/SPAN>=3B<=3B/SPAN&g= >t=3B<=3BSPAN class=3D
>=3B >=3B=3D3DEC_EC_EC_Apple-style-span styl= >e=3D3D"FONT-FAMILY: 'Gill Sans'">=3B<=3BSPAN class=3D
>=3B >=3B= >=3D3DEC_EC_EC_Apple-style-span style=3D3D"FONT-FAMILY: 'Gill Sans'">=3B&a= >mp=3Bnbsp=3D3B| C=3D
>=3B >=3Bomputer Science | Purdue University<= >=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/FONT>=3B<=3B/DIV>=3B
>=3B = >>=3B<=3BDIV>=3B<=3BFONT class=3D3DEC_EC_EC_Apple-style-span face=3D= >3DGillSans-Light>=3B<=3BSPAN cl=3D
>=3B >=3Bass=3D3DEC_EC_EC_App= >le-style-span style=3D3D"FONT-FAMILY: GillSans-Light">=3B305 N=3D
>= >=3B >=3B. University Street | West Lafayette | IN 47907 | USA<=3B/SPAN&= >gt=3B<=3B/FONT>=3B<=3B/DIV>=3B
>=3B >=3B<=3BDIV>=3B<= >=3BFONT class=3D3DEC_EC_EC_Apple-style-span face=3D3D"Gill Sans" color=3D3D= >#00=3D
>=3B >=3B00ff>=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-= >span style=3D3D"COLOR: rgb(0=3D2C0=3D2C25=3D
>=3B >=3B5)=3D3B FONT-F= >AMILY: 'Gill Sans'">=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-span sty= >=3D
>=3B >=3Ble=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=3D3B FONT-FAMILY: '= >Gill Sans'">=3BOffice<=3B/SPAN>=3B<=3B/S=3D
>=3B >=3BPAN>= >=3B<=3B/FONT>=3B<=3BFONT class=3D3DEC_EC_EC_Apple-style-span face=3D3= >DGillSans-Light>=3B<=3BS=3D
>=3B >=3BPAN class=3D3DEC_EC_EC_Appl= >e-style-span style=3D3D"FONT-FAMILY: GillSans-Light"=3D
>=3B >=3B>= >=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-span style=3D3D"FONT-FAMILY: G= >illSans-Lig=3D
>=3B >=3Bht">=3B&=3Bnbsp=3D3B+1 765 494 6001 |&l= >t=3BSPAN class=3D3DEC_EC_Apple-converted-space>=3B&=3Bnbs=3D
>=3B= > >=3Bp=3D3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/FONT= >>=3B<=3BFONT class=3D3DEC_EC_EC_Apple-style-span fac=3D
>=3B >= >=3Be=3D3D"Gill Sans" color=3D3D#0000ff>=3B<=3BSPAN class=3D3DEC_EC_EC_A= >pple-style-span sty=3D
>=3B >=3Ble=3D3D"COLOR: rgb(0=3D2C0=3D2C255)= >=3D3B FONT-FAMILY: 'Gill Sans'">=3B<=3BSPAN class=3D3DEC=3D
>=3B &= >gt=3B_EC_EC_Apple-style-span style=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=3D3B FO= >NT-FAMILY: 'G=3D
>=3B >=3Bill Sans'">=3BMobile<=3B/SPAN>=3B<= >=3B/SPAN>=3B<=3B/FONT>=3B<=3BFONT class=3D3DEC_EC_EC_Apple-style-sp= >=3D
>=3B >=3Ban face=3D3DGillSans-Light>=3B<=3BSPAN class=3D3DEC= >_EC_EC_Apple-style-span style=3D3D"F=3D
>=3B >=3BONT-FAMILY: GillSan= >s-Light">=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-span style=3D
&g= >t=3B >=3B=3D3D"FONT-FAMILY: GillSans-Light">=3B<=3BSPAN class=3D3DEC_= >EC_Apple-converted-space>=3B=3D
>=3B >=3B&=3Bnbsp=3D3B<=3B/SP= >AN>=3B+1 765 427 5484<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/FONT>=3B&= >lt=3B/DIV>=3B
>=3B >=3B<=3BDIV>=3B<=3BFONT class=3D3DEC_EC_E= >C_Apple-style-span face=3D3DGillSans-Light>=3B<=3BBR clas=3D
>=3B = >>=3Bs=3D3DEC_EC_EC_khtml-block-placeholder>=3B<=3B/FONT>=3B<=3B/D= >IV>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SP=3D
= >>=3B >=3BAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<= >=3BBR class=3D3DEC_EC_EC_Apple-interchange-newline>=3B<=3B/SP=3D
>= >=3B >=3BAN>=3B<=3B/DIV>=3B<=3B/SPAN>=3B<=3B/DIV>=3B<=3BBR= >>=3B
>=3B >=3B<=3BDIV>=3B
>=3B >=3B<=3BDIV>=3BOn 12= > Jan 2009=3D2C at 01:44=3D2C Jay wrote:<=3B/DIV>=3B<=3BBR class=3D3DE= >C_EC_EC_App=3D
>=3B >=3Ble-interchange-newline>=3B
>=3B >= >=3B<=3BBLOCKQUOTE>=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-span sty= >le=3D3D"WORD-SPACING: =3D
>=3B >=3B0px=3D3B FONT: 12px Helvetica=3D3= >B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0=3D
>=3B >=3B)= >=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal= >=3D3B B=3D
>=3B >=3BORDER-COLLAPSE: separate">=3B
>=3B >=3B= ><=3BDIV class=3D3DEC_EC_EC_hmmessage style=3D3D"FONT-SIZE: 10pt=3D3B FONT= >-FAMILY: Ve=3D
>=3B >=3Brdana">=3BIs there a way in Modula-3 to de= >clare that&=3Bnbsp=3D3Ba type exists=3D2C a=3D
>=3B >=3Bnd there = >are &=3Blt=3D3B*external*&=3Bgt=3D3B instances of it=3D2C without "fu= >lly" decl=3D
>=3B >=3Baring it=3D2C so that no Modula-3 can instanti= >ate it?<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3BI have d=3D
>=3B &g= >t=3Bone this for sigset_t and sem_t=3D2C but they could erroneously be inst= >antiat=3D
>=3B >=3Bed by Modula-3 and I'd like to remove that abilit= >y to mess up so easily.<=3BBR=3D
>=3B >=3B>=3B&=3Bnbsp=3D3B&l= >t=3BBR>=3B(* This type is not declared correctly. It is only instantiate= >=3D
>=3B >=3Bd in C code. *)<=3BBR>=3B&=3Bnbsp=3D3B sigset_t = >=3D3D RECORD END=3D3B<=3BBR>=3B<=3BBR>=3B(* This type =3D
>=3B= > >=3Bis not declared correctly. It is only instantiated in C code. *)<= >=3BBR>=3B&=3Bnbsp=3D
>=3B >=3B=3D3B sem_t =3D3D RECORD END=3D3B= ><=3BBR>=3B<=3BBR>=3BIn C I believe you can do this=3D2C like:<=3B= >=3D
>=3B >=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3Btypedef struct = >foo foo_t=3D3B&=3Bnbsp=3D3B<=3BSPAN class=3D3DEC_EC_E=3D
>=3B >= >=3BC_Apple-converted-space>=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BBR&g= >t=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3Bextern foo_t foo=3D
>=3B >=3B=3D= >3B&=3Bnbsp=3D3B<=3BSPAN class=3D3DEC_EC_EC_Apple-converted-space>=3B= >&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BBR>=3B=3D
>=3B >=3B&=3Bn= >bsp=3D3B<=3BBR>=3B&=3Bnbsp=3D3Bvoid UseFoo(foo_t*)=3D3B<=3BSPAN cl= >ass=3D3DEC_EC_EC_Apple-conv=3D
>=3B >=3Berted-space>=3B&=3Bnbsp= >=3D3B<=3B/SPAN>=3B<=3BBR>=3B&=3Bnbsp=3D3B foo_t* GetFoo(void)=3D= >3B<=3BSPAN class=3D
>=3B >=3B=3D3DEC_EC_EC_Apple-converted-space&g= >t=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR= >>=3BThanks=3D2C<=3B=3D
>=3B >=3BBR>=3B&=3Bnbsp=3D3B- Jay<= >=3BBR>=3B<=3BBR>=3B<=3BBR>=3B<=3BBR>=3B<=3B/DIV>=3B<=3B= >/SPAN>=3B<=3B/BLOCKQUOTE>=3B<=3B/DIV>=3B<=3BBR>=3B<=3B/DIV&= >gt=3B<=3B=3D
>=3B >=3B/DIV>=3B<=3B/SPAN>=3B<=3BBR class=3D= >3DEC_EC_Apple-interchange-newline>=3B<=3B/BLOCKQUOTE>=3B<=3B/DIV>= >=3B=3D
>=3B >=3B<=3BBR>=3B<=3B/DIV>=3B<=3B/SPAN>=3B<= >=3BBR class=3D3DEC_Apple-interchange-newline>=3B<=3B/BLOCKQUOTE>=3B&l= >t=3B/DI=3D
>=3B >=3BV>=3B<=3BBR>=3B<=3B/body>=3B
>=3B= > >=3B<=3B/html>=3B=3D
>=3B >=3B
>=3B >=3B--_6117a048-91= >85-4c03-badb-ef8f93402268_--

>= > >--_2e194b09-14b6-4301-9116-a9e4d1e522b4_-- From jay.krell at cornell.edu Mon Jan 12 11:24:37 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 10:24:37 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: <200901121013.n0CADQE0075969@camembert.async.caltech.edu> References: Your message of "Mon, 12 Jan 2009 09:56:43 GMT." <200901121013.n0CADQE0075969@camembert.async.caltech.edu> Message-ID: I don't at this time want to write C a parser. (Actually I do, as part of an entire compiler, but...) I'd rather run the one I already have -- the C compiler. I briefly in the past dreamt that C programmers might start writing "xml" (schema?!) or "idl". Oh, and you can't rely on headers being written in an easy to parse C subset. There are inlines, #pragmas, compiler-specific extensions, etc. Best just to use them as part of compiling C with the intended compiler. Well, I have parsed C subsets actually..more than once. One didn't really have to be very complete. One "lived" with the headers and there was flexibility to fix the headers to suit. - Jay> To: jay.krell at cornell.edu> Date: Mon, 12 Jan 2009 02:13:25 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?> > > I think you're misunderstanding me a bit. You don't need C either.> I would use a Lisp-based language for the "top level" just because> they are good at handling things like parse trees, if one gets to> that.> > The objectives are:> > * A finished system in Pure Modula-3 (no executable C)> > * Make it as self-contained as possible> > You'd start by simply bundling the existing headers with m3bundle> and printing them out. Then you'd find duplication (what you've> been doing) and express that programmatically. Then you might find> things that might conceivably change in the OS headers and use> whatever tricks were necessary to figure them out automatically.> Does this involve C? Maybe on some architecture it does, maybe on> another it doesn't. On some it might not involve running C but> merely parsing C headers. Perhaps the program is just hand-written> and just a way of distilling all the duplication into one place> where it can be clearly described and documented. Since this is a> Modula-3 distribution, obviously the program I'm talking about is> written in Modula-3, not in C or Perl or Python.> > Mika> > Jay writes:> >--_2e194b09-14b6-4301-9116-a9e4d1e522b4_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >Yes=2C generating the headers is viable.> >I thought I mentioned that a few times.> >They could be generated in any build "that can". i.e. a native build=2C th=> >at has a working C development system and checked against the checked in o=> >nes.> > So then porting is: copy the generator to new system=2C run it=2C copy r=> >esults back=2C proceed=20> > Maybe a good compromise. Not good for "embedded systems"=2C but heck=2C i=> >s there any such thing any longer? Doesn't everything have megs of RAM and=> > gigs of persistant storage? :)> >You don't need Scheme.> >Just Quake + compiling and running C code.> >Assuming a native build system.> >I've done stuff in cross build systems like:> >typedef struct foo_t {int i=3B int j=3B } foo_t=3B> >extern const int xi =3D offsetof(foo_t=2C i)=3B> >=20> >compile that=2C and read the value of xi out of the .obj file.> >=20> > The .obj file reader was written in Perl. :)=20> > (Python not available.)> > but to do that here=2C I'd have to support multiple .obj file formats.> >=20> > - Jay> To: jay.krell at cornell.edu> Date: Mon=2C 12 Jan 2009 01:34:24 -0800>=> > From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3d=> >evel] declaring a type's existance but not enough to instantiate it?> > > Y=> >ou present it as a true tragic Dilemma.> > But isn't there a Third Way---to=> > wit=2C can't you "Ask the Computer"> to do the work for you?> > Generate t=> >he code somehow... Parsing the C headers is an obvious> way but there may b=> >e others that are simpler=2C such as writing a> Modula-3 program to generat=> >e the cloned M3 headers=2C sorry=2C interfaces.> > If I had to do this I wo=> >uld use my Scheme interpreter that's coded> in Modula-3 to write a Scheme p=> >rogram to generate the headers. This> program could pull whatever tricks ar=> >e deemed necessary and suitable=2C> down to the point of generating and com=> >piling and running C programs> as necessary (or parsing C code=2C or readin=> >g tea leaves). But the> end result would be a set of interfaces written in => >"Pure Modula-3".> The process of running the header generator would also ha=> >ve very> few dependencies on anything outside the M3 distribution.> > Mika>=> > > Jay writes:> >--_6117a048-9185-4c03-badb-ef8f93402268_> >Content-Type: t=> >ext/plain=3B charset=3D"iso-8859-1"> >Content-Transfer-Encoding: quoted-pri=> >ntable> >> >> >This is what you "have to" chose between.> >Header cloning o=> >r C code (and C headers).> >=3D20> >CONST or VAR (or functions?)> >=3D20> >=> >I'm going to likely make the Uerror change tonight.> >You can still veto it=> > (er=3D2C vote against it :) )> >=3D20> >Possibly some convuluted C (enum/#=> >undef)=3D2C or splitting the Modula-3> >at boundaries that weren't previous=> >ly believed "natural".> >(See how SetupHandlers is ~two lines in Modula-3 a=> >nd the rest in C=3D3B> >this is partly out of ignorance. I don't know how t=> >o write those> >two lines in C=3D3B and laziness=3D2C I didn't look into ho=> >w).> >=3D20> >=3D20> >=3D20> >Remember I'm still staying away from mainstre=> >am platforms=3D2C> >so the value isn't what it might appear to be=3D2C but => >it is "stage setting"=3D> >=3D2C> >and the show might go on. :)> >=3D20> >=> >=3D20> >Also=3D2C the dilemna does get more difficult now=3D2C with the lit=> >tle C header=3D> > cloning that remains.> >=3D20> >For example=3D2C look at=> > Upthreads.i3.> >Mainly=3D2C look at function prototypes.> >Constants and t=> >ypes are "known problems".> >Prototypes are gray. They actually tend to be => >portable.> >=3D20> >For example:> >=3D20> >TYPE pid_t =3D3D INTEGER=3D3B> >=> ><*EXTERNAL "m3_getpid*> PROCEDURE getpid():pid_t=3D3B> >=3D20> >or leave it=> > alone?> >getpid is probably the worst example.> >It is so very portable de=> >clared in Modula-3.> >But still=3D2C imagine pid_t might be 16bits or 32 or=> > 64.> >Writing a wrapper is more portable -- as long as the pid isn't stuff=> > into s=3D> >ome record that the system defines.> >=3D20> >=3D20> >Again=3D=> >2C Upthreads.i3.> >Would you like to see it reduced=3D2C or left alone?> >O=> >nly deal with the types and initializers=3D2C or also the prototypes?> >You=> > know=3D2C I could write a little portable layer=3D2C where all the types a=> >r=3D> >e pointers=3D2C always null initialized.> >It would buy /some/ porta=> >bility=3D2C and cost some.> >=3D20> >=3D20> >Do you like the sem_t change? => >Partly? Not at all?> >There is one sem_t in the system. So I moved it to be=> > in C code.> >Or=3D2C as I had it before=3D2C declared as the max size/alig=> >n of all the platf=3D> >orms -- getting that right is the same work as gett=> >ing it right "the old wa=3D> >y"=3D2C except if you make a mistake=3D2C odd=> >s are still good of it being ok.> >=3D20> >=3D20> >Should the line be drawn=> > at generating the remaining headers=3D2C rather than=3D> > eliminating the=> >m?> >Uerror.i3 is easily generated. Good enough?> >=3D20> >Upthread.i3's ty=> >pes can be generated generally as records with opaque array=3D> >s with the=> > right size and alignment.> >=3D20> >Other stuff can be generated or at lea=> >st checked.> >e.g. to check that getpid is declared correctly=3D2C you can => >assign it to a f=3D> >unction pointer and see if that compiles.> >=3D20> >P=> >erf on Uerror arguably doesn't matter.> >Is it only error handling code?Or => >do sockets often go down "error" paths=3D2C=3D> > because they are slow and=> > you are waiting for more data?> >=3D20> >Anyway=3D2C point is=3D2C I agree=> > for sure this is valuable=3D2C but I might be h=3D> >itting the "tail" of => >the approach and should switch=3D2C I'm not sure. I keep=3D> > saying that => >though=3D2C and then press further.> >=3D20> >=3D20> > - Jay> >> >> >> >Fro=> >m: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon=3D2C 12 Jan 200=> >=3D> >9 19:24:50 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] decla=> >ring a=3D> > type's existance but not enough to instantiate it?> >> >> >Poi=> >nt taken. We live in a C universe and so need to interact. I do think =3D> => >>your work with the headers is useful=3D2C and I want it to continue. Espec=> >ia=3D> >lly in simplifying ports.> >> >> >On 12 Jan 2009=3D2C at 19:18=3D2C=> > Jay wrote:> >> >I don't think a development system without C headers is in=> >teresting.. Is it=3D> > really? The transform I apply at times is wherever => >there is interaction wi=3D> >th C code that is described by system-dependen=> >t headers=3D2C or perhaps even =3D> >fairly system-independent headers outs=> >ide the Modula-3 tree=3D2C either write=3D> > wrapper functions for the fun=> >ctionality in the headers (e.g. stat=3D2C waitp=3D> >id)=3D2C which can be => >done in a system-independent way=3D2C or move the Modula-=3D> >3<->C transi=> >tion higher=3D2C which is also usually system-independent=3D2C e.g.=3D> > T=> >hreadPThreadC_SetupHandlers. It is either that or clone the headers=3D2C wh=> >=3D> >ich seems like the worse evil. There is always going to be a Modula-3=> ><->C t=3D> >ransition=3D2C it is just a matter of where it occurs. - Jay> >=> >> >CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornel=> >l.e=3D> >duSubject: Re: [M3devel] declaring a type's existance but not enou=> >gh to ins=3D> >tantiate it?Date: Mon=3D2C 12 Jan 2009 12:32:15 +1100> >> >>=> > >Jay=3D2C I really think you are bending over backwards too far just to be=> > abl=3D> >e to shoe-horn things into C. I *like* having the transpar of C h=> >eader fil=3D> >es expressed in Modula-3=3D2C *particularly* for system call=> >s=3D2C where you mi=3D> >ght even be trying to build on a system that does => >not have the C header fil=3D> >es installed=3D2C even though the libraries => >exist and can be linked to. Fund=3D> >amentally=3D2C I think anytime the Mo=> >dula-3 code is made less transparent you=3D> > should think hard about what=> > you are doing. The same with the change of c=3D> >onstants to variables.> => >>> >I am getting very nervous that the changes you are making are destroyin=> >g th=3D> >e clarity of the Modula-3 run-time code.> >> >In this particular => >case=3D2C you are wanting to use a Modula-3 parameter pass=3D> >ing mechani=> >sm on something that is not declared in Modula-3. Seems kind of=3D> > dubio=> >us to me. Also=3D2C I really don't like the idea of accessing external=3D> => >> variables in C.> >> >-- Tony> >> >On 12 Jan 2009=3D2C at 11:55=3D2C Jay w=> >rote:> >> >I considered ADDRESS.However I think it still doesn't satisfy. I=> > want to be=3D> > able to do this: TYPE Foo_t =3D3D something=3D3B<* EXTERN=> >AL *> VAR Foo1=3D2C Foo=3D> >2:Foo_t=3D3B<* EXTERNAL *> PROCEDURE UseFoo(RE=> >ADONLY (* or VAR *) foo:Foo_t)=3D> >=3D3B (* Modula-3=3D2C not external *)P=> >ROCEDURE x()=3D3DBEGIN UseFoo(Foo1)=3D3B U=3D> >seFoo(Foo2)=3D3BEND x=3D3B => >AND I want any use of:VAR Foo3:Foo3_t=3D3B (* Modula-3=3D> >=3D2C not exter=> >nal *)to error. This is sem_t and sigset_t in particular. Poss=3D> >ibly re=> >naming is the thing.They used to be declared in Modula-3=3D2C system-d=3D> => >>ependently=3D2C butI moved them to portable C. I could remove the types en=> >tir=3D> >ely and change UseFoo to take an address=3D2Cand declare mask and => >ackSem to b=3D> >e integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END=> >=3D3B That would sat=3D> >isfy but I thought it might be nicer to still pro=> >vide the namedtypes to ref=3D> >er to the external variables. - Jay> >> >Fr=> >om: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon=3D2C 12 Jan 200=> >=3D> >9 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] decla=> >ring a=3D> > type's existance but not enough to instantiate it?What's wrong=> > with using =3D> >ADDRESS for references to opaque values? If sigset_t is n=> >ever instantiated=3D> > in Modula-3=3D2C then why do you need it declared t=> >here?> >> >> >> >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 200=> >9=3D2C at 01:44=3D2C Jay wrote:> >> >Is there a way in Modula-3 to declare => >that a type exists=3D2C and there are <=3D> >*external*> instances of it=3D=> >2C without "fully" declaring it=3D2C so that no M=3D> >odula-3 can instanti=> >ate it? I have done this for sigset_t and sem_t=3D2C but =3D> >they could e=> >rroneously be instantiated by Modula-3 and I'd like to remove t=3D> >hat ab=> >ility to mess up so easily. (* This type is not declared correctly. I=3D> >=> >t is only instantiated in C code. *) sigset_t =3D3D RECORD END=3D3B(* This => >typ=3D> >e is not declared correctly. It is only instantiated in C code. *)=> > sem_t =3D> >=3D3D RECORD END=3D3BIn C I believe you can do this=3D2C like:=> > typedef struct fo=3D> >o foo_t=3D3B extern foo_t foo=3D3B void UseFoo(foo_=> >t*)=3D3B foo_t* GetFoo=3D> >(void)=3D3B Thanks=3D2C - Jay=3D> >> >--_6117a0=> >48-9185-4c03-badb-ef8f93402268_> >Content-Type: text/html=3B charset=3D"iso=> >-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >=> >> >> ><=> >/head>> >> >This is what you "have to" chose be=> >tween.
> >Header cloning or C code (and C headers).
> > =3D3B
=> >> >CONST or VAR (or functions?)
> > =3D3B
> >I'm going to likely => >make the Uerror change tonight.
> >You can still veto it (er=3D2C vote a=> >gainst it :) )
> > =3D3B
> >Possibly some convuluted C (enum/#und=> >ef)=3D2C or splitting the Modula-3
> >at boundaries that weren't previou=> >sly believed "natural".
> >(See how SetupHandlers is ~two lines in Modul=> >a-3 and the rest in C=3D3B
> >this is partly out of ignorance. I don't k=> >now how to write those
> >two lines in C=3D3B and laziness=3D2C I didn't=> > look into how).
> > =3D3B
> > =3D3B
> > =3D3B
> >R=> >emember I'm still staying away from mainstream platforms=3D2C
> >so the => >value isn't what it might appear to be=3D2C but it is "stage setting"=3D> >=> >=3D2C
> >and the show might go on. :)
> > =3D3B
> > =3D3B<=> >BR>> >Also=3D2C the dilemna does get more difficult now=3D2C with the littl=> >e C header=3D> > cloning that remains.
> > =3D3B
> >For example=> >=3D2C look at Upthreads.i3.
> >Mainly=3D2C look at function prototypes.<=> >BR>> >Constants and types are "known problems".
> >Prototypes are gray. => >They actually tend to be portable.
> > =3D3B
> >For example:
>=> > > =3D3B
> >TYPE pid_t =3D3D INTEGER=3D3B
> ><=3D3B*EXTERNAL "m=> >3_getpid*>=3D3B PROCEDURE getpid():pid_t=3D3B
> > =3D3B
> >or l=> >eave it alone?
> >getpid is probably the worst example.
> >It is so v=> >ery portable declared in Modula-3.
> >But still=3D2C imagine pid_t might=> > be 16bits or 32 or 64.
> >Writing a wrapper is more portable -- as long=> > as the pid isn't stuff into s=3D> >ome record that the system defines.
=> >> > =3D3B
> > =3D3B
> >Again=3D2C Upthreads.i3.
> >Would y=> >ou like to see it reduced=3D2C or left alone?
> >Only deal with the type=> >s and initializers=3D2C or also the prototypes?
> >You know=3D2C I could=> > write a little portable layer=3D2C where all the types ar=3D> >e pointers=> >=3D2C always null initialized.
> >It would buy /some/ portability=3D2C a=> >nd cost some.
> > =3D3B
> > =3D3B
> >Do you like the sem_t=> > change? Partly? Not at all?
> >There is one sem_t in the system. So I m=> >oved it to be in C code.
> >Or=3D2C as I had it before=3D2C declared as => >the max size/align of all the platf=3D> >orms -- getting that right is the => >same work as getting it right "the old wa=3D> >y"=3D2C except if you make a=> > mistake=3D2C odds are still good of it being ok. >R>> > =3D3B >>> > =3D3B
> >Should the line be drawn at generating the remaining h=> >eaders=3D2C rather than=3D> > eliminating them?
> >Uerror.i3 is easily g=> >enerated. Good enough?
> > =3D3B
> >Upthread.i3's types can be ge=> >nerated generally as records with opaque array=3D> >s with the right size a=> >nd alignment.
> > =3D3B
> >Other stuff can be generated or at lea=> >st checked.
> >e.g. to check that getpid is declared correctly=3D2C you => >can assign it to a f=3D> >unction pointer and see if that compiles.
> >&=> >nbsp=3D3B
> >Perf on Uerror arguably doesn't matter.
> >Is it only er=> >ror handling code?
Or do sockets often go down "error" path=3D> >s=3D2C => >because they are slow and you are waiting for more data?
> > =3D3B >R>> >Anyway=3D2C point is=3D2C I agree for sure this is valuable=3D2C but I=> > might be h=3D> >itting the "tail" of the approach and should switch=3D2C I=> >'m not sure. I keep=3D> > saying that though=3D2C and then press further. >R>> > =3D3B
> > =3D3B
> > =3D3B- Jay

> >> >
>=3D3DstopSpelling>>
> >From: hosking at cs.purdue.edu
To: jay.krell at cor=> >nell.edu
Date: Mon=3D2C 12=3D> > Jan 2009 19:24:50 +1100
CC: m3devel@=> >elegosoft.com
Subject: Re: [M3de=3D> >vel] declaring a type's existance => >but not enough to instantiate it?

=3D> >
> >
>EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: =3D> >12px Helv=> >etica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-IN=> >D=3D> >ENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B B=> >ORDER-COLLAPS=3D> >E: separate">> >
<=> >SPAN class=3D3DEC_Apple-style-span styl=3D> >e=3D3D"WORD-SPACING: 0px=3D3B => >FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B C=3D> >OLOR: rgb(0=3D2C=> >0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-S=3D> >=> >PACING: normal=3D3B BORDER-COLLAPSE: separate"> >le-s=3D> >pan style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B T=> >EXT-TRANSFORM: n=3D> >one=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: => >0px=3D3B WHITE-SPACE: normal=3D3B =3D> >LETTER-SPACING: normal=3D3B BORDER-=> >COLLAPSE: separate"> >-style-span style=3D3D"WO=> >RD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRAN=3D> >SFORM: none=> >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: no=> >=3D> >rmal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate"> >N class=3D3D=3D> >EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FON=> >T: 12px Helvetica=3D3B T=3D> >EXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=> >=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-S=3D> >PACE: normal=3D3B LETTER-SP=> >ACING: normal=3D3B BORDER-COLLAPSE: separate"> >class=3D3DEC_Appl=> >e-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvet=3D> >ica=> >=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT:=> > 0px=3D3B=3D> > WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER=> >-COLLAPSE: separate=3D> >"> >ORD-SPACING: 0px=3D3B FONT: 12p=3D> >x Helvetica=3D3B TEXT-TRANSFORM: none=> >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT=3D> >: 0px=3D3B WHITE-SPAC=> >E: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: =3D> >separate"=> >> >> >ONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D=> >2C0)=3D3B TEX=3D> >T-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACI=> >NG: normal=3D3B BORDER-CO=3D> >LLAPSE: separate"> >tyle-span style=3D3D"WORD-SPACING: =3D> >0px=3D3B FONT: 12px Helvetica=3D3B=> > TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0=3D> >)=3D3B TEXT-INDENT=> >: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B B=3D> >ORDE=> >R-COLLAPSE: separate">> >
Point taken.  =3D3BWe live in a C univers=> >e and so need to interact. =3D> > =3D3BI do think your work with the he=> >aders is useful=3D2C and I want it to=3D> > continue.  =3D3BEspecially => >in simplifying ports.
> >

 >SPAN> >V>
> >
> >
On 12 Ja=> >n 2009=3D2C at 19:18=3D2C Jay wrote:

>e=> >rchange-newline>> >
>3D"WORD-SPACING: 0px=3D3B=3D> > FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: n=> >one=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B T=3D> >EXT-INDENT: 0px=3D3B WHITE-S=> >PACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-=3D> >COLLAPSE: separa=> >te">> >
>ILY: Verdana"=3D> >>I don't think a development system without C headers is=> > interesting.. Is i=3D> >t really?
 =3D3B
The transform I apply a=> >t times is wherever there i=3D> >s interaction with C code that is describe=> >d by system-dependent headers=3D2C =3D> >or perhaps even fairly system-inde=> >pendent headers outside the Modula-3 tree=3D> >=3D2C either write wrapper f=> >unctions for the functionality in the headers (e.=3D> >g. stat=3D2C waitpid=> >)=3D2C which =3D3Bcan be done in a system-independent way=3D> >=3D2C&nb=> >sp=3D3Bor move the Modula-3<=3D3B->=3D3BC transition higher=3D2C which => >is=3D> > also usually system-independent=3D2C e.g. ThreadPThreadC_SetupHand=> >lers.
&=3D> >nbsp=3D3B
It is either that or clone the headers=3D2C wh=> >ich seems like the w=3D> >orse evil.
 =3D3B
There is always going=> > to be a Modula-3<=3D3B->=3D> >=3D3BC transition=3D2C it is just a matt=> >er of where it occurs.
 =3D3B
&=3D> >nbsp=3D3B- Jay

> > > id=3D3DEC_stopSpelling>> >
CC:=> > =3D3B >lto:m3devel at elegosoft.com">m3devel at e=> >legosoft.com
From: >EC_Apple-converted-space>&nb=> >sp=3D3B >.edu">hosking at cs.p=> >urdue.edu
To: >e> =3D=> >3Bjay.krell at cornell=3D> >=> >.edu
Subject: Re: [M3devel] declaring a type's existance but not eno=> >=3D> >ugh to instantiate it?
Date: Mon=3D2C 12 Jan 2009 12:32:15 +1100 >R>
>R>>
>RD-SPACING: 0px=3D3B FON=3D> >T: 12px Helvetica=3D3B TEXT-TRANSFORM: none=> >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-=3D> >INDENT: 0px=3D3B WHITE-SPAC=> >E: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLL=3D> >APSE: separate"=> >>> >
>e-span s=3D> >tyle=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TE=> >XT-TRANSFORM: none=3D> >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0=> >px=3D3B WHITE-SPACE: normal=3D3B LET=3D> >TER-SPACING: normal=3D3B BORDER-C=> >OLLAPSE: separate"> >-style-span style=3D3D"=> >WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRAN=3D> >SFORM: none=> >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: no=> >=3D> >rmal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate"> >N class=3D3D=3D> >EC_EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B => >FONT: 12px Helvetica=3D> >=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C=> >0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WH=3D> >ITE-SPACE: normal=3D3B LETTER-S=> >PACING: normal=3D3B BORDER-COLLAPSE: separate"><=3D> >SPAN class=3D3DEC_EC_=> >Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12p=3D> >x Helveti=> >ca=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDEN=> >T=3D> >: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORD=> >ER-COLLAPSE: =3D> >separate"> >=3D3D"WORD-SPACING: 0px=3D> >=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM=> >: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D> >=3D3B TEXT-INDENT: 0px=3D3B WHIT=> >E-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BO=3D> >RDER-COLLAPSE: sep=> >arate"> >-SPACING=> >: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb=> >=3D> >(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B L=> >ETTER-SPACING: n=3D> >ormal=3D3B BORDER-COLLAPSE: separate"> >DEC_EC_Apple-style-span st=3D> >yle=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px => >Helvetica=3D3B TEXT-TRANSFORM: none=3D3B=3D> > COLOR: rgb(0=3D2C0=3D2C0)=3D=> >3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER=3D> >-SPACING: nor=> >mal=3D3B BORDER-COLLAPSE: separate"> >yle=> >-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRAN=> >SFO=3D> >RM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B=> > WHITE-SPACE: norma=3D> >l=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE=> >: separate">> >
Jay=3D2C I really think you are bending over backwards => >too far just to b=3D> >e able to shoe-horn things into C.  =3D3BI *like=> >* having the transpar of =3D> >C header files expressed in Modula-3=3D2C *p=> >articularly* for system calls=3D2C =3D> >where you might even be trying to => >build on a system that does not have the =3D> >C header files installed=3D2=> >C even though the libraries exist and can be link=3D> >ed to.  =3D3BFun=> >damentally=3D2C I think anytime the Modula-3 code is made l=3D> >ess transp=> >arent you should think hard about what you are doing.  =3D3BThe=3D> > s=> >ame with the change of constants to variables.
> >

> > >IV>I am getting very nervous that the changes you are making are destroyi=> >=3D> >ng the clarity of the Modula-3 run-time code.
> >

=> >> >
In this particular case=3D2C you are wanting to use a Modula-3 para=> >meter=3D> > passing mechanism on something that is not declared in Modula-3=> >.  =3D3BS=3D> >eems kind of dubious to me.  =3D3BAlso=3D2C I really=> > don't like the idea of=3D> > accessing external variables in C.
> > >IV>
> >
-- Tony
>><=3D> >/DIV>

> >
> >
On 12 Jan 2009=> >=3D2C at 11:55=3D2C Jay wrote:

>interch=> >ange-newline>> >
>3D"WORD-SPACING: 0px=3D> >=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: n=> >one=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D> >=3D3B TEXT-INDENT: 0px=3D3B WHITE-S=> >PACE: normal=3D3B LETTER-SPACING: normal=3D3B BO=3D> >RDER-COLLAPSE: separa=> >te">> >
>FAMILY: Verda=3D> >na">I considered ADDRESS.
However I think it still do=> >esn't satisfy.
&=3D> >nbsp=3D3B
I want to be able to do this:
&nbs=> >p=3D3B
TYPE =3D3BFoo_t =3D> >=3D3D something=3D3B
<=3D3B* EXTER=> >NAL *>=3D3B VAR Foo1=3D2C Foo2:Foo_t=3D3B
&=3D> >lt=3D3B* EXTERNAL *&g=> >t=3D3B PROCEDURE =3D3BUseFoo(READONLY (* or VAR *) foo:F=3D> >oo_t)=3D3=> >B
 =3D3B
(* Modula-3=3D2C not external *)
PROCEDURE x()=3D3D<=> >=3D> >BR>BEGIN
 =3D3B UseFoo(Foo1)=3D3B
 =3D3B UseFoo(Foo2)=> >=3D3B
END x=3D> >=3D3B
 =3D3B
AND I want any use of:
VAR Fo=> >o3:Foo3_t=3D3B (* Modula-3=3D> >=3D2C not external *)

to error. This=> > is sem_t and sigset_t in particul=3D> >ar.
 =3D3B
Possibly renam=> >ing is the thing.
They used to be decla=3D> >red in Modula-3=3D2C system=> >-dependently=3D2C but
I moved them to portable C.=3D> >
 =3D3B >>I could remove the types entirely and change UseFoo to take=3D> > an addre=> >ss=3D2C
and declare mask and ackSem to be integers or I guess. >>=> ><=3D3B*EXTERNAL>=3D3B VAR ackSem =3D3B: RECORD END=3D3B
 =3D=> >3B
Tha=3D> >t would satisfy but I thought it might be nicer to still pro=> >vide the named<=3D> >BR>types to refer to the external variables.
 => >=3D3B
 =3D3B- Jay >R>
> >
> ><=> >BR>From: =3D3B >f=3D> >=3D3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu
To:=> > >ss=3D3DEC_EC_Apple-converted-space> =3D3B >=3D3D"mailto:jay.krell=3D> >@cornell.edu">jay.krell at cornell.edu
Date=> >: Mon=3D2C 12 Jan 2009 11:13:0=3D> >0 +1100
CC: >le-converted-space> =3D3B >ref=3D3D"mailto:m3devel at elego=> >soft.com">m3devel at elegosoft.com
Subject: =3D> >Re: [M3devel] declari=> >ng a type's existance but not enough to instantiate it=3D> >?

What's=> > wrong with using ADDRESS for references to opaque values? &=3D> >nbsp=3D3B=> >If sigset_t is never instantiated in Modula-3=3D2C then why do you nee=3D> => >>d it declared there?
> >

> >
>-style-span style=3D3D"WORD-SPACING: 0px=3D3B =3D> >FONT: 12px Helvetica=3D=> >3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TE=3D> >XT-INDE=> >NT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-C=> >=3D> >OLLAPSE: separate">> >
>ass=3D3DEC_EC_EC_Apple-style-spa=3D> >n style=3D3D"WORD-SPACING: 0px=3D3B F=> >ONT: 12px Helvetica=3D3B TEXT-TRANSFORM: non=3D> >e=3D3B COLOR: rgb(0=3D2C0=> >=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LE=3D> >TTER-SP=> >ACING: normal=3D3B BORDER-COLLAPSE: separate"> >> >pple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=> >=3D3B TEXT-=3D> >TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-I=> >NDENT: 0px=3D3B WHITE-SPACE=3D> >: normal=3D3B LETTER-SPACING: normal=3D3B => >BORDER-COLLAPSE: separate"> >s=3D3DEC_EC_EC_Apple-style-span => >style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helv=3D> >etica=3D3B TEXT-TRAN=> >SFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D> >=3D3B=> > WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: sepa=> >r=3D> >ate"> >NG: 0px=3D3B =3D> >FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLO=> >R: rgb(0=3D2C0=3D2C0)=3D3B TE=3D> >XT-INDENT: 0px=3D3B WHITE-SPACE: normal=> >=3D3B LETTER-SPACING: normal=3D3B BORDER-C=3D> >OLLAPSE: separate"> >ass=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SP=3D> >ACING: 0px=3D3B F=> >ONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D> >=3D2C0=> >=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING:=> > nor=3D> >mal=3D3B BORDER-COLLAPSE: separate"> >e-style-span s=3D> >tyle=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=> >=3D3B TEXT-TRANSFORM: none=3D> >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-I=> >NDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LET=3D> >TER-SPACING: normal=3D3B => >BORDER-COLLAPSE: separate"> >ple-style-span => >style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-T=3D> >RAN=> >SFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE=> >-SPACE:=3D> > normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: sepa=> >rate"> >=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SPACI=> >NG: 0px=3D3B FONT: 12px Helve=3D> >tica=3D3B TEXT-TRANSFORM: none=3D3B COLO=> >R: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D> >=3D3B WHITE-SPACE: normal=> >=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separ=3D> >ate">> >
=> > >D=3D> >EC_EC_EC_Apple-style-span face=3D3D"Gill Sans"> >_EC_Apple-s=3D> >tyle-span style=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=3D3B FONT=> >-FAMILY: 'Gill Sans'"> >AN class=3D3DEC_EC_EC_Apple-style-span style=> >=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=3D3B FO=3D> >NT-FAMILY: 'Gill Sans'">Anto=> >ny Hosking >ss=3D3DEC_EC_EC_Apple-=> >style-span face=3D3D"Gill Sans"> >ple-style-=> >span style=3D3D"FONT-FAMILY: 'Gill Sans'"> >=> >ple-style-span style=3D3D"FONT-FAMILY: 'Gill Sans'"> >pple=3D> >-converted-space> =3D3B| >nverted-space>=3D> > =3D3B >_Apple-style-span style=3D> >=3D3D"FONT-FAMILY: 'Gill Sans'"> >3DEC_EC_EC_Apple-style-span style=3D> >=3D3D"FONT-FAMILY: 'Gill Sans'">Asso=> >ciate Professor >=3D3DEC_EC_EC_Apple-style-spa=> >n style=3D3D"FONT-FAMILY: 'Gill Sans'"> >=3D3DEC_EC_EC_Apple=> >-style-span style=3D3D"FONT-FAMILY: 'Gill Sans'"> =3D3B| C=3D> >omputer=> > Science | Purdue University
> >
>=3D3DEC_EC_EC_Apple-style-span face=3D3DGillSans-Light> >ass=3D=> >3DEC_EC_EC_Apple-style-span style=3D3D"FONT-FAMILY: GillSans-Light">305 N=> >=3D> >. University Street | West Lafayette | IN 47907 | USA >DIV>> >
>color=3D3D#00=3D> >00ff> >D"COLOR: rgb(0=3D2C0=3D2C25=3D> >5)=3D3B FONT-FAMILY: 'Gill Sans'"> >ass=3D3DEC_EC_EC_Apple-style-span sty=3D> >le=3D3D"COLOR: rgb(0=3D2C0=3D2C2=> >55)=3D3B FONT-FAMILY: 'Gill Sans'">Office >PAN> >lass=3D3DEC_EC_EC_Apple-style-span face=3D3DGillSans-Light> >PAN clas=> >s=3D3DEC_EC_EC_Apple-style-span style=3D3D"FONT-FAMILY: GillSans-Light"=3D>=> > >> >ns-Lig=3D> >ht"> =3D3B+1 765 494 6001 | >erted-space>&nbs=3D> >p=3D3B >EC_EC_Apple-style-span fac=3D> >e=3D3D"Gill Sans" color=3D3D#0000ff> >lass=3D3DEC_EC_EC_Apple-style-span sty=3D> >le=3D3D"COLOR: rgb(0=3D2C0=3D2C=> >255)=3D3B FONT-FAMILY: 'Gill Sans'"> >_EC_EC_Apple-st=> >yle-span style=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=3D3B FONT-FAMILY: 'G=3D> >i=> >ll Sans'">Mobile >p=3D> >an face=3D3DGillSans-Light> > style=3D3D"F=3D> >ONT-FAMILY: GillSans-Light"> >le-style-span style=3D> >=3D3D"FONT-FAMILY: GillSans-Light"> >DEC_EC_Apple-converted-space>=3D> > =3D3B+1 765 427 5484<=> >/SPAN>
> >
>=3D3DGillSans-Light>
>s=3D3DEC_EC_EC_khtml-block-placeholder> >FONT>
>AN>
>=3D3DEC_EC_EC_Apple-interchange-newline> >AN>
>>> >
> >
On 12 Jan 2009=3D2C at 01:44=3D2C Jay wrote:

>s=3D3DEC_EC_EC_App=3D> >le-interchange-newline>> >
>=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SPACING: =3D> >0px=3D3B FONT=> >: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0=3D=> >> >)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: no=> >rmal=3D3B B=3D> >ORDER-COLLAPSE: separate">> >
>sage style=3D3D"FONT-SIZE: 10pt=3D3B FONT-FAMILY: Ve=3D> >rdana">Is there a=> > way in Modula-3 to declare that =3D3Ba type exists=3D2C a=3D> >nd ther=> >e are <=3D3B*external*>=3D3B instances of it=3D2C without "fully" decl=> >=3D> >aring it=3D2C so that no Modula-3 can instantiate it?
 =3D3B >R>I have d=3D> >one this for sigset_t and sem_t=3D2C but they could erroneo=> >usly be instantiat=3D> >ed by Modula-3 and I'd like to remove that ability => >to mess up so easily. >> =3D3B
(* This type is not declared c=> >orrectly. It is only instantiate=3D> >d in C code. *)
 =3D3B sigset_=> >t =3D3D RECORD END=3D3B

(* This type =3D> >is not declared correctly=> >. It is only instantiated in C code. *)
 =3D> >=3D3B sem_t =3D3D REC=> >ORD END=3D3B

In C I believe you can do this=3D2C like:<=3D> >BR>&nbs=> >p=3D3B =3D3Btypedef struct foo foo_t=3D3B =3D3B >C_E=3D> >C_Apple-converted-space> =3D3B
 =3D3B =3D3Be=> >xtern foo_t foo=3D> >=3D3B =3D3B >d-space> =3D3B
=3D> > =3D3B
 =3D3Bvoid UseFoo(foo_=> >t*)=3D3B >erted-space> =3D3B >AN>
 =3D3B foo_t* GetFoo(void)=3D3B >=3D3DEC_EC_EC_Ap=> >ple-converted-space> =3D3B
 =3D3B
Thanks=3D2C<=3D> >BR=> >> =3D3B- Jay




<=> >=3D> >/DIV>
>E>
=3D> >

<=> >/BLOCKQUOTE> >V>
> >=3D> >> >--_6117a048-9185-4c03=> >-badb-ef8f93402268_--=> >> >--_2e194b09-14b6-4301-9116-a9e4d1e522b4_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >> >Yes=2C generating the headers is viable.
> >I thought I mentioned that a few times.
> They could be generated in any build "that can".
 =3B i.e. a native => >build=2C that has a working C development system
 =3B and checked ag=> >ainst the checked in ones.
> > =3BSo then porting is:
 =3B copy the generator to new system=> >=2C run it=2C copy results back=2C proceed
> >
 =3BMaybe a good compromise.
 =3BNot good for "embedded sys=> >tems"=2C but heck=2C is there any such thing
 =3B any longer? Doesn'=> >t everything have megs of RAM and gigs of persistant storage? :)
> >
You don't need =3BScheme.
> >Just Quake =3B+ compiling and running C code.
> >Assuming a native build system.
> >I've done stuff in cross build systems like:
> >typedef struct foo_t {int i=3B int j=3B } foo_t=3B
> >extern const int xi =3D offsetof(foo_t=2C i)=3B
> > =3B
> >compile that=2C and read the value of xi out of the .obj file.
> > =3B
> > =3BThe .obj file reader was written in Perl. :)
> > =3B (Python not available.)
> > =3Bbut to do that here=2C I'd have to support multiple .obj file forma=> >ts.
> > =3B
> > =3B- Jay

>=3B To: jay.krell at cornell.edu
>=3B Date: Mon=> >=2C 12 Jan 2009 01:34:24 -0800
>=3B From: mika at async.caltech.edu
&g=> >t=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] declaring a=> > type's existance but not enough to instantiate it?
>=3B
>=3B >R>>=3B You present it as a true tragic Dilemma.
>=3B
>=3B But => >isn't there a Third Way---to wit=2C can't you "Ask the Computer"
>=3B => >to do the work for you?
>=3B
>=3B Generate the code somehow... P=> >arsing the C headers is an obvious
>=3B way but there may be others th=> >at are simpler=2C such as writing a
>=3B Modula-3 program to generate => >the cloned M3 headers=2C sorry=2C interfaces.
>=3B
>=3B If I had=> > to do this I would use my Scheme interpreter that's coded
>=3B in Mod=> >ula-3 to write a Scheme program to generate the headers. This
>=3B pro=> >gram could pull whatever tricks are deemed necessary and suitable=2C
>=> >=3B down to the point of generating and compiling and running C programs >>>=3B as necessary (or parsing C code=2C or reading tea leaves). But the<=> >BR>>=3B end result would be a set of interfaces written in "Pure Modula-3=> >".
>=3B The process of running the header generator would also have ve=> >ry
>=3B few dependencies on anything outside the M3 distribution.
&=> >gt=3B
>=3B Mika
>=3B
>=3B Jay writes:
>=3B >=3B--_6=> >117a048-9185-4c03-badb-ef8f93402268_
>=3B >=3BContent-Type: text/pla=> >in=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Encoding: quo=> >ted-printable
>=3B >=3B
>=3B >=3B
>=3B >=3BThis is wha=> >t you "have to" chose between.
>=3B >=3BHeader cloning or C code (an=> >d C headers).
>=3B >=3B=3D20
>=3B >=3BCONST or VAR (or functi=> >ons?)
>=3B >=3B=3D20
>=3B >=3BI'm going to likely make the Ue=> >rror change tonight.
>=3B >=3BYou can still veto it (er=3D2C vote ag=> >ainst it :) )
>=3B >=3B=3D20
>=3B >=3BPossibly some convulute=> >d C (enum/#undef)=3D2C or splitting the Modula-3
>=3B >=3Bat boundar=> >ies that weren't previously believed "natural".
>=3B >=3B(See how Se=> >tupHandlers is ~two lines in Modula-3 and the rest in C=3D3B
>=3B >=> >=3Bthis is partly out of ignorance. I don't know how to write those
>=> >=3B >=3Btwo lines in C=3D3B and laziness=3D2C I didn't look into how). >>>=3B >=3B=3D20
>=3B >=3B=3D20
>=3B >=3B=3D20
>=3B &=> >gt=3BRemember I'm still staying away from mainstream platforms=3D2C
>=> >=3B >=3Bso the value isn't what it might appear to be=3D2C but it is "sta=> >ge setting"=3D
>=3B >=3B=3D2C
>=3B >=3Band the show might go => >on. :)
>=3B >=3B=3D20
>=3B >=3B=3D20
>=3B >=3BAlso=3D2=> >C the dilemna does get more difficult now=3D2C with the little C header=3D<=> >BR>>=3B >=3B cloning that remains.
>=3B >=3B=3D20
>=3B >=> >=3BFor example=3D2C look at Upthreads.i3.
>=3B >=3BMainly=3D2C look => >at function prototypes.
>=3B >=3BConstants and types are "known prob=> >lems".
>=3B >=3BPrototypes are gray. They actually tend to be portab=> >le.
>=3B >=3B=3D20
>=3B >=3BFor example:
>=3B >=3B=3D2=> >0
>=3B >=3BTYPE pid_t =3D3D INTEGER=3D3B
>=3B >=3B<=3B*EXTE=> >RNAL "m3_getpid*>=3B PROCEDURE getpid():pid_t=3D3B
>=3B >=3B=3D20<=> >BR>>=3B >=3Bor leave it alone?
>=3B >=3Bgetpid is probably the w=> >orst example.
>=3B >=3BIt is so very portable declared in Modula-3.<=> >BR>>=3B >=3BBut still=3D2C imagine pid_t might be 16bits or 32 or 64. >R>>=3B >=3BWriting a wrapper is more portable -- as long as the pid isn=> >'t stuff into s=3D
>=3B >=3Bome record that the system defines.
&=> >gt=3B >=3B=3D20
>=3B >=3B=3D20
>=3B >=3BAgain=3D2C Upthread=> >s.i3.
>=3B >=3BWould you like to see it reduced=3D2C or left alone?<=> >BR>>=3B >=3BOnly deal with the types and initializers=3D2C or also the => >prototypes?
>=3B >=3BYou know=3D2C I could write a little portable l=> >ayer=3D2C where all the types ar=3D
>=3B >=3Be pointers=3D2C always => >null initialized.
>=3B >=3BIt would buy /some/ portability=3D2C and => >cost some.
>=3B >=3B=3D20
>=3B >=3B=3D20
>=3B >=3BDo y=> >ou like the sem_t change? Partly? Not at all?
>=3B >=3BThere is one => >sem_t in the system. So I moved it to be in C code.
>=3B >=3BOr=3D2C=> > as I had it before=3D2C declared as the max size/align of all the platf=3D=> >
>=3B >=3Borms -- getting that right is the same work as getting it => >right "the old wa=3D
>=3B >=3By"=3D2C except if you make a mistake=> >=3D2C odds are still good of it being ok.
>=3B >=3B=3D20
>=3B &=> >gt=3B=3D20
>=3B >=3BShould the line be drawn at generating the remai=> >ning headers=3D2C rather than=3D
>=3B >=3B eliminating them?
>=> >=3B >=3BUerror.i3 is easily generated. Good enough?
>=3B >=3B=3D20=> >
>=3B >=3BUpthread.i3's types can be generated generally as records => >with opaque array=3D
>=3B >=3Bs with the right size and alignment. >R>>=3B >=3B=3D20
>=3B >=3BOther stuff can be generated or at lea=> >st checked.
>=3B >=3Be.g. to check that getpid is declared correctly=> >=3D2C you can assign it to a f=3D
>=3B >=3Bunction pointer and see i=> >f that compiles.
>=3B >=3B=3D20
>=3B >=3BPerf on Uerror argua=> >bly doesn't matter.
>=3B >=3BIs it only error handling code?Or do so=> >ckets often go down "error" paths=3D2C=3D
>=3B >=3B because they are=> > slow and you are waiting for more data?
>=3B >=3B=3D20
>=3B &g=> >t=3BAnyway=3D2C point is=3D2C I agree for sure this is valuable=3D2C but I => >might be h=3D
>=3B >=3Bitting the "tail" of the approach and should => >switch=3D2C I'm not sure. I keep=3D
>=3B >=3B saying that though=3D2=> >C and then press further.
>=3B >=3B=3D20
>=3B >=3B=3D20
&g=> >t=3B >=3B - Jay
>=3B >=3B
>=3B >=3B
>=3B >=3B
>=> >=3B >=3BFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon=3D2=> >C 12 Jan 200=3D
>=3B >=3B9 19:24:50 +1100CC: m3devel at elegosoft.comSu=> >bject: Re: [M3devel] declaring a=3D
>=3B >=3B type's existance but n=> >ot enough to instantiate it?
>=3B >=3B
>=3B >=3B
>=3B &g=> >t=3BPoint taken. We live in a C universe and so need to interact. I do thin=> >k =3D
>=3B >=3Byour work with the headers is useful=3D2C and I want => >it to continue. Especia=3D
>=3B >=3Blly in simplifying ports.
>=> >=3B >=3B
>=3B >=3B
>=3B >=3BOn 12 Jan 2009=3D2C at 19:18=3D=> >2C Jay wrote:
>=3B >=3B
>=3B >=3BI don't think a development => >system without C headers is interesting.. Is it=3D
>=3B >=3B really?=> > The transform I apply at times is wherever there is interaction wi=3D
&=> >gt=3B >=3Bth C code that is described by system-dependent headers=3D2C or=> > perhaps even =3D
>=3B >=3Bfairly system-independent headers outside=> > the Modula-3 tree=3D2C either write=3D
>=3B >=3B wrapper functions => >for the functionality in the headers (e.g. stat=3D2C waitp=3D
>=3B >=> >=3Bid)=3D2C which can be done in a system-independent way=3D2C or move the => >Modula-=3D
>=3B >=3B3<=3B->=3BC transition higher=3D2C which is => >also usually system-independent=3D2C e.g.=3D
>=3B >=3B ThreadPThread=> >C_SetupHandlers. It is either that or clone the headers=3D2C wh=3D
>=> >=3B >=3Bich seems like the worse evil. There is always going to be a Modu=> >la-3<=3B->=3BC t=3D
>=3B >=3Bransition=3D2C it is just a matter => >of where it occurs. - Jay
>=3B >=3B
>=3B >=3BCC: m3devel at eleg=> >osoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.e=3D
>=3B &g=> >t=3BduSubject: Re: [M3devel] declaring a type's existance but not enough to=> > ins=3D
>=3B >=3Btantiate it?Date: Mon=3D2C 12 Jan 2009 12:32:15 +11=> >00
>=3B >=3B
>=3B >=3B
>=3B >=3BJay=3D2C I really thin=> >k you are bending over backwards too far just to be abl=3D
>=3B >=3B=> >e to shoe-horn things into C. I *like* having the transpar of C header fil=> >=3D
>=3B >=3Bes expressed in Modula-3=3D2C *particularly* for system=> > calls=3D2C where you mi=3D
>=3B >=3Bght even be trying to build on => >a system that does not have the C header fil=3D
>=3B >=3Bes installe=> >d=3D2C even though the libraries exist and can be linked to. Fund=3D
>=> >=3B >=3Bamentally=3D2C I think anytime the Modula-3 code is made less tra=> >nsparent you=3D
>=3B >=3B should think hard about what you are doing=> >. The same with the change of c=3D
>=3B >=3Bonstants to variables. >R>>=3B >=3B
>=3B >=3BI am getting very nervous that the changes => >you are making are destroying th=3D
>=3B >=3Be clarity of the Modula=> >-3 run-time code.
>=3B >=3B
>=3B >=3BIn this particular case=> >=3D2C you are wanting to use a Modula-3 parameter pass=3D
>=3B >=3Bi=> >ng mechanism on something that is not declared in Modula-3. Seems kind of=> >=3D
>=3B >=3B dubious to me. Also=3D2C I really don't like the idea => >of accessing external=3D
>=3B >=3B variables in C.
>=3B >=3B<=> >BR>>=3B >=3B-- Tony
>=3B >=3B
>=3B >=3BOn 12 Jan 2009=3D2=> >C at 11:55=3D2C Jay wrote:
>=3B >=3B
>=3B >=3BI considered AD=> >DRESS.However I think it still doesn't satisfy. I want to be=3D
>=3B &=> >gt=3B able to do this: TYPE Foo_t =3D3D something=3D3B<=3B* EXTERNAL *>=> >=3B VAR Foo1=3D2C Foo=3D
>=3B >=3B2:Foo_t=3D3B<=3B* EXTERNAL *>=> >=3B PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t)=3D
>=3B >=3B=> >=3D3B (* Modula-3=3D2C not external *)PROCEDURE x()=3D3DBEGIN UseFoo(Foo1)=> >=3D3B U=3D
>=3B >=3BseFoo(Foo2)=3D3BEND x=3D3B AND I want any use of=> >:VAR Foo3:Foo3_t=3D3B (* Modula-3=3D
>=3B >=3B=3D2C not external *)t=> >o error. This is sem_t and sigset_t in particular. Poss=3D
>=3B >=3B=> >ibly renaming is the thing.They used to be declared in Modula-3=3D2C system=> >-d=3D
>=3B >=3Bependently=3D2C butI moved them to portable C. I coul=> >d remove the types entir=3D
>=3B >=3Bely and change UseFoo to take a=> >n address=3D2Cand declare mask and ackSem to b=3D
>=3B >=3Be integer=> >s or I guess.<=3B*EXTERNAL>=3B VAR ackSem : RECORD END=3D3B That would => >sat=3D
>=3B >=3Bisfy but I thought it might be nicer to still provid=> >e the namedtypes to ref=3D
>=3B >=3Ber to the external variables. - => >Jay
>=3B >=3B
>=3B >=3BFrom: hosking at cs.purdue.eduTo: jay.kre=> >ll at cornell.eduDate: Mon=3D2C 12 Jan 200=3D
>=3B >=3B9 11:13:00 +1100=> >CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a=3D
>=3B &g=> >t=3B type's existance but not enough to instantiate it?What's wrong with us=> >ing =3D
>=3B >=3BADDRESS for references to opaque values? If sigset_=> >t is never instantiated=3D
>=3B >=3B in Modula-3=3D2C then why do yo=> >u need it declared there?
>=3B >=3B
>=3B >=3B
>=3B >=> >=3B
>=3B >=3BAntony Hosking | Associate Professor | Computer Science=> > | Purdue University
>=3B >=3B305 N. University Street | West Lafaye=> >tte | IN 47907 | USA
>=3B >=3BOffice +1 765 494 6001 | Mobile +1 765=> > 427 5484
>=3B >=3B
>=3B >=3B
>=3B >=3BOn 12 Jan 2009=> >=3D2C at 01:44=3D2C Jay wrote:
>=3B >=3B
>=3B >=3BIs there a => >way in Modula-3 to declare that a type exists=3D2C and there are <=3B=3D<=> >BR>>=3B >=3B*external*>=3B instances of it=3D2C without "fully" decla=> >ring it=3D2C so that no M=3D
>=3B >=3Bodula-3 can instantiate it? I => >have done this for sigset_t and sem_t=3D2C but =3D
>=3B >=3Bthey cou=> >ld erroneously be instantiated by Modula-3 and I'd like to remove t=3D
&=> >gt=3B >=3Bhat ability to mess up so easily. (* This type is not declared => >correctly. I=3D
>=3B >=3Bt is only instantiated in C code. *) sigset=> >_t =3D3D RECORD END=3D3B(* This typ=3D
>=3B >=3Be is not declared co=> >rrectly. It is only instantiated in C code. *) sem_t =3D
>=3B >=3B=> >=3D3D RECORD END=3D3BIn C I believe you can do this=3D2C like: typedef stru=> >ct fo=3D
>=3B >=3Bo foo_t=3D3B extern foo_t foo=3D3B void UseFoo(foo=> >_t*)=3D3B foo_t* GetFoo=3D
>=3B >=3B(void)=3D3B Thanks=3D2C - Jay=3D=> >
>=3B >=3B
>=3B >=3B--_6117a048-9185-4c03-badb-ef8f93402268_<=> >BR>>=3B >=3BContent-Type: text/html=3B charset=3D"iso-8859-1"
>=3B=> > >=3BContent-Transfer-Encoding: quoted-printable
>=3B >=3B
>=> >=3B >=3B<=3Bhtml>=3B
>=3B >=3B<=3Bhead>=3B
>=3B >=> >=3B<=3Bstyle>=3B
>=3B >=3B.hmmessage P
>=3B >=3B{
>=> >=3B >=3Bmargin:0px=3D3B
>=3B >=3Bpadding:0px
>=3B >=3B}
=> >>=3B >=3Bbody.hmmessage
>=3B >=3B{
>=3B >=3Bfont-size: 10=> >pt=3D3B
>=3B >=3Bfont-family:Verdana
>=3B >=3B}
>=3B >=> >=3B<=3B/style>=3B
>=3B >=3B<=3B/head>=3B
>=3B >=3B<=> >=3Bbody class=3D3D'hmmessage'>=3B
>=3B >=3BThis is what you "have => >to" chose between.<=3BBR>=3B
>=3B >=3BHeader cloning or C code (=> >and C headers).<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=> >=3B
>=3B >=3BCONST or VAR (or functions?)<=3BBR>=3B
>=3B &g=> >t=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BI'm going to likely make=> > the Uerror change tonight.<=3BBR>=3B
>=3B >=3BYou can still vet=> >o it (er=3D2C vote against it :) )<=3BBR>=3B
>=3B >=3B&=3Bnbs=> >p=3D3B<=3BBR>=3B
>=3B >=3BPossibly some convuluted C (enum/#unde=> >f)=3D2C or splitting the Modula-3<=3BBR>=3B
>=3B >=3Bat boundari=> >es that weren't previously believed "natural".<=3BBR>=3B
>=3B >=> >=3B(See how SetupHandlers is ~two lines in Modula-3 and the rest in C=3D3B&=> >lt=3BBR>=3B
>=3B >=3Bthis is partly out of ignorance. I don't know=> > how to write those<=3BBR>=3B
>=3B >=3Btwo lines in C=3D3B and l=> >aziness=3D2C I didn't look into how).<=3BBR>=3B
>=3B >=3B&=3B=> >nbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
&=> >gt=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BRemember I'm sti=> >ll staying away from mainstream platforms=3D2C<=3BBR>=3B
>=3B >=> >=3Bso the value isn't what it might appear to be=3D2C but it is "stage sett=> >ing"=3D
>=3B >=3B=3D2C<=3BBR>=3B
>=3B >=3Band the show mi=> >ght go on. :)<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B<=> >BR>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BAlso=3D2C th=> >e dilemna does get more difficult now=3D2C with the little C header=3D
&=> >gt=3B >=3B cloning that remains.<=3BBR>=3B
>=3B >=3B&=3Bnbs=> >p=3D3B<=3BBR>=3B
>=3B >=3BFor example=3D2C look at Upthreads.i3.=> ><=3BBR>=3B
>=3B >=3BMainly=3D2C look at function prototypes.<=> >=3BBR>=3B
>=3B >=3BConstants and types are "known problems".<=3B=> >BR>=3B
>=3B >=3BPrototypes are gray. They actually tend to be port=> >able.<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=> >=3B >=3BFor example:<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3B=> >BR>=3B
>=3B >=3BTYPE pid_t =3D3D INTEGER=3D3B<=3BBR>=3B
>=> >=3B >=3B&=3Blt=3D3B*EXTERNAL "m3_getpid*&=3Bgt=3D3B PROCEDURE getpi=> >d():pid_t=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B=> >
>=3B >=3Bor leave it alone?<=3BBR>=3B
>=3B >=3Bgetpid is=> > probably the worst example.<=3BBR>=3B
>=3B >=3BIt is so very po=> >rtable declared in Modula-3.<=3BBR>=3B
>=3B >=3BBut still=3D2C i=> >magine pid_t might be 16bits or 32 or 64.<=3BBR>=3B
>=3B >=3BWri=> >ting a wrapper is more portable -- as long as the pid isn't stuff into s=3D=> >
>=3B >=3Bome record that the system defines.<=3BBR>=3B
>=> >=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B&l=> >t=3BBR>=3B
>=3B >=3BAgain=3D2C Upthreads.i3.<=3BBR>=3B
>=> >=3B >=3BWould you like to see it reduced=3D2C or left alone?<=3BBR>=> >=3B
>=3B >=3BOnly deal with the types and initializers=3D2C or also => >the prototypes?<=3BBR>=3B
>=3B >=3BYou know=3D2C I could write a=> > little portable layer=3D2C where all the types ar=3D
>=3B >=3Be poi=> >nters=3D2C always null initialized.<=3BBR>=3B
>=3B >=3BIt would => >buy /some/ portability=3D2C and cost some.<=3BBR>=3B
>=3B >=3B&a=> >mp=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B=> >
>=3B >=3BDo you like the sem_t change? Partly? Not at all?<=3BBR&=> >gt=3B
>=3B >=3BThere is one sem_t in the system. So I moved it to be=> > in C code.<=3BBR>=3B
>=3B >=3BOr=3D2C as I had it before=3D2C d=> >eclared as the max size/align of all the platf=3D
>=3B >=3Borms -- g=> >etting that right is the same work as getting it right "the old wa=3D
&g=> >t=3B >=3By"=3D2C except if you make a mistake=3D2C odds are still good of=> > it being ok.<=3BB=3D
>=3B >=3BR>=3B
>=3B >=3B&=3Bnbsp=> >=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=> >=3B >=3BShould the line be drawn at generating the remaining headers=3D2C=> > rather than=3D
>=3B >=3B eliminating them?<=3BBR>=3B
>=3B => >>=3BUerror.i3 is easily generated. Good enough?<=3BBR>=3B
>=3B &=> >gt=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BUpthread.i3's types can=> > be generated generally as records with opaque array=3D
>=3B >=3Bs w=> >ith the right size and alignment.<=3BBR>=3B
>=3B >=3B&=3Bnbsp=> >=3D3B<=3BBR>=3B
>=3B >=3BOther stuff can be generated or at leas=> >t checked.<=3BBR>=3B
>=3B >=3Be.g. to check that getpid is decla=> >red correctly=3D2C you can assign it to a f=3D
>=3B >=3Bunction poin=> >ter and see if that compiles.<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3=> >B<=3BBR>=3B
>=3B >=3BPerf on Uerror arguably doesn't matter.<=> >=3BBR>=3B
>=3B >=3BIs it only error handling code?<=3BBR>=3BOr=> > do sockets often go down "error" path=3D
>=3B >=3Bs=3D2C because th=> >ey are slow and you are waiting for more data?<=3BBR>=3B
>=3B >=> >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BAnyway=3D2C point is=3D2C=> > I agree for sure this is valuable=3D2C but I might be h=3D
>=3B >=> >=3Bitting the "tail" of the approach and should switch=3D2C I'm not sure. I=> > keep=3D
>=3B >=3B saying that though=3D2C and then press further.&l=> >t=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=> >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B- Jay<=> >=3BBR>=3B<=3BBR>=3B
>=3B >=3B
>=3B >=3B<=3BHR id=3D3D=> >stopSpelling>=3B
>=3B <=3BBR>=3B
>=3B >=3BFrom: hosking at c=> >s.purdue.edu<=3BBR>=3BTo: jay.krell at cornell.edu<=3BBR>=3BDate: Mon=> >=3D2C 12=3D
>=3B >=3B Jan 2009 19:24:50 +1100<=3BBR>=3BCC: m3dev=> >el at elegosoft.com<=3BBR>=3BSubject: Re: [M3de=3D
>=3B >=3Bvel] de=> >claring a type's existance but not enough to instantiate it?<=3BBR>=3B&=> >lt=3BBR>=3B=3D
>=3B >=3B<=3BBR>=3B
>=3B >=3B<=3BDIV&g=> >t=3B<=3BSPAN class=3D3DEC_Apple-style-span style=3D3D"WORD-SPACING: 0px=> >=3D3B FONT: =3D
>=3B >=3B12px Helvetica=3D3B TEXT-TRANSFORM: none=3D=> >3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-IND=3D
>=3B >=3BENT: 0px=3D3B=> > WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPS=3D
=> >>=3B >=3BE: separate">=3B
>=3B >=3B<=3BDIV style=3D3D"WORD-W=> RAP: break-word">=3B<=3BSPAN class=3D3DEC_Apple-style-span styl=3D
&=> >gt=3B >=3Be=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TR=> >ANSFORM: none=3D3B C=3D
>=3B >=3BOLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-=> >INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-S=3D
>=3B >=3BPACIN=> >G: normal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=3D3DEC_Appl=> >e-style-s=3D
>=3B >=3Bpan style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12=> >px Helvetica=3D3B TEXT-TRANSFORM: n=3D
>=3B >=3Bone=3D3B COLOR: rgb(=> >0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B =3D
&=> >gt=3B >=3BLETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate">=3B<=> >=3BSPAN class=3D3DEC_Apple=3D
>=3B >=3B-style-span style=3D3D"WORD-S=> >PACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRAN=3D
>=3B >=3BSFO=> >RM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SP=> >ACE: no=3D
>=3B >=3Brmal=3D3B LETTER-SPACING: normal=3D3B BORDER-COL=> >LAPSE: separate">=3B<=3BSPAN class=3D3D=3D
>=3B >=3BEC_Apple-sty=> >le-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B T=3D >>>=3B >=3BEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-=> >INDENT: 0px=3D3B WHITE-S=3D
>=3B >=3BPACE: normal=3D3B LETTER-SPACIN=> >G: normal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN =3D
>=3B >=> >=3Bclass=3D3DEC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12=> >px Helvet=3D
>=3B >=3Bica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(=> >0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B=3D
>=3B >=3B WHITE-SPACE: => >normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate=3D
>=> >=3B >=3B">=3B<=3BSPAN class=3D3DEC_Apple-style-span style=3D3D"WORD-S=> >PACING: 0px=3D3B FONT: 12p=3D
>=3B >=3Bx Helvetica=3D3B TEXT-TRANSFO=> >RM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT=3D
>=3B >=> >=3B: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-C=> >OLLAPSE: =3D
>=3B >=3Bseparate">=3B<=3BSPAN class=3D3DEC_Apple-s=> >tyle-span style=3D3D"WORD-SPACING: 0px=3D3B F=3D
>=3B >=3BONT: 12px => >Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEX=> >=3D
>=3B >=3BT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPAC=> >ING: normal=3D3B BORDER-CO=3D
>=3B >=3BLLAPSE: separate">=3B<=3B=> >SPAN class=3D3DEC_Apple-style-span style=3D3D"WORD-SPACING: =3D
>=3B &=> >gt=3B0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rg=> >b(0=3D2C0=3D2C0=3D
>=3B >=3B)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE=> >: normal=3D3B LETTER-SPACING: normal=3D3B B=3D
>=3B >=3BORDER-COLLAP=> >SE: separate">=3B
>=3B >=3B<=3BDIV>=3BPoint taken. &=3Bnbsp=> >=3D3BWe live in a C universe and so need to interact. =3D
>=3B >=3B&=> >amp=3Bnbsp=3D3BI do think your work with the headers is useful=3D2C and I w=> >ant it to=3D
>=3B >=3B continue. &=3Bnbsp=3D3BEspecially in simpl=> >ifying ports.<=3B/DIV>=3B
>=3B >=3B<=3BDIV>=3B<=3BBR>=3B=> ><=3B/DIV>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/S=> >PAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=> >=3B<=3B/DI=3D
>=3B >=3BV>=3B<=3B/SPAN>=3B<=3B/DIV>=3B >>>=3B >=3B<=3BDIV>=3B
>=3B >=3B<=3BDIV>=3BOn 12 Jan 2009=> >=3D2C at 19:18=3D2C Jay wrote:<=3B/DIV>=3B<=3BBR class=3D3DEC_Apple-i=> >nt=3D
>=3B >=3Berchange-newline>=3B
>=3B >=3B<=3BBLOCKQUO=> >TE>=3B<=3BSPAN class=3D3DEC_Apple-style-span style=3D3D"WORD-SPACING: 0=> >px=3D3B=3D
>=3B >=3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=> >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B T=3D
>=3B >=3BEXT-INDENT: 0px=> >=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-=3D
&g=> >t=3B >=3BCOLLAPSE: separate">=3B
>=3B >=3B<=3BDIV class=3D3DEC=> >_hmmessage style=3D3D"FONT-SIZE: 10pt=3D3B FONT-FAMILY: Verdana"=3D
>=> >=3B >=3B>=3BI don't think a development system without C headers is int=> >eresting.. Is i=3D
>=3B >=3Bt really?<=3BBR>=3B&=3Bnbsp=3D3B&=> >lt=3BBR>=3BThe transform I apply at times is wherever there i=3D
>=> >=3B >=3Bs interaction with C code that is described by system-dependent h=> >eaders=3D2C =3D
>=3B >=3Bor perhaps even fairly system-independent h=> >eaders outside the Modula-3 tree=3D
>=3B >=3B=3D2C either write wrap=> >per functions for the functionality in the headers (e.=3D
>=3B >=3Bg=> >. stat=3D2C waitpid)=3D2C which&=3Bnbsp=3D3Bcan be done in a system-inde=> >pendent way=3D
>=3B >=3B=3D2C&=3Bnbsp=3D3Bor move the Modula-3&am=> >p=3Blt=3D3B-&=3Bgt=3D3BC transition higher=3D2C which is=3D
>=3B &g=> >t=3B also usually system-independent=3D2C e.g. ThreadPThreadC_SetupHandlers=> >.<=3BBR>=3B&=3B=3D
>=3B >=3Bnbsp=3D3B<=3BBR>=3BIt is eith=> >er that or clone the headers=3D2C which seems like the w=3D
>=3B >=> >=3Borse evil.<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3BThere is always go=> >ing to be a Modula-3&=3Blt=3D3B-&=3Bgt=3D
>=3B >=3B=3D3BC tran=> >sition=3D2C it is just a matter of where it occurs.<=3BBR>=3B&=3Bnbs=> >p=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bnbsp=3D3B- Jay<=3BBR>=3B=> ><=3BBR>=3B
>=3B >=3B<=3BHR id=3D3DEC_stopSpelling>=3B
>=> >=3B >=3B<=3BBR>=3BCC:<=3BSPAN class=3D3DEC_Apple-converted-space>=> >=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BA href=3D3D"mai=3D
>=3B >=> >=3Blto:m3devel at elegosoft.com">=3Bm3devel at elegosoft.com<=3B/A>=3B<=> >=3BBR>=3BFrom:<=3BSPAN class=3D3D=3D
>=3B >=3BEC_Apple-converted=> >-space>=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BA href=3D3D"mailto:hoski=> >ng at cs.purdue=3D
>=3B >=3B.edu">=3Bhosking at cs.purdue.edu<=3B/A>=> >=3B<=3BBR>=3BTo:<=3BSPAN class=3D3DEC_Apple-converted-spac=3D
>=> >=3B >=3Be>=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BA href=3D3D"mailto:=> >jay.krell at cornell.edu">=3Bjay.krell at cornell=3D
>=3B >=3B.edu<=3B=> >/A>=3B<=3BBR>=3BSubject: Re: [M3devel] declaring a type's existance b=> >ut not eno=3D
>=3B >=3Bugh to instantiate it?<=3BBR>=3BDate: Mon=> >=3D2C 12 Jan 2009 12:32:15 +1100<=3BBR>=3B<=3BBR>=3B<=3BB=3D
&=> >gt=3B >=3BR>=3B
>=3B <=3BDIV>=3B<=3BSPAN class=3D3DEC_EC_App=> >le-style-span style=3D3D"WORD-SPACING: 0px=3D3B FON=3D
>=3B >=3BT: 1=> >2px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B=> > TEXT-=3D
>=3B >=3BINDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-=> >SPACING: normal=3D3B BORDER-COLL=3D
>=3B >=3BAPSE: separate">=3B >R>>=3B >=3B<=3BDIV style=3D3D"WORD-WRAP: break-word">=3B<=3BSPAN => >class=3D3DEC_EC_Apple-style-span s=3D
>=3B >=3Btyle=3D3D"WORD-SPACIN=> >G: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D
>=3B >=> >=3B=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: => >normal=3D3B LET=3D
>=3B >=3BTER-SPACING: normal=3D3B BORDER-COLLAPSE=> >: separate">=3B<=3BSPAN class=3D3DEC_EC_Apple=3D
>=3B >=3B-style=> >-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRAN=> >=3D
>=3B >=3BSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-IN=> >DENT: 0px=3D3B WHITE-SPACE: no=3D
>=3B >=3Brmal=3D3B LETTER-SPACING:=> > normal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=3D3D=3D
&g=> >t=3B >=3BEC_EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 1=> >2px Helvetica=3D
>=3B >=3B=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb=> >(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WH=3D
>=3B >=3BITE-SPACE:=> > normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate">=3B&l=> >t=3B=3D
>=3B >=3BSPAN class=3D3DEC_EC_Apple-style-span style=3D3D"WO=> >RD-SPACING: 0px=3D3B FONT: 12p=3D
>=3B >=3Bx Helvetica=3D3B TEXT-TRA=> >NSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT=3D
>=3B &=> >gt=3B: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER=> >-COLLAPSE: =3D
>=3B >=3Bseparate">=3B<=3BSPAN class=3D3DEC_EC_Ap=> >ple-style-span style=3D3D"WORD-SPACING: 0px=3D
>=3B >=3B=3D3B FONT: => >12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D<=> >BR>>=3B >=3B=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER=> >-SPACING: normal=3D3B BO=3D
>=3B >=3BRDER-COLLAPSE: separate">=3B&=> >lt=3BSPAN class=3D3DEC_EC_Apple-style-span style=3D3D"WORD=3D
>=3B >=> >=3B-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B C=> >OLOR: rgb=3D
>=3B >=3B(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHI=> >TE-SPACE: normal=3D3B LETTER-SPACING: n=3D
>=3B >=3Bormal=3D3B BORDE=> >R-COLLAPSE: separate">=3B<=3BSPAN class=3D3DEC_EC_Apple-style-span st=> >=3D
>=3B >=3Byle=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D=> >3B TEXT-TRANSFORM: none=3D3B=3D
>=3B >=3B COLOR: rgb(0=3D2C0=3D2C0)=> >=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER=3D
>=3B &g=> >t=3B-SPACING: normal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=> >=3D3DEC_EC_Apple-st=3D
>=3B >=3Byle-span style=3D3D"WORD-SPACING: 0p=> >x=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFO=3D
>=3B >=3BRM: none=> >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: nor=> >ma=3D
>=3B >=3Bl=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: s=> >eparate">=3B
>=3B >=3B<=3BDIV>=3BJay=3D2C I really think you a=> >re bending over backwards too far just to b=3D
>=3B >=3Be able to sh=> >oe-horn things into C. &=3Bnbsp=3D3BI *like* having the transpar of =3D<=> >BR>>=3B >=3BC header files expressed in Modula-3=3D2C *particularly* fo=> >r system calls=3D2C =3D
>=3B >=3Bwhere you might even be trying to b=> >uild on a system that does not have the =3D
>=3B >=3BC header files => >installed=3D2C even though the libraries exist and can be link=3D
>=3B=> > >=3Bed to. &=3Bnbsp=3D3BFundamentally=3D2C I think anytime the Modula=> >-3 code is made l=3D
>=3B >=3Bess transparent you should think hard => >about what you are doing. &=3Bnbsp=3D3BThe=3D
>=3B >=3B same with=> > the change of constants to variables.<=3B/DIV>=3B
>=3B >=3B<=> >=3BDIV>=3B<=3BBR>=3B<=3B/DIV>=3B
>=3B >=3B<=3BDIV>=3BI=> > am getting very nervous that the changes you are making are destroyi=3D >>>=3B >=3Bng the clarity of the Modula-3 run-time code.<=3B/DIV>=3B=> >
>=3B >=3B<=3BDIV>=3B<=3BBR>=3B<=3B/DIV>=3B
>=3B &g=> >t=3B<=3BDIV>=3BIn this particular case=3D2C you are wanting to use a Mo=> >dula-3 parameter=3D
>=3B >=3B passing mechanism on something that is=> > not declared in Modula-3. &=3Bnbsp=3D3BS=3D
>=3B >=3Beems kind o=> >f dubious to me. &=3Bnbsp=3D3BAlso=3D2C I really don't like the idea of=> >=3D
>=3B >=3B accessing external variables in C.<=3B/DIV>=3B
=> >>=3B >=3B<=3BDIV>=3B<=3BBR>=3B<=3B/DIV>=3B
>=3B >=3B=> ><=3BDIV>=3B-- Tony<=3B/DIV>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=> >=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPA=> >N>=3B<=3B/SPAN>=3B<=3B=3D
>=3B >=3B/DIV>=3B<=3B/SPAN>=> >=3B<=3B/DIV>=3B<=3BBR>=3B
>=3B >=3B<=3BDIV>=3B
>=3B=> > >=3B<=3BDIV>=3BOn 12 Jan 2009=3D2C at 11:55=3D2C Jay wrote:<=3B/DI=> >V>=3B<=3BBR class=3D3DEC_EC_Apple-=3D
>=3B >=3Binterchange-newli=> >ne>=3B
>=3B >=3B<=3BBLOCKQUOTE>=3B<=3BSPAN class=3D3DEC_EC_A=> >pple-style-span style=3D3D"WORD-SPACING: 0px=3D
>=3B >=3B=3D3B FONT:=> > 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D=> >
>=3B >=3B=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTE=> >R-SPACING: normal=3D3B BO=3D
>=3B >=3BRDER-COLLAPSE: separate">=3B=> >
>=3B >=3B<=3BDIV class=3D3DEC_EC_hmmessage style=3D3D"FONT-SIZE: => >10pt=3D3B FONT-FAMILY: Verda=3D
>=3B >=3Bna">=3BI considered ADDRE=> >SS.<=3BBR>=3BHowever I think it still doesn't satisfy.<=3BBR>=3B&am=> >p=3B=3D
>=3B >=3Bnbsp=3D3B<=3BBR>=3BI want to be able to do this=> >:<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3BTYPE&=3Bnbsp=3D3BFoo_t =3D<=> >BR>>=3B >=3B=3D3D something=3D3B<=3BBR>=3B&=3Blt=3D3B* EXTERNAL => >*&=3Bgt=3D3B VAR Foo1=3D2C Foo2:Foo_t=3D3B<=3BBR>=3B&=3B=3D
&g=> >t=3B >=3Blt=3D3B* EXTERNAL *&=3Bgt=3D3B PROCEDURE&=3Bnbsp=3D3BUseFo=> >o(READONLY (* or VAR *) foo:F=3D
>=3B >=3Boo_t)=3D3B<=3BBR>=3B&a=> >mp=3Bnbsp=3D3B<=3BBR>=3B(* Modula-3=3D2C not external *)<=3BBR>=3BP=> >ROCEDURE x()=3D3D<=3B=3D
>=3B >=3BBR>=3BBEGIN<=3BBR>=3B&=> >=3Bnbsp=3D3B UseFoo(Foo1)=3D3B<=3BBR>=3B&=3Bnbsp=3D3B UseFoo(Foo2)=> >=3D3B<=3BBR>=3BEND x=3D
>=3B >=3B=3D3B<=3BBR>=3B&=3Bnbsp=> >=3D3B<=3BBR>=3BAND I want any use of:<=3BBR>=3BVAR Foo3:Foo3_t=3D3B=> > (* Modula-3=3D
>=3B >=3B=3D2C not external *)<=3BBR>=3B<=3BBR=> >>=3Bto error. This is sem_t and sigset_t in particul=3D
>=3B >=3Ba=> >r.<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3BPossibly renaming is the thin=> >g.<=3BBR>=3BThey used to be decla=3D
>=3B >=3Bred in Modula-3=3D=> >2C system-dependently=3D2C but<=3BBR>=3BI moved them to portable C.=3D<=> >BR>>=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3BI could remove => >the types entirely and change UseFoo to take=3D
>=3B >=3B an address=> >=3D2C<=3BBR>=3Band declare mask and ackSem to be integers or I guess.&l=> >t=3BBR=3D
>=3B >=3B>=3B&=3Blt=3D3B*EXTERNAL&=3Bgt=3D3B VAR a=> >ckSem&=3Bnbsp=3D3B: RECORD END=3D3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BB=> >R>=3BTha=3D
>=3B >=3Bt would satisfy but I thought it might be nic=> >er to still provide the named<=3B=3D
>=3B >=3BBR>=3Btypes to ref=> >er to the external variables.<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B&a=> >mp=3Bnbsp=3D3B- Jay<=3BB=3D
>=3B >=3BR>=3B<=3BBR>=3B
>=> >=3B >=3B<=3BHR id=3D3DEC_EC_stopSpelling>=3B
>=3B >=3B<=3BBR=> >>=3BFrom:<=3BSPAN class=3D3DEC_EC_Apple-converted-space>=3B&=3Bnbs=> >p=3D3B<=3B/SPAN>=3B<=3BA href=3D
>=3B >=3B=3D3D"mailto:hosking=> >@cs.purdue.edu">=3Bhosking at cs.purdue.edu<=3B/A>=3B<=3BBR>=3BTo:&l=> >t=3BSPAN cla=3D
>=3B >=3Bss=3D3DEC_EC_Apple-converted-space>=3B&am=> >p=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BA href=3D3D"mailto:jay.krell=3D
>=> >=3B >=3B at cornell.edu">=3Bjay.krell at cornell.edu<=3B/A>=3B<=3BBR>=> >=3BDate: Mon=3D2C 12 Jan 2009 11:13:0=3D
>=3B >=3B0 +1100<=3BBR>=> >=3BCC:<=3BSPAN class=3D3DEC_EC_Apple-converted-space>=3B&=3Bnbsp=3D3=> >B<=3B/SPAN>=3B<=3BA h=3D
>=3B >=3Bref=3D3D"mailto:m3devel at eleg=> >osoft.com">=3Bm3devel at elegosoft.com<=3B/A>=3B<=3BBR>=3BSubject: => >=3D
>=3B >=3BRe: [M3devel] declaring a type's existance but not enou=> >gh to instantiate it=3D
>=3B >=3B?<=3BBR>=3B<=3BBR>=3BWhat's=> > wrong with using ADDRESS for references to opaque values? &=3B=3D
&g=> >t=3B >=3Bnbsp=3D3BIf sigset_t is never instantiated in Modula-3=3D2C then=> > why do you nee=3D
>=3B >=3Bd it declared there?<=3BBR>=3B
&g=> >t=3B >=3B<=3BDIV>=3B<=3BBR>=3B
>=3B >=3B<=3BDIV>=3B<=> >=3BSPAN class=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D=> >3B =3D
>=3B >=3BFONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B => >COLOR: rgb(0=3D2C0=3D2C0)=3D3B TE=3D
>=3B >=3BXT-INDENT: 0px=3D3B WH=> >ITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-C=3D
>=3B &g=> >t=3BOLLAPSE: separate">=3B
>=3B >=3B<=3BDIV style=3D3D"WORD-WRAP=> >: break-word">=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-spa=3D
>=> >=3B >=3Bn style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEX=> >T-TRANSFORM: non=3D
>=3B >=3Be=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B T=> >EXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LE=3D
>=3B >=3BTTER-SP=> >ACING: normal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=3D3DEC_=> >EC_EC_A=3D
>=3B >=3Bpple-style-span style=3D3D"WORD-SPACING: 0px=3D3=> >B FONT: 12px Helvetica=3D3B TEXT-=3D
>=3B >=3BTRANSFORM: none=3D3B C=> >OLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE=3D
>=> >=3B >=3B: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separa=> >te">=3B<=3BSPAN clas=3D
>=3B >=3Bs=3D3DEC_EC_EC_Apple-style-span=> > style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helv=3D
>=3B >=3Betica=> >=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT:=> > 0px=3D
>=3B >=3B=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: norm=> >al=3D3B BORDER-COLLAPSE: separ=3D
>=3B >=3Bate">=3B<=3BSPAN clas=> >s=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B =3D
&g=> >t=3B >=3BFONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=> >=3D2C0=3D2C0)=3D3B TE=3D
>=3B >=3BXT-INDENT: 0px=3D3B WHITE-SPACE: n=> >ormal=3D3B LETTER-SPACING: normal=3D3B BORDER-C=3D
>=3B >=3BOLLAPSE:=> > separate">=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-span style=3D3D"W=> >ORD-SP=3D
>=3B >=3BACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TR=> >ANSFORM: none=3D3B COLOR: rgb(0=3D
>=3B >=3B=3D2C0=3D2C0)=3D3B TEXT-=> >INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: nor=3D
>=3B => >>=3Bmal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=3D3DEC_EC_E=> >C_Apple-style-span s=3D
>=3B >=3Btyle=3D3D"WORD-SPACING: 0px=3D3B FO=> >NT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D
>=3B >=3B=3D3B COLOR=> >: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LE=> >T=3D
>=3B >=3BTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate">=> >=3B<=3BSPAN class=3D3DEC_EC_EC_Ap=3D
>=3B >=3Bple-style-span style=> >=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-T=3D
>=3B => >>=3BRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=> >=3D3B WHITE-SPACE:=3D
>=3B >=3B normal=3D3B LETTER-SPACING: normal=> >=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=3D
>=3B >=3B=> >=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px=> > Helve=3D
>=3B >=3Btica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=> >=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D
>=3B >=3B=3D3B WHITE-SPACE: n=> >ormal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separ=3D
>=3B => >>=3Bate">=3B
>=3B >=3B<=3BDIV>=3B<=3BFONT class=3D3DEC_EC_=> >EC_Apple-style-span color=3D3D#0000ff>=3B<=3BFONT class=3D3D=3D
>=> >=3B >=3BEC_EC_EC_Apple-style-span face=3D3D"Gill Sans">=3B<=3BSPAN cl=> >ass=3D3DEC_EC_EC_Apple-s=3D
>=3B >=3Btyle-span style=3D3D"COLOR: rgb=> >(0=3D2C0=3D2C255)=3D3B FONT-FAMILY: 'Gill Sans'">=3B<=3BSP=3D
>=3B=> > >=3BAN class=3D3DEC_EC_EC_Apple-style-span style=3D3D"COLOR: rgb(0=3D2C0=> >=3D2C255)=3D3B FO=3D
>=3B >=3BNT-FAMILY: 'Gill Sans'">=3BAntony Ho=> >sking<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/FONT>=3B<=3B/FONT>=3B&l=> >t=3BFONT cla=3D
>=3B >=3Bss=3D3DEC_EC_EC_Apple-style-span face=3D3D"=> >Gill Sans">=3B<=3BSPAN class=3D3DEC_EC_EC_Ap=3D
>=3B >=3Bple-sty=> >le-span style=3D3D"FONT-FAMILY: 'Gill Sans'">=3B<=3BSPAN class=3D3DEC_E=> >C_EC_Ap=3D
>=3B >=3Bple-style-span style=3D3D"FONT-FAMILY: 'Gill San=> >s'">=3B<=3BSPAN class=3D3DEC_EC_Apple=3D
>=3B >=3B-converted-spa=> >ce>=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B|<=3BSPAN class=3D3DEC_EC_Apple-=> >converted-space>=3B=3D
>=3B >=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B&=> >lt=3B/SPAN>=3B<=3B/SPAN>=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-=> >span style=3D
>=3B >=3B=3D3D"FONT-FAMILY: 'Gill Sans'">=3B<=3BSP=> >AN class=3D3DEC_EC_EC_Apple-style-span style=3D
>=3B >=3B=3D3D"FONT-=> >FAMILY: 'Gill Sans'">=3BAssociate Professor<=3B/SPAN>=3B<=3B/SPAN&g=> >t=3B<=3BSPAN class=3D
>=3B >=3B=3D3DEC_EC_EC_Apple-style-span styl=> >e=3D3D"FONT-FAMILY: 'Gill Sans'">=3B<=3BSPAN class=3D
>=3B >=3B=> >=3D3DEC_EC_EC_Apple-style-span style=3D3D"FONT-FAMILY: 'Gill Sans'">=3B&a=> >mp=3Bnbsp=3D3B| C=3D
>=3B >=3Bomputer Science | Purdue University<=> >=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/FONT>=3B<=3B/DIV>=3B
>=3B => >>=3B<=3BDIV>=3B<=3BFONT class=3D3DEC_EC_EC_Apple-style-span face=3D=> >3DGillSans-Light>=3B<=3BSPAN cl=3D
>=3B >=3Bass=3D3DEC_EC_EC_App=> >le-style-span style=3D3D"FONT-FAMILY: GillSans-Light">=3B305 N=3D
>=> >=3B >=3B. University Street | West Lafayette | IN 47907 | USA<=3B/SPAN&=> >gt=3B<=3B/FONT>=3B<=3B/DIV>=3B
>=3B >=3B<=3BDIV>=3B<=> >=3BFONT class=3D3DEC_EC_EC_Apple-style-span face=3D3D"Gill Sans" color=3D3D=> >#00=3D
>=3B >=3B00ff>=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-=> >span style=3D3D"COLOR: rgb(0=3D2C0=3D2C25=3D
>=3B >=3B5)=3D3B FONT-F=> >AMILY: 'Gill Sans'">=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-span sty=> >=3D
>=3B >=3Ble=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=3D3B FONT-FAMILY: '=> >Gill Sans'">=3BOffice<=3B/SPAN>=3B<=3B/S=3D
>=3B >=3BPAN>=> >=3B<=3B/FONT>=3B<=3BFONT class=3D3DEC_EC_EC_Apple-style-span face=3D3=> >DGillSans-Light>=3B<=3BS=3D
>=3B >=3BPAN class=3D3DEC_EC_EC_Appl=> >e-style-span style=3D3D"FONT-FAMILY: GillSans-Light"=3D
>=3B >=3B>=> >=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-span style=3D3D"FONT-FAMILY: G=> >illSans-Lig=3D
>=3B >=3Bht">=3B&=3Bnbsp=3D3B+1 765 494 6001 |&l=> >t=3BSPAN class=3D3DEC_EC_Apple-converted-space>=3B&=3Bnbs=3D
>=3B=> > >=3Bp=3D3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/FONT=> >>=3B<=3BFONT class=3D3DEC_EC_EC_Apple-style-span fac=3D
>=3B >=> >=3Be=3D3D"Gill Sans" color=3D3D#0000ff>=3B<=3BSPAN class=3D3DEC_EC_EC_A=> >pple-style-span sty=3D
>=3B >=3Ble=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=> >=3D3B FONT-FAMILY: 'Gill Sans'">=3B<=3BSPAN class=3D3DEC=3D
>=3B &=> >gt=3B_EC_EC_Apple-style-span style=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=3D3B FO=> >NT-FAMILY: 'G=3D
>=3B >=3Bill Sans'">=3BMobile<=3B/SPAN>=3B<=> >=3B/SPAN>=3B<=3B/FONT>=3B<=3BFONT class=3D3DEC_EC_EC_Apple-style-sp=> >=3D
>=3B >=3Ban face=3D3DGillSans-Light>=3B<=3BSPAN class=3D3DEC=> >_EC_EC_Apple-style-span style=3D3D"F=3D
>=3B >=3BONT-FAMILY: GillSan=> >s-Light">=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-span style=3D
&g=> >t=3B >=3B=3D3D"FONT-FAMILY: GillSans-Light">=3B<=3BSPAN class=3D3DEC_=> >EC_Apple-converted-space>=3B=3D
>=3B >=3B&=3Bnbsp=3D3B<=3B/SP=> >AN>=3B+1 765 427 5484<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/FONT>=3B&=> >lt=3B/DIV>=3B
>=3B >=3B<=3BDIV>=3B<=3BFONT class=3D3DEC_EC_E=> >C_Apple-style-span face=3D3DGillSans-Light>=3B<=3BBR clas=3D
>=3B => >>=3Bs=3D3DEC_EC_EC_khtml-block-placeholder>=3B<=3B/FONT>=3B<=3B/D=> >IV>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SP=3D
=> >>=3B >=3BAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=> >=3BBR class=3D3DEC_EC_EC_Apple-interchange-newline>=3B<=3B/SP=3D
>=> >=3B >=3BAN>=3B<=3B/DIV>=3B<=3B/SPAN>=3B<=3B/DIV>=3B<=3BBR=> >>=3B
>=3B >=3B<=3BDIV>=3B
>=3B >=3B<=3BDIV>=3BOn 12=> > Jan 2009=3D2C at 01:44=3D2C Jay wrote:<=3B/DIV>=3B<=3BBR class=3D3DE=> >C_EC_EC_App=3D
>=3B >=3Ble-interchange-newline>=3B
>=3B >=> >=3B<=3BBLOCKQUOTE>=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-span sty=> >le=3D3D"WORD-SPACING: =3D
>=3B >=3B0px=3D3B FONT: 12px Helvetica=3D3=> >B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0=3D
>=3B >=3B)=> >=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=> >=3D3B B=3D
>=3B >=3BORDER-COLLAPSE: separate">=3B
>=3B >=3B=> ><=3BDIV class=3D3DEC_EC_EC_hmmessage style=3D3D"FONT-SIZE: 10pt=3D3B FONT=> >-FAMILY: Ve=3D
>=3B >=3Brdana">=3BIs there a way in Modula-3 to de=> >clare that&=3Bnbsp=3D3Ba type exists=3D2C a=3D
>=3B >=3Bnd there => >are &=3Blt=3D3B*external*&=3Bgt=3D3B instances of it=3D2C without "fu=> >lly" decl=3D
>=3B >=3Baring it=3D2C so that no Modula-3 can instanti=> >ate it?<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3BI have d=3D
>=3B &g=> >t=3Bone this for sigset_t and sem_t=3D2C but they could erroneously be inst=> >antiat=3D
>=3B >=3Bed by Modula-3 and I'd like to remove that abilit=> >y to mess up so easily.<=3BBR=3D
>=3B >=3B>=3B&=3Bnbsp=3D3B&l=> >t=3BBR>=3B(* This type is not declared correctly. It is only instantiate=> >=3D
>=3B >=3Bd in C code. *)<=3BBR>=3B&=3Bnbsp=3D3B sigset_t => >=3D3D RECORD END=3D3B<=3BBR>=3B<=3BBR>=3B(* This type =3D
>=3B=> > >=3Bis not declared correctly. It is only instantiated in C code. *)<=> >=3BBR>=3B&=3Bnbsp=3D
>=3B >=3B=3D3B sem_t =3D3D RECORD END=3D3B=> ><=3BBR>=3B<=3BBR>=3BIn C I believe you can do this=3D2C like:<=3B=> >=3D
>=3B >=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3Btypedef struct => >foo foo_t=3D3B&=3Bnbsp=3D3B<=3BSPAN class=3D3DEC_EC_E=3D
>=3B >=> >=3BC_Apple-converted-space>=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BBR&g=> >t=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3Bextern foo_t foo=3D
>=3B >=3B=3D=> >3B&=3Bnbsp=3D3B<=3BSPAN class=3D3DEC_EC_EC_Apple-converted-space>=3B=> >&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BBR>=3B=3D
>=3B >=3B&=3Bn=> >bsp=3D3B<=3BBR>=3B&=3Bnbsp=3D3Bvoid UseFoo(foo_t*)=3D3B<=3BSPAN cl=> >ass=3D3DEC_EC_EC_Apple-conv=3D
>=3B >=3Berted-space>=3B&=3Bnbsp=> >=3D3B<=3B/SPAN>=3B<=3BBR>=3B&=3Bnbsp=3D3B foo_t* GetFoo(void)=3D=> >3B<=3BSPAN class=3D
>=3B >=3B=3D3DEC_EC_EC_Apple-converted-space&g=> >t=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR=> >>=3BThanks=3D2C<=3B=3D
>=3B >=3BBR>=3B&=3Bnbsp=3D3B- Jay<=> >=3BBR>=3B<=3BBR>=3B<=3BBR>=3B<=3BBR>=3B<=3B/DIV>=3B<=3B=> >/SPAN>=3B<=3B/BLOCKQUOTE>=3B<=3B/DIV>=3B<=3BBR>=3B<=3B/DIV&=> >gt=3B<=3B=3D
>=3B >=3B/DIV>=3B<=3B/SPAN>=3B<=3BBR class=3D=> >3DEC_EC_Apple-interchange-newline>=3B<=3B/BLOCKQUOTE>=3B<=3B/DIV>=> >=3B=3D
>=3B >=3B<=3BBR>=3B<=3B/DIV>=3B<=3B/SPAN>=3B<=> >=3BBR class=3D3DEC_Apple-interchange-newline>=3B<=3B/BLOCKQUOTE>=3B&l=> >t=3B/DI=3D
>=3B >=3BV>=3B<=3BBR>=3B<=3B/body>=3B
>=3B=> > >=3B<=3B/html>=3B=3D
>=3B >=3B
>=3B >=3B--_6117a048-91=> >85-4c03-badb-ef8f93402268_--

> >=> >> >--_2e194b09-14b6-4301-9116-a9e4d1e522b4_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 12:45:23 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 11:45:23 +0000 Subject: [M3devel] map/def files to limit exports to only functions in interfaces Message-ID: On Windows, a "def" file lists extra linker parameters, mainly a list of functions to export. On most Posix systems, a "map" serves the same purpose. On Windows, a "map" file is actually a linker output, that is roughly, a text file with some symbol information. On Windows, the default set of functions to export is empty. You can either decorate your source code with __declspec(dllexport), or write a .def file. Some build systems -- including cm3 -- grovel .obj files and put every symbol in the .def file. Typical Unix behavior is to export all symbols. More so, typical Unix behavior is to try to make "shared objects" very much like "objects". In particular, to treat all the shared objects within a process as containing one global/pooled namespace. Therefore, the first shared object loaded that exports a function named "open", is the target of any unresolved links to the symbol "open". This is a feature. It lets folks "interpose" and/or "preload" their own special shared object that implements whatever function in its own special way. Such dynamic resolution occurs by default for all non-static symbols. I'm not sure how it works out, but two shared objects might contain a function foo, that they each call, expecting to their own, but as I understand, they might both call the first loaded one. You can control linking presumably by declaring functions static, but that doesn't work if you have multiple source files in your shared object and want to call between them. There are some details I am uncertain of, to be sure. > This is a feature.. But, I believe it is more broadly understood to be a mistake. At some early point, like around 10.2, Apple changed from a "flat namespace" to "two level namespace". That is, when I link, on the development machine, "open" was found in e.g. "libc.so", so in my foo.exe, not just the symbol "open" is recorded, but "libc" is associated with it. So at load time, "open" is not looked at in all shared objects, but only in "libc" (could there be more than one, in different directories, I don't know). Is this just a "hint" or it "must be so"? I'm not sure. Solaris linker man pages give the "export everything" as the historical default, but not the recommended practise. There is a paper by the Linux ld.so maintainer -- Ulrich Drepper -- with advise I believe compatible with my thinking. Limit exports to only what you intend. Bind symbols locally that you implement. Don't leave all symbols "interposable", only ones you intend to import from somewhere else. When I was debugging AMD64_LINUX months ago, I found that even nested functions were exported and interposable, and the delayed resolution of them trashed the static link. So at the time I changed just their behavior. There is new syntax and command line flags to gcc to control what they call "visibility". Historical default, everything is visible/exported. Current guidance is, switch the default to not exported, and "decorate" source code with "__attribute__" or a wrapper macro thereof. SO...... Today we export "every" function -- including functions not defined in an .i3 file. This is inefficient. I strongly propose that we generate "def" files for Win32 and "map" files for "everyone else" (being sure to read up on the Solaris linker, GNU linker, BSD linkers, and later Irix, AIX, HP-UX, OSF, etc.) that list only functions in .i3 files, and the module_m3 and/or _i3 symbols, whatever is needed. I've already done some initial investigation here. It is doable in the front end but I believe m3linker is the right place. The front end visits interface/module at a time, whereas this work needs to be done once per "package" or "library", and cannot really be done incrementally, and it is small anyway. We don't need signatures, just lists of functions (and, on some systems..variables) in interfaces. Actually, I think this work could lead to "fixing data imports on Win32", but that's another subject and it is likely avoidable (you would change all cross-interface variable references to go through pointers, in case they are imported, then linker can synthesize the pointers if ends up not imported, kind of backwards from the way importing functions where, where the default is a direct call and linker can synthesize thunks for imports). Reasonable? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 15:05:34 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 14:05:34 +0000 Subject: [M3devel] a note on user thread -- *context not 'universal' Message-ID: just a note, that make/get/set/swapcontext are not available on Darwin (10.4) and OpenBSD.I didn't check NetBSD. It is on Linux, Solaris, FreeBSD. A "dual" approach where some ports use setjmp/longjmp, some use *context, probably reasonable. Another approach that would probably work is you double up the jmpbuf.Always make a copy before setjmp and setjmp to the copy.That way if longjmp "scrambles" it, no matter.If you can't even copy them, well, setjmp to the "original", copy it away, and thenrecopy before any setjmp. However, this is inefficient and using *context is probably better, where it is available. question: On Windows, you can "reserve" virtual memory, and "commit" it."reserve" is allocating just the address space."commit" I think is ensuring there is room in a pagefile.Reserve is cheaper. You can overrreserve but I guess not long-term overcommit.Usually stacks are only ever at first reserved, and then commited gradually,like a page at a time. Whatever *context documentation I could find, didn't talk about this.They either used a local char array, or a called mmap.On at least some platforms, there a flag to mmap to indicate you are creating a stack. Do we really need the assembly _fpsetjmp? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Jan 12 15:30:20 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 12 Jan 2009 15:30:20 +0100 Subject: [M3devel] a note on user thread -- *context not 'universal' In-Reply-To: References: Message-ID: <20090112153020.qff8fc7eioc8kocs@mail.elegosoft.com> Quoting Jay : > Do we really need the assembly _fpsetjmp? IIRC, I introduced fpsetjmp/fplongjmp when I made the first FreeBSD code, as FreeBSD does not care about storing the floating point state, and spurious FP errors occured when switching threads by longjmp. I think Bruce Evans contributed the FreeBSD assembler code. It may be that Darwin, which is derived from FreeBSD in certain areas, has inherited this problem (I don't remember offhand, and I haven't done much BSD or M3 programming in recent months). I think no other systems needed to use specially crafted setjmp/longjmp pairs to accomodate the M3 user threads. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Mon Jan 12 22:04:02 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 13 Jan 2009 08:04:02 +1100 Subject: [M3devel] a note on user thread -- *context not 'universal' In-Reply-To: <20090112153020.qff8fc7eioc8kocs@mail.elegosoft.com> References: <20090112153020.qff8fc7eioc8kocs@mail.elegosoft.com> Message-ID: <9C37CD59-A42F-4B4F-BE9D-2295817B1C71@cs.purdue.edu> makecontext/getcontext/setcontext and friends are both available on Darwin and should do FP state properly. On 13 Jan 2009, at 01:30, Olaf Wagner wrote: > Quoting Jay : > >> Do we really need the assembly _fpsetjmp? > > IIRC, I introduced fpsetjmp/fplongjmp when I made the first FreeBSD > code, > as FreeBSD does not care about storing the floating point state, > and spurious FP errors occured when switching threads by longjmp. > I think Bruce Evans contributed the FreeBSD assembler code. > > It may be that Darwin, which is derived from FreeBSD in certain areas, > has inherited this problem (I don't remember offhand, and I haven't > done much BSD or M3 programming in recent months). I think no other > systems needed to use specially crafted setjmp/longjmp pairs to > accomodate the M3 user threads. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hosking at cs.purdue.edu Mon Jan 12 22:01:33 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 13 Jan 2009 08:01:33 +1100 Subject: [M3devel] a note on user thread -- *context not 'universal' In-Reply-To: References: Message-ID: <19C99B21-4997-4ABB-8BD2-4992FD0513AE@cs.purdue.edu> They *are* available on Darwin 10.5 and I am pretty sure they were there on 10.4. Have you installed the developer kit (with man pages)? On 13 Jan 2009, at 01:05, Jay wrote: > just a note, that make/get/set/swapcontext are not available on > Darwin (10.4) and OpenBSD. > I didn't check NetBSD. It is on Linux, Solaris, FreeBSD. > > > A "dual" approach where some ports use setjmp/longjmp, some use > *context, probably reasonable. > > > Another approach that would probably work is you double up the jmpbuf. > Always make a copy before setjmp and setjmp to the copy. > That way if longjmp "scrambles" it, no matter. > If you can't even copy them, well, setjmp to the "original", copy it > away, and then > recopy before any setjmp. > > > However, this is inefficient and using *context is probably better, > where it is available. > > > question: > > > On Windows, you can "reserve" virtual memory, and "commit" it. > "reserve" is allocating just the address space. > "commit" I think is ensuring there is room in a pagefile. > Reserve is cheaper. You can overrreserve but I guess not long-term > overcommit. > Usually stacks are only ever at first reserved, and then commited > gradually, > like a page at a time. > > > Whatever *context documentation I could find, didn't talk about this. > They either used a local char array, or a called mmap. > On at least some platforms, there a flag to mmap to indicate you are > creating a stack. > > > Do we really need the assembly _fpsetjmp? > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 23:20:24 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 22:20:24 +0000 Subject: [M3devel] a note on user thread -- *context not 'universal' In-Reply-To: <19C99B21-4997-4ABB-8BD2-4992FD0513AE@cs.purdue.edu> References: <19C99B21-4997-4ABB-8BD2-4992FD0513AE@cs.purdue.edu> Message-ID: They really don't seem to be there, on 10.4. I haven't check the libs yet but they are not in the headers or man pages. Do you have installed the "multiple SDKs" (headers/libs for multiple OS versions)? Look at in /Developer/SDKs. Anyway, they also aren't on OpenBSD so a dual approach will be needed which I think is ok. Heck, probably one set of Modula-3 but #ifdefed C. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Tue, 13 Jan 2009 08:01:33 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] a note on user thread -- *context not 'universal' They *are* available on Darwin 10.5 and I am pretty sure they were there on 10.4. Have you installed the developer kit (with man pages)? On 13 Jan 2009, at 01:05, Jay wrote: just a note, that make/get/set/swapcontext are not available on Darwin (10.4) and OpenBSD.I didn't check NetBSD. It is on Linux, Solaris, FreeBSD. A "dual" approach where some ports use setjmp/longjmp, some use *context, probably reasonable. Another approach that would probably work is you double up the jmpbuf.Always make a copy before setjmp and setjmp to the copy.That way if longjmp "scrambles" it, no matter.If you can't even copy them, well, setjmp to the "original", copy it away, and thenrecopy before any setjmp. However, this is inefficient and using *context is probably better, where it is available. question: On Windows, you can "reserve" virtual memory, and "commit" it."reserve" is allocating just the address space."commit" I think is ensuring there is room in a pagefile.Reserve is cheaper. You can overrreserve but I guess not long-term overcommit.Usually stacks are only ever at first reserved, and then commited gradually,like a page at a time. Whatever *context documentation I could find, didn't talk about this.They either used a local char array, or a called mmap.On at least some platforms, there a flag to mmap to indicate you are creating a stack. Do we really need the assembly _fpsetjmp? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 23:39:01 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 22:39:01 +0000 Subject: [M3devel] cygwin/pthread still broken fyi Message-ID: Just fyi, I tried cygwin with pthreads and it crashes in "startup" (well, it gets as far as sysutils entry which is pretty far) Switched back to Wni32 threads, no crash. I will debug more later. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Jan 13 00:23:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 13 Jan 2009 10:23:36 +1100 Subject: [M3devel] a note on user thread -- *context not 'universal' In-Reply-To: References: <19C99B21-4997-4ABB-8BD2-4992FD0513AE@cs.purdue.edu> Message-ID: <8FA8E456-79FB-40CE-A7CA-D53DE0E88980@cs.purdue.edu> Hmm, weird -- I am sure I looked at that a long time back. On 13 Jan 2009, at 09:20, Jay wrote: > They really don't seem to be there, on 10.4. > I haven't check the libs yet but they are not in the headers or man > pages. > Do you have installed the "multiple SDKs" (headers/libs for multiple > OS versions)? > Look at in /Developer/SDKs. > Anyway, they also aren't on OpenBSD so a dual approach will be needed > which I think is ok. > Heck, probably one set of Modula-3 but #ifdefed C. > > - Jay > > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 13 Jan 2009 08:01:33 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] a note on user thread -- *context not > 'universal' > > > They *are* available on Darwin 10.5 and I am pretty sure they were > there on 10.4. Have you installed the developer kit (with man pages)? > > On 13 Jan 2009, at 01:05, Jay wrote: > > just a note, that make/get/set/swapcontext are not available on > Darwin (10.4) and OpenBSD. > I didn't check NetBSD. It is on Linux, Solaris, FreeBSD. > > > A "dual" approach where some ports use setjmp/longjmp, some use > *context, probably reasonable. > > > Another approach that would probably work is you double up the jmpbuf. > Always make a copy before setjmp and setjmp to the copy. > That way if longjmp "scrambles" it, no matter. > If you can't even copy them, well, setjmp to the "original", copy it > away, and then > recopy before any setjmp. > > > However, this is inefficient and using *context is probably better, > where it is available. > > > question: > > > On Windows, you can "reserve" virtual memory, and "commit" it. > "reserve" is allocating just the address space. > "commit" I think is ensuring there is room in a pagefile. > Reserve is cheaper. You can overrreserve but I guess not long-term > overcommit. > Usually stacks are only ever at first reserved, and then commited > gradually, > like a page at a time. > > > Whatever *context documentation I could find, didn't talk about this. > They either used a local char array, or a called mmap. > On at least some platforms, there a flag to mmap to indicate you are > creating a stack. > > > Do we really need the assembly _fpsetjmp? > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eiserlohpp at yahoo.com Tue Jan 13 08:31:27 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Mon, 12 Jan 2009 23:31:27 -0800 (PST) Subject: [M3devel] dynamic chose between user/kernel threads? Message-ID: <486480.21981.qm@web56801.mail.re3.yahoo.com> >> [Jay] Some programs "better" with user threads >> [Tony] Is this still true for modern kernel thread systems? > >I really don't know. >Olaf /kind of/ indicated so (just in saying that it'd be a nice option to have). > >> [Jay] small stacks for many threads vs. larger stacks for calls to "the system" >> [Tony] In a systems programming language like Modula-3 shouldn't threads have a relationship to the system? >> Is it a boolean or an enum? >> Cygwin might conceivably get pthreads support (Cygwin has it, but >> Modula-3/Cygwin does not). >> Therefore, is the choice among "posix" threads, "pthreads" and "NT" >> threads? >> Or just user vs. kernel? > >I would argue for user vs. kernel. Correct me if I am wrong, but don't user threads all run in the same process, and therefore, can't make use of multi-processors (ie, SMP machines). Many people now even have dual core machines, or even quad core, let alone motherboards with many processors on them. At least with Linux, the old system thread library (I forgot its name, it been a number of years) used user level threads. Then Linus invented the clone() system call, which acted similarly to a fork(), but kept the same virtual memory and file contexts. This allowed threads to act like processes, and migrate to other processors of an SMP machine. This is what the Linux implementation of the pthread library currently uses, to take advantage of modern machine architectures. This is a kernel thread under Linux. This should be significant reason for prefering the pthread threading library, and should probably be the default. Default to "kernel" theads. Allow "user" threads. Don't make it a binary choice. If a port wants to make available a third (or fourth) threading option they should be able to do so. Just don't expect many people to jump up and down for joy. If a platform does not support kernel threads, (eg, PalmOS) uh ... (what we don't support it yet), then only support user threads. If a port were to be built that ran on bare hardware (such as the "SPIN" OS) they would have to implement their own thread mechanism, and must not include any support for a thread library which expects to be in user space with a kernel providing OS support. BTW: I think putting IF statements in all the threading code looks ugly. Couldn't you implement it as an OBJECT ThreadMechanism, and derive the specific mechanisms: ThreadUserMechanism, ThreadPThreadMechanism, ThreadWinNTMechanism, ThreadDoItYourselfMechanism. The startup code would choose which one to instantiate. All thread and mutex calls would use that object to perform its action. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Tue Jan 13 09:19:17 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 13 Jan 2009 08:19:17 +0000 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: <486480.21981.qm@web56801.mail.re3.yahoo.com> References: <486480.21981.qm@web56801.mail.re3.yahoo.com> Message-ID: > Terminology wrong, but your point is correct. A "process" is an "address space" and isolation boundary for security. A thread is a unit of scheduling, a stack and register context. "Straightforward" user threads indeed, you would only ever run one at a time, per process, even on a multi threaded systems. People speak of N:M 1:1 or N:1 One number is number of user threads. The other is kernel threads. You can have a hybrid where some number of user threads are scheduled on some smaller number of kernel threads. You can have one to one. You can have one kernel thread (e.g. on a system without kernel threads-- just processes) that you use to run multiple user threads. Historically N:1 was the only option. Then some people moved to N:M. Such as older releases of Solaris. These days almost everything is 1:1. However some people still don't think this is clearly and always best. And on rare occasion, perhaps it is not. N:M is an interesting hybrid, it gives user threads a chance to scale on a multiprocessor. But it is probably the most difficult to implement. If you read near the beginning of the 2nd edition of "Solaris Internals" they talk about some of this, and how Solaris 10 (9?) improved things by making it all "1:1". I consider user threads extremely uninteresting but folks here are vocally interested in them. And right there are systems without kernel threads. Like, I've been thinking of making a I386_MSDOS_DJGPP or such release. It appears to have sufficient support for the user threads -- alarm(). > IF looks ugly. Couldn't you implement it as an OBJECT I said function pointers at one point. Same thing. If it was IF, it'd be an extra layer outside all of the "real" code and so wouldn't be ugly at all. But maybe slower. Something I've been meaning to ask. The old Linux library was "LinuxThreads". "NPTL" is the Native PThread Library. Modula-3 only seemed to switch to pthreads with NPTL widely available. But I assume the pthreads interface was implemented over LinuxThreads? Couldn't Modula-3 have used that, earlier? That is, couldn't Modula-3 using pthreads claim to work to older versions?There's a comment in thread/m3makefile that suggests NPTL is required. I guess it is moot. NPTL is here and nobody probably runs the older stuff?? (I ran Modula-3/LINUXELF briefly on 1.2. Imho binary compatibility mandates that it should still work... certainly I continue to use Windows software from the same time period every day.) - Jay> Date: Mon, 12 Jan 2009 23:31:27 -0800> From: eiserlohpp at yahoo.com> To: m3devel at elegosoft.com> Subject: [M3devel] dynamic chose between user/kernel threads?> > >> [Jay] Some programs "better" with user threads> >> [Tony] Is this still true for modern kernel thread systems?> >> >I really don't know.> >Olaf /kind of/ indicated so (just in saying that it'd be a nice option to have).> >> >> [Jay] small stacks for many threads vs. larger stacks for calls to "the system"> >> [Tony] In a systems programming language like Modula-3 shouldn't threads have a relationship to the system?> > > >> Is it a boolean or an enum?> >> Cygwin might conceivably get pthreads support (Cygwin has it, but > >> Modula-3/Cygwin does not).> >> Therefore, is the choice among "posix" threads, "pthreads" and "NT" > >> threads?> >> Or just user vs. kernel?> >> >I would argue for user vs. kernel.> > > Correct me if I am wrong, but don't user threads all run> in the same process, and therefore, can't make use of> multi-processors (ie, SMP machines). Many people now even> have dual core machines, or even quad core, let alone > motherboards with many processors on them.> > At least with Linux, the old system thread library (I> forgot its name, it been a number of years) used user> level threads. Then Linus invented the clone() system> call, which acted similarly to a fork(), but kept the> same virtual memory and file contexts. This allowed> threads to act like processes, and migrate to other> processors of an SMP machine.> > This is what the Linux implementation of the pthread> library currently uses, to take advantage of modern> machine architectures. This is a kernel thread under> Linux.> > This should be significant reason for prefering the pthread> threading library, and should probably be the default.> > Default to "kernel" theads. Allow "user" threads. Don't> make it a binary choice. If a port wants to make available> a third (or fourth) threading option they should be able> to do so. Just don't expect many people to jump up and> down for joy.> > If a platform does not support kernel threads, (eg, PalmOS)> uh ... (what we don't support it yet), then only support> user threads. > > If a port were to be built that ran on bare hardware (such> as the "SPIN" OS) they would have to implement their own> thread mechanism, and must not include any support for a> thread library which expects to be in user space with a> kernel providing OS support.> > BTW: I think putting IF statements in all the threading> code looks ugly. Couldn't you implement it as an OBJECT> ThreadMechanism, and derive the specific mechanisms:> ThreadUserMechanism, > ThreadPThreadMechanism, > ThreadWinNTMechanism,> ThreadDoItYourselfMechanism.> > The startup code would choose which one to instantiate.> All thread and mutex calls would use that object to > perform its action.> > > +--------------------------------------------------------+> | Peter P. Eiserloh |> +--------------------------------------------------------+> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jan 13 15:54:38 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 13 Jan 2009 14:54:38 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: > fix for old compilers that can't compile LONGINT: define LongRep.T = INTEGER Is that what bootstrapping should do? Automate that little patch for the first pass and undo it in the second? Then always building in dependency order? Tonight I was trying to build from PPC_DARWIN 5.5.0. I figured, heck, maybe it supports LONGINT already, maybe I should just try building up in dependency order. But then I hit the problem of Compiler.i3 mismatch due to new targets. So...is that correct? Does building in dependency order predictably fail if compiler has fewer targets than runtime? But starting with existing m3core/libm3 and first building the compiler against them predictably works? I've added targets a bunch and usually don't have a problem, but I can't say for certain what order I do things when I do this. Certainly "upgrade.py skipgcc" is something I run fairly often. It is very fast on NT386 (and unlike upgrade.sh, it doesn't build all of std). For now I put in two small hacks to sysutils, so it works with old m3core. I was stuck otherwise. The hacks are: - assume kernel threads or "single threaded" That is -- always pass 0 for the waitpid option. If sysutils client is multithreaded (always the case), and parent threads depend on child processes (not always the case), and user threads (really not always the case), then there risk of deadlock. - if status is non zero but lower 8 bits are zero, set it to 1, to ensure non-zero in lower bits This could be done correctly by copying the current Uexec code into sysutils. Maybe Compiler.i3 can somehow be implemented to "just work"? And eliminate the redundancy as well? Have the compiler inject its definition into m3core/libm3? - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Mon, 12 Jan 2009 19:22:13 +1100 CC: jkrell at elego.de; m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 I think there is a straightforward fix for old compilers that can't compile LONGINT: define LongRep.T = INTEGER. Most everything should compile from there. That's what I recall doing to upgrade my compiler to handle LONGINT. LONGINT is not used anywhere else in m3core, so nothing depends on it working. On 12 Jan 2009, at 19:02, Jay wrote:If old compiler can't build m3core, such as if old compiler predates LONGINT. You already know this. Are we "past" such compilers? - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Mon, 12 Jan 2009 18:51:08 +1100 CC: jkrell at elego.de; m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Why do you not build in the following order to get a new compiler? (You may need to downgrade Compiler.tmpl for use with an old compiler so that you don't get a mismatch between m3core and libm3, but otherwise the following sequence should work). m3corelibm3sysutilsm3middlem3objfilem3linkerm3backm3frontm3quakecm3 On 12 Jan 2009, at 18:25, Jay wrote:The compiler uses sysutils. The first pass builds against an old package store, which might not have sysutils at all, if it is that old. Again, once new m3core is around, no problem. I could/should have put in the m3core change and just waited on the sysutils change, rather than go ahead and do the quake stuff, and we can do that now (or your change that moots it, which I haven't looked into yet). I was browsing the docs and it appears there is an "import_pkg" directive for like, copying in a package contents, instead of linking. That might also solve this. I found that relatively late and never looked into it. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Mon, 12 Jan 2009 18:19:55 +1100 CC: jkrell at elego.de; m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Not true. sysutils should be built against the m3core with which it will be linked. I don't think this is correct. On 12 Jan 2009, at 17:58, Jay wrote:To bootstrap I believe. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Mon, 12 Jan 2009 17:53:02 +1100 CC: jkrell at elego.de; m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Why does sysutils need to be compatible with both old and new versions of m3core? On 12 Jan 2009, at 17:39, Jay wrote:ThreadPosix is basically unaffected -- I never provided user threads on Cygwin. I guess it got a slight reduction regarding DoesWaitPidYield, but its SchedulerPosix implementation was unchanged. The code in ThreadPosix is similar to but different than ThreadPThread. It is possible they could be merged but it wasn't trivial so I left ThreadPosix alone. > You are smearing implementation details across multiple files and directories You really think it is bad to have SchedulerPosix implemented in a small separate file? On top of what happens to be common implementation details of ThreadPThread.m3 and ThreadWin32.m3? ThreadPScheduler.m3 is just basically three functions: IOWait, IOAlertWait, XIOWait Plus the little internal utility, UTimeFromTime, the one liner DoesWaitPidYield, and non-trivial functions nested in XIOWait: TestFDS, CallSelect. I mean, you know, an alternative is to copy out very large chunks of ThreadWin32.m3 and ThreadPThread.m3 and merge them into ThreadCygwin.m3. That would be worse imho. "Directories" hardly. Or I can try debugging cygwin pthreads again. - Jay CC: jkrell at elego.de; m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Date: Mon, 12 Jan 2009 12:46:54 +1100 You are smearing implementation details across multiple files and directories. Up until now, ThreadPThread has been nicely self-contained, and captured all the basic pieces of the thread implementation. Also, how does all of this fit with the ThreadPosix implementation? On 12 Jan 2009, at 12:19, Jay wrote:btw, I don't think it's that hairy, I merely split it into two or three files, and added interfaces so they can reuse code with each other. Movement between files is hard to track though (depending on version control, but with all I've used). The SchedulerPosix implementation moved to ThreadPScheduler.m3. What is shared between it and ThreadPThread/Win32.m3 is ThreadInternal.i3, which maybe should be in ThreadF.i3, though that's exposed outside m3core, and ThreadInternal.i3 includes a variable. I can try again to debug Cygwin pthreads though. - Jay > From: hosking at cs.purdue.edu > To: jkrell at elego.de > Date: Mon, 12 Jan 2009 11:03:33 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Jay, > > Can you remind me again why Cygwin was unable to use pthreads? It > seems you have introduced a bunch of hair into the PTHREADS > implementation to deal with broken Cygwin pthreads. As many of us > have already pointed out, Cygwin should be a port that tries as much > as possible to be like a standard POSIX platform (pthread-based) as > opposed to a weird Windows/POSIX hybrid. > > I have a bunch of code that will be going into the PTHREADS base that > I am now at a loss to integrate with the changes you have made. > > Help! > > -- Tony > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Jan 13 16:06:21 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 13 Jan 2009 16:06:21 +0100 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: References: <486480.21981.qm@web56801.mail.re3.yahoo.com> Message-ID: <20090113160621.07cnshm5cgc0s0w8@mail.elegosoft.com> If I remember correctly, until Antony Hosking provided the PThreads implementation, M3 only used its own user-level threads on all POSIX platforms (but not on Windows). The ability to use system pthread libraries has been added rather late. (M3's) user level threads are extremely fast and use little resources (configurable stack sizes). External system threads have a little more overhead due to the extra user/kernel mode switches for all scheduling related activies. They have got the advantage that they can be used for scaling across multiple processors (which wasn't possible with M3 on Unix until recently). I agree that these days kernel threads should be the default, as they are available on almost every system and usually reasonably stable and fast (which was not so when M3 was created). Nonetheless M3's user level threads can have advantages for certain uses and should not be discarded, as they have proven to be mature and useful. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Jan 13 16:08:45 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 13 Jan 2009 16:08:45 +0100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: <20090113160845.y5ucq4et28o484cs@mail.elegosoft.com> Quoting Jay : > > > fix for old compilers that can't compile LONGINT: define > LongRep.T = INTEGER > > Is that what bootstrapping should do? > Automate that little patch for the first pass and undo it in the second? > Then always building in dependency order? > > > Tonight I was trying to build from PPC_DARWIN 5.5.0. > I figured, heck, maybe it supports LONGINT already, maybe I should just try > building up in dependency order. > But then I hit the problem of Compiler.i3 mismatch due to new targets. > > > So...is that correct? > Does building in dependency order predictably fail if compiler has > fewer targets than runtime? > But starting with existing m3core/libm3 and first building the > compiler against them predictably works? As far as I remember it has always been this way with (C)M3. Runtime and compiler must agree wrt. target platforms. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Jan 13 19:45:43 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 13 Jan 2009 18:45:43 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20090113160845.y5ucq4et28o484cs@mail.elegosoft.com> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> <20090113160845.y5ucq4et28o484cs@mail.elegosoft.com> Message-ID: > As far as I remember it has always been this way with (C)M3.> Runtime and compiler must agree wrt. target platforms.> > Olaf I /think/ they can disagree, as long as you don't build the runtime. That is, when you add new platforms, you build the updated compiler first, against an old runtime, then build the updated runtime. I'm just speculating though based on my being stuck last night trying to build m3core first, vs. that I often build the compiler first. I also wonder if it must be this way -- if the compiler can't inject into the runtime its list of targets. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 14 00:11:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 14 Jan 2009 10:11:36 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: On 14 Jan 2009, at 01:54, Jay wrote: > > fix for old compilers that can't compile LONGINT: define > LongRep.T = INTEGER > > Is that what bootstrapping should do? > Automate that little patch for the first pass and undo it in the > second? > Then always building in dependency order? I would prefer to get all the bootstrap archives LONGINT-capable. Just do the patch by hand to build the initial archives and then forget about it. > Tonight I was trying to build from PPC_DARWIN 5.5.0. > I figured, heck, maybe it supports LONGINT already, maybe I should > just try > building up in dependency order. > But then I hit the problem of Compiler.i3 mismatch due to new targets. > So...is that correct? > Does building in dependency order predictably fail if compiler has > fewer targets than runtime? > But starting with existing m3core/libm3 and first building the > compiler against them predictably works? Yes, it works. > I've added targets a bunch and usually don't have a problem, but I > can't say for certain what > order I do things when I do this. > Certainly "upgrade.py skipgcc" is something I run fairly often. > It is very fast on NT386 (and unlike upgrade.sh, it doesn't build > all of std). Sounds like your upgrade script > For now I put in two small hacks to sysutils, so it works with old > m3core. No! I did not want to do have this hack. Let's just fix the boot archives to handle new m3core and have sysutils work as expected. The alternative is to fold sysutils into m3core, where it can be used directly. That might be a better solution given the dependency. Thoughts? > I was stuck otherwise. > > > The hacks are: > - assume kernel threads or "single threaded" > That is -- always pass 0 for the waitpid option. > If sysutils client is multithreaded (always the case), > and parent threads depend on child processes (not always the > case), > and user threads (really not always the case), > then there risk of deadlock. > > - if status is non zero but lower 8 bits are zero, set it to 1, to > ensure non-zero in lower bits > This could be done correctly by copying the current Uexec code > into sysutils. > > > Maybe Compiler.i3 can somehow be implemented to "just work"? > And eliminate the redundancy as well? > Have the compiler inject its definition into m3core/libm3? > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 19:22:13 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > I think there is a straightforward fix for old compilers that can't > compile LONGINT: define LongRep.T = INTEGER. Most everything should > compile from there. That's what I recall doing to upgrade my > compiler to handle LONGINT. LONGINT is not used anywhere else in > m3core, so nothing depends on it working. > > On 12 Jan 2009, at 19:02, Jay wrote: > > If old compiler can't build m3core, such as if old compiler predates > LONGINT. > You already know this. > Are we "past" such compilers? > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 18:51:08 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > Why do you not build in the following order to get a new compiler? > (You may need to downgrade Compiler.tmpl for use with an old > compiler so that you don't get a mismatch between m3core and libm3, > but otherwise the following sequence should work). > > m3core > libm3 > sysutils > m3middle > m3objfile > m3linker > m3back > m3front > m3quake > cm3 > > On 12 Jan 2009, at 18:25, Jay wrote: > > The compiler uses sysutils. The first pass builds against an old > package store, which might not have sysutils at all, if it is that > old. > > Again, once new m3core is around, no problem. > I could/should have put in the m3core change and just waited on the > sysutils change, rather than go ahead and do the quake stuff, and we > can do that now (or your change that moots it, which I haven't > looked into yet). > > I was browsing the docs and it appears there is an "import_pkg" > directive for like, copying in a package contents, instead of > linking. That might also solve this. I found that relatively late > and never looked into it. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 18:19:55 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Not true. sysutils should be built against the m3core with which it > will be linked. I don't think this is correct. > > On 12 Jan 2009, at 17:58, Jay wrote: > > To bootstrap I believe. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 17:53:02 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Why does sysutils need to be compatible with both old and new > versions of m3core? > > On 12 Jan 2009, at 17:39, Jay wrote: > > ThreadPosix is basically unaffected -- I never provided user threads > on Cygwin. > I guess it got a slight reduction regarding DoesWaitPidYield, but > its SchedulerPosix implementation was unchanged. > > The code in ThreadPosix is similar to but different than > ThreadPThread. > It is possible they could be merged but it wasn't trivial so I left > ThreadPosix alone. > > > You are smearing implementation details across multiple files and > directories > > You really think it is bad to have SchedulerPosix implemented in a > small separate file? > On top of what happens to be common implementation details of > ThreadPThread.m3 and ThreadWin32.m3? > > ThreadPScheduler.m3 is just basically three functions: IOWait, > IOAlertWait, XIOWait > Plus the little internal utility, UTimeFromTime, the one liner > DoesWaitPidYield, and non-trivial functions nested in XIOWait: > TestFDS, CallSelect. > > I mean, you know, an alternative is to copy out very large chunks of > ThreadWin32.m3 and ThreadPThread.m3 and merge them into > ThreadCygwin.m3. That would be worse imho. > > "Directories" hardly. > > Or I can try debugging cygwin pthreads again. > > - Jay > > > CC: jkrell at elego.de; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Mon, 12 Jan 2009 12:46:54 +1100 > > You are smearing implementation details across multiple files and > directories. Up until now, ThreadPThread has been nicely self- > contained, and captured all the basic pieces of the thread > implementation. Also, how does all of this fit with the ThreadPosix > implementation? > > On 12 Jan 2009, at 12:19, Jay wrote: > > btw, I don't think it's that hairy, I merely split it into two or > three files, and added interfaces so they can reuse code with each > other. Movement between files is hard to track though (depending on > version control, but with all I've used). > > The SchedulerPosix implementation moved to ThreadPScheduler.m3. > What is shared between it and ThreadPThread/Win32.m3 is > ThreadInternal.i3, which maybe should be in ThreadF.i3, though > that's exposed outside m3core, and ThreadInternal.i3 includes a > variable. > > I can try again to debug Cygwin pthreads though. > > - Jay > > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:03:33 +1100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay, > > > > Can you remind me again why Cygwin was unable to use pthreads? It > > seems you have introduced a bunch of hair into the PTHREADS > > implementation to deal with broken Cygwin pthreads. As many of us > > have already pointed out, Cygwin should be a port that tries as much > > as possible to be like a standard POSIX platform (pthread-based) as > > opposed to a weird Windows/POSIX hybrid. > > > > I have a bunch of code that will be going into the PTHREADS base > that > > I am now at a loss to integrate with the changes you have made. > > > > Help! > > > > -- Tony > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jan 14 01:09:03 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 14 Jan 2009 00:09:03 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: > Sounds like your upgrade script Based on someone else's upgrade.sh. > The alternative is to fold sysutils into m3core, where it can be used directly Merging sysutils into m3core doesn't quite work, again only or due to bootstrapping from older builds. The compiler uses sysutils. Older builds don't have it at all, and can't build m3core...but maybe again, make that hand patch Long.Rep = INTEGER? Or have an up to date compiler. Pointless statement I'm making though, it devolves to: - have an up to date m3core in bootstrap - or have sysutils in bootstrap, which implies up to date m3core - or merge sysutils with m3core, which implies up to date m3core (and the second) => "have an up to date m3core" (and LONGINT capable compiler) And I think merging them is a fine idea. I generally like fewer larger pieces of reusable code, though the counterpoint is to have more smaller independently changable pieces. Probably the scripts and/or m3makefiles should probe the compiler version and/or m3core version and/or sysutils presence and error clearly if it is too old/absent. Possibly some "feature detection" feature is needed. The compiler can just define Quake variables willy/nilly. if defined("HAS_LONGINT") Less clear how to probe m3core capability. Can try compiling a little program against the old WaitProcess signature. I'm leary of anything that resembles autoconf though (though I have autoconf-ish stuff in my config files already, probing some cm3cg and cm3 behavior). Oh...I looked at WaitProcess history. It looks like I introduced it, in 2008. So..while it never returned the full status word, there also wasn't much history to change. Compiler could expose m3core functionality via variables too, though that..is wrong. It could only expose the m3core it is linked to, not the one it is building. I guess the only way really is to define a version or date constant and folks can write constant expressions based on it, though that doesn't get you very far. Less clear how to correctly probe for package existance. Easy to do ad-hoc by probing package store files, not sure what is the right way. I also want to try this "import_pkg" directive I see in the docs. It might help a lot here, if I understand it, and if it actually exists and resembles the doc I read. It sounds like it recompiles a package's source as part of another package, statically linking it. It would be bloating in the absence of build_standalone(), but not in its presence. > No! I did not want to do have this hack Are the hacks this time in sysutils really so bad? m3core is left unadulterated. sysutils assumes waitpid(0) won't deadlock, which is true of kernel threads and cm3's use. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Wed, 14 Jan 2009 10:11:36 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3 On 14 Jan 2009, at 01:54, Jay wrote: > fix for old compilers that can't compile LONGINT: define LongRep.T = INTEGERIs that what bootstrapping should do? Automate that little patch for the first pass and undo it in the second? Then always building in dependency order? I would prefer to get all the bootstrap archives LONGINT-capable. Just do the patch by hand to build the initial archives and then forget about it. Tonight I was trying to build from PPC_DARWIN 5.5.0.I figured, heck, maybe it supports LONGINT already, maybe I should just trybuilding up in dependency order.But then I hit the problem of Compiler.i3 mismatch due to new targets. So...is that correct?Does building in dependency order predictably fail if compiler has fewer targets than runtime?But starting with existing m3core/libm3 and first building the compiler against them predictably works? Yes, it works. I've added targets a bunch and usually don't have a problem, but I can't say for certain whatorder I do things when I do this.Certainly "upgrade.py skipgcc" is something I run fairly often.It is very fast on NT386 (and unlike upgrade.sh, it doesn't build all of std). Sounds like your upgrade script For now I put in two small hacks to sysutils, so it works with old m3core. No! I did not want to do have this hack. Let's just fix the boot archives to handle new m3core and have sysutils work as expected. The alternative is to fold sysutils into m3core, where it can be used directly. That might be a better solution given the dependency. Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 14 02:49:41 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 14 Jan 2009 12:49:41 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: <2FFBEA2D-98BF-4268-977C-4A4B38664B08@cs.purdue.edu> The current hack is not so bad, I suppose. I would prefer to come up with a solution that simply defines Process.Wait and System.Wait as returning a BOOLEAN indicating if the process terminated successfully or not. Are there any clients of these procedures that decode the bits in any more detail than simply testing non-zero? On 14 Jan 2009, at 11:09, Jay wrote: > > Sounds like your upgrade script > > Based on someone else's upgrade.sh. > > > > The alternative is to fold sysutils into m3core, where it can be > used directly > > Merging sysutils into m3core doesn't quite work, > again only or due to bootstrapping from older builds. > > The compiler uses sysutils. Older builds don't have it at all, > and can't build m3core...but maybe again, make that hand patch > Long.Rep = INTEGER? Or have an up to date compiler. > > > > Pointless statement I'm making though, it devolves to: > > > - have an up to date m3core in bootstrap > - or have sysutils in bootstrap, which implies up to date m3core > - or merge sysutils with m3core, which implies up to date m3core > (and the second) > => "have an up to date m3core" (and LONGINT capable compiler) > > And I think merging them is a fine idea. > I generally like fewer larger pieces of reusable code, though > the counterpoint is to have more smaller independently changable > pieces. > > > Probably the scripts and/or m3makefiles should probe the compiler > version > and/or m3core version and/or sysutils presence and error clearly if > it is too old/absent. > > Possibly some "feature detection" feature is needed. > > The compiler can just define Quake variables willy/nilly. > if defined("HAS_LONGINT") > Less clear how to probe m3core capability. > Can try compiling a little program against the old WaitProcess > signature. > I'm leary of anything that resembles autoconf though (though I > have autoconf-ish > stuff in my config files already, probing some cm3cg and cm3 > behavior). > Oh...I looked at WaitProcess history. It looks like I introduced > it, in 2008. > So..while it never returned the full status word, there also > wasn't much history > to change. > Compiler could expose m3core functionality via variables too, > though that..is wrong. > It could only expose the m3core it is linked to, not the one it > is building. > I guess the only way really is to define a version or date > constant and folks > can write constant expressions based on it, though that doesn't > get you very far. > > Less clear how to correctly probe for package existance. > Easy to do ad-hoc by probing package store files, not sure what is > the right way. > > > I also want to try this "import_pkg" directive I see in the docs. > It might help a lot here, > if I understand it, and if it actually exists and resembles the > doc I read. > It sounds like it recompiles a package's source as part of another > package, statically > linking it. It would be bloating in the absence of > build_standalone(), but not in its presence. > > > > No! I did not want to do have this hack > > Are the hacks this time in sysutils really so bad? > m3core is left unadulterated. > sysutils assumes waitpid(0) won't deadlock, which is true of kernel > threads and cm3's use. > > - Jay > > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Wed, 14 Jan 2009 10:11:36 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > On 14 Jan 2009, at 01:54, Jay wrote: > > > fix for old compilers that can't compile LONGINT: define > LongRep.T = INTEGER > > Is that what bootstrapping should do? > Automate that little patch for the first pass and undo it in the > second? > Then always building in dependency order? > > I would prefer to get all the bootstrap archives LONGINT-capable. > Just do the patch by hand to build the initial archives and then > forget about it. > > Tonight I was trying to build from PPC_DARWIN 5.5.0. > I figured, heck, maybe it supports LONGINT already, maybe I should > just try > building up in dependency order. > But then I hit the problem of Compiler.i3 mismatch due to new targets. > > So...is that correct? > Does building in dependency order predictably fail if compiler has > fewer targets than runtime? > But starting with existing m3core/libm3 and first building the > compiler against them predictably works? > > Yes, it works. > > I've added targets a bunch and usually don't have a problem, but I > can't say for certain what > order I do things when I do this. > Certainly "upgrade.py skipgcc" is something I run fairly often. > It is very fast on NT386 (and unlike upgrade.sh, it doesn't build > all of std). > > Sounds like your upgrade script > > For now I put in two small hacks to sysutils, so it works with old > m3core. > > No! I did not want to do have this hack. Let's just fix the boot > archives to handle new m3core and have sysutils work as expected. > The alternative is to fold sysutils into m3core, where it can be > used directly. That might be a better solution given the > dependency. Thoughts? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jan 14 03:33:53 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 14 Jan 2009 02:33:53 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <2FFBEA2D-98BF-4268-977C-4A4B38664B08@cs.purdue.edu> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> <2FFBEA2D-98BF-4268-977C-4A4B38664B08@cs.purdue.edu> Message-ID: I /think/ cm3/quake exposes the integer but I'll try to peek around, and at the other clients, and my own uses of try_exec/q_exec. There is /some/ validity to a "rich" exit code, more than 1 bit, but I realize it is controversial. Windows has a 32 bit exit code. Perl on Windows truncates it to 8 bits. When a process exits with a negative exit code, Perl on Windows gets confused and issues a strange error or runs it a second time (as if negative means CreateProcess failed, for a possible reason that the path was wrong.) - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Wed, 14 Jan 2009 12:49:41 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3 The current hack is not so bad, I suppose. I would prefer to come up with a solution that simply defines Process.Wait and System.Wait as returning a BOOLEAN indicating if the process terminated successfully or not. Are there any clients of these procedures that decode the bits in any more detail than simply testing non-zero? On 14 Jan 2009, at 11:09, Jay wrote: > Sounds like your upgrade script Based on someone else's upgrade.sh. > The alternative is to fold sysutils into m3core, where it can be used directly Merging sysutils into m3core doesn't quite work, again only or due to bootstrapping from older builds. The compiler uses sysutils. Older builds don't have it at all, and can't build m3core...but maybe again, make that hand patch Long.Rep = INTEGER? Or have an up to date compiler. Pointless statement I'm making though, it devolves to: - have an up to date m3core in bootstrap - or have sysutils in bootstrap, which implies up to date m3core - or merge sysutils with m3core, which implies up to date m3core (and the second) => "have an up to date m3core" (and LONGINT capable compiler) And I think merging them is a fine idea.I generally like fewer larger pieces of reusable code, thoughthe counterpoint is to have more smaller independently changable pieces. Probably the scripts and/or m3makefiles should probe the compiler version and/or m3core version and/or sysutils presence and error clearly if it is too old/absent. Possibly some "feature detection" feature is needed. The compiler can just define Quake variables willy/nilly. if defined("HAS_LONGINT") Less clear how to probe m3core capability. Can try compiling a little program against the old WaitProcess signature. I'm leary of anything that resembles autoconf though (though I have autoconf-ish stuff in my config files already, probing some cm3cg and cm3 behavior). Oh...I looked at WaitProcess history. It looks like I introduced it, in 2008. So..while it never returned the full status word, there also wasn't much history to change. Compiler could expose m3core functionality via variables too, though that..is wrong. It could only expose the m3core it is linked to, not the one it is building. I guess the only way really is to define a version or date constant and folks can write constant expressions based on it, though that doesn't get you very far. Less clear how to correctly probe for package existance. Easy to do ad-hoc by probing package store files, not sure what is the right way. I also want to try this "import_pkg" directive I see in the docs. It might help a lot here, if I understand it, and if it actually exists and resembles the doc I read. It sounds like it recompiles a package's source as part of another package, statically linking it. It would be bloating in the absence of build_standalone(), but not in its presence. > No! I did not want to do have this hack Are the hacks this time in sysutils really so bad? m3core is left unadulterated. sysutils assumes waitpid(0) won't deadlock, which is true of kernel threads and cm3's use. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Wed, 14 Jan 2009 10:11:36 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3 On 14 Jan 2009, at 01:54, Jay wrote: > fix for old compilers that can't compile LONGINT: define LongRep.T = INTEGERIs that what bootstrapping should do? Automate that little patch for the first pass and undo it in the second? Then always building in dependency order? I would prefer to get all the bootstrap archives LONGINT-capable. Just do the patch by hand to build the initial archives and then forget about it. Tonight I was trying to build from PPC_DARWIN 5.5.0.I figured, heck, maybe it supports LONGINT already, maybe I should just trybuilding up in dependency order.But then I hit the problem of Compiler.i3 mismatch due to new targets. So...is that correct?Does building in dependency order predictably fail if compiler has fewer targets than runtime?But starting with existing m3core/libm3 and first building the compiler against them predictably works? Yes, it works. I've added targets a bunch and usually don't have a problem, but I can't say for certain whatorder I do things when I do this.Certainly "upgrade.py skipgcc" is something I run fairly often.It is very fast on NT386 (and unlike upgrade.sh, it doesn't build all of std). Sounds like your upgrade script For now I put in two small hacks to sysutils, so it works with old m3core. No! I did not want to do have this hack. Let's just fix the boot archives to handle new m3core and have sysutils work as expected. The alternative is to fold sysutils into m3core, where it can be used directly. That might be a better solution given the dependency. Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jan 14 03:57:51 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 14 Jan 2009 02:57:51 +0000 Subject: [M3devel] building all platforms regularly? Message-ID: Hi. On my system I can cd m3-sys/m3cc cm3 -DM3CC_TARGET=platform cd scripts/python ./do-cm3-all.py realclean skipgcc ./do-cm3-std.py platform boot skipgcc ./boot1.py platform and for pretty much "any" platform it pretty much works. Ok, on a 32bit host with a 64bit target, there is an error in JV.i3 or such because, like TextLiteralF.i3, there is a declaration of a maximally sized integer. This is an easy to fix compiler bug, soon. Ratchet it down to just "min" and it works more, since JV.i3 isn't there. The result of this is a .tar.gz containing assembly source for all the Modula-3 code, some .h and .c files, and a Makefile and alternate make.sh. One can takes this to the target system, with a C development environment, and finish the build, giving you a current cm3, which you can then use to build cm3cg, and so on. (Some source files are also in the archive and updatesource.sh, but that's not relevant to this email; they are typically edited files when doing a new port.) So, my point is, maybe this should be run kind of like the Tinderboxes? Spitting out current archives of all "active" platforms, regularly? It is not as "good" as the Tinderbox. There might still be errors in the C, link errors, test failures. But it is pretty good. It gets a bit more testing across platforms and provides a good up to date start. And then, the list of "active" targets needs to be identified. Oh, I forgot to mention, this only currently works for platforms for which there is m3-sys/cminstall/src/config-no-install/platform, and NT386. The others give an error about not liking the "unconfigured" config files in the neighboring config directory. Also, the .tar.gz is presently put at the root, which isn't right. It works ok on Windows. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jan 14 05:16:43 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 14 Jan 2009 04:16:43 +0000 Subject: [M3devel] FW: building all platforms regularly? Message-ID: [was truncated] From: jayTo: m3develSubject: building all platforms regularly?Date: Wed, 14 Jan 2009 02:57:51 +0000 Hi. On my system I can cd m3-sys/m3cc cm3 -DM3CC_TARGET=platform cd scripts/python ./do-cm3-all.py realclean skipgcc ./do-cm3-std.py platform boot skipgcc ./boot1.py platform and for pretty much "any" platform it pretty much works.Ok, on a 32bit host with a 64bit target, there is an error in JV.i3 or such because,like TextLiteralF.i3, there is a declaration of a maximally sized integer.This is an easy to fix compiler bug, soon. Ratchet it down to just "min" and it works more, since JV.i3 isn't there. The result of this is a .tar.gz containing assembly source for all the Modula-3 code,some .h and .c files, and a Makefile and alternate make.sh.One can takes this to the target system, with a C development environment,and finish the build, giving you a current cm3, which you can then use to build cm3cg,and so on. (Some source files are also in the archive and updatesource.sh, but that'snot relevant to this email; they are typically edited files when doing a new port.) So, my point is, maybe this should be run kind of like the Tinderboxes?Spitting out current archives of all "active" platforms, regularly? It is not as "good" as the Tinderbox.There might still be errors in the C, link errors, test failures.But it is pretty good. It gets a bit more testing across platforms and provides a good up to date start. And then, the list of "active" targets needs to be identified. Oh, I forgot to mention, this only currently works for platforms for whichthere is m3-sys/cminstall/src/config-no-install/platform, and NT386.The others give an error about not liking the "unconfigured" config filesin the neighboring config directory. Also, the .tar.gz is presently put at the root, which isn't right.It works ok on Windows. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jan 14 07:53:08 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 14 Jan 2009 06:53:08 +0000 Subject: [M3devel] building all platforms regularly? Message-ID: On the other hand, this is increasingly redundant, what with the increased portability in the system and coming to the system :). And increasingly insufficient, since it doesn't test compilability of the C code. - Jay From: jay.krell at cornell.eduTo: m3devel at elegosoft.comSubject: FW: building all platforms regularly?Date: Wed, 14 Jan 2009 04:16:43 +0000 [was truncated] From: jayTo: m3develSubject: building all platforms regularly?Date: Wed, 14 Jan 2009 02:57:51 +0000 Hi. On my system I can cd m3-sys/m3cc cm3 -DM3CC_TARGET=platform cd scripts/python ./do-cm3-all.py realclean skipgcc ./do-cm3-std.py platform boot skipgcc ./boot1.py platform and for pretty much "any" platform it pretty much works.Ok, on a 32bit host with a 64bit target, there is an error in JV.i3 or such because,like TextLiteralF.i3, there is a declaration of a maximally sized integer.This is an easy to fix compiler bug, soon. Ratchet it down to just "min" and it works more, since JV.i3 isn't there. The result of this is a .tar.gz containing assembly source for all the Modula-3 code,some .h and .c files, and a Makefile and alternate make.sh.One can takes this to the target system, with a C development environment,and finish the build, giving you a current cm3, which you can then use to build cm3cg,and so on. (Some source files are also in the archive and updatesource.sh, but that'snot relevant to this email; they are typically edited files when doing a new port.) So, my point is, maybe this should be run kind of like the Tinderboxes?Spitting out current archives of all "active" platforms, regularly? It is not as "good" as the Tinderbox.There might still be errors in the C, link errors, test failures.But it is pretty good. It gets a bit more testing across platforms and provides a good up to date start. And then, the list of "active" targets needs to be identified. Oh, I forgot to mention, this only currently works for platforms for whichthere is m3-sys/cminstall/src/config-no-install/platform, and NT386.The others give an error about not liking the "unconfigured" config filesin the neighboring config directory. Also, the .tar.gz is presently put at the root, which isn't right.It works ok on Windows. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jan 14 10:14:19 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 14 Jan 2009 09:14:19 +0000 Subject: [M3devel] how to switch between user and kernel threads.. Message-ID: Are people really against using function pointers for this? Either changing the interface to have function pointer variables (I'm not sure Modula-3 allows this, but in C you can fairly transparently replace functions with function pointers; client code just keeps working; it breaks down in C++ with overloading), or having a set of functions that just call/jump through function pointers? There would be no if, no conditional branches. Dynamic linking on Windows always goes through function pointers already. So while yes it adds another instruction, it is already never getting inlined. Don't other platforms do that too? Or they patch every call site? I'm not sure otherwise of a simple method. Easiest might be to have a parallel directory structure to m3core, with just m3core files. That would wastefully rebuild all of m3core a second time, for just a small amount of variation. I think function pointers are the way to go here. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 14 11:31:22 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 14 Jan 2009 21:31:22 +1100 Subject: [M3devel] how to switch between user and kernel threads.. In-Reply-To: References: Message-ID: I don't want dynamic switching. A link-time switch is just fine. Also, please don't go messing about with this right now -- I have changes pending for the threads system that will be harder to integrate if you change with it further. On 14 Jan 2009, at 20:14, Jay wrote: > Are people really against using function pointers for this? > Either changing the interface to have function pointer variables > (I'm not sure Modula-3 allows this, but in C you can fairly > transparently replace functions with function pointers; client code > just keeps working; it breaks down in C++ with overloading), or > having a set of functions that just call/jump through function > pointers? There would be no if, no conditional branches. > > Dynamic linking on Windows always goes through function pointers > already. > So while yes it adds another instruction, it is already never > getting inlined. > Don't other platforms do that too? > Or they patch every call site? > > I'm not sure otherwise of a simple method. > Easiest might be to have a parallel directory structure to m3core, > with just m3core files. > That would wastefully rebuild all of m3core a second time, for just > a small amount of variation. > > I think function pointers are the way to go here. > > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jan 14 22:30:59 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 14 Jan 2009 21:30:59 +0000 Subject: [M3devel] how to switch between user and kernel threads.. In-Reply-To: References: Message-ID: I'll wait. So, build two different m3core.lib/a/so/dylib? m3core and m3coreuserthreads Compile both thread directories, if the platform supports it, and call quake make_lib twice with slightly different parameters? An m3core specific hack in the config file or cm3? Easy enough in the config file. Very m3core specific. I suppose you could argue that quake isn't a generic build system, but it is Modula-3's build system, and that m3core is really special. The result btw, would likely be no change at all to any *.i3 or *.m3 file. I still think function pointers are the way to go. Even with function pointers, the changes to *.i3 and *.m3 would be very minor. Just the export list would vary. And new *.i3 files introduced. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Wed, 14 Jan 2009 21:31:22 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] how to switch between user and kernel threads..I don't want dynamic switching. A link-time switch is just fine. Also, please don't go messing about with this right now -- I have changes pending for the threads system that will be harder to integrate if you change with it further. On 14 Jan 2009, at 20:14, Jay wrote: Are people really against using function pointers for this?Either changing the interface to have function pointer variables (I'm not sure Modula-3 allows this, but in C you can fairly transparently replace functions with function pointers; client code just keeps working; it breaks down in C++ with overloading), or having a set of functions that just call/jump through function pointers? There would be no if, no conditional branches. Dynamic linking on Windows always goes through function pointers already. So while yes it adds another instruction, it is already never getting inlined.Don't other platforms do that too?Or they patch every call site? I'm not sure otherwise of a simple method.Easiest might be to have a parallel directory structure to m3core, with just m3core files.That would wastefully rebuild all of m3core a second time, for just a small amount of variation. I think function pointers are the way to go here. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jan 14 22:34:20 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 14 Jan 2009 21:34:20 +0000 Subject: [M3devel] FW: how to switch between user and kernel threads.. In-Reply-To: References: Message-ID: [truncated again] From: jayTo: hoskingCC: m3develSubject: RE: [M3devel] how to switch between user and kernel threads..Date: Wed, 14 Jan 2009 21:30:59 +0000 I'll wait.So, build two different m3core.lib/a/so/dylib?m3core and m3coreuserthreads Compile both thread directories, if the platform supports it, andcall quake make_lib twice with slightly different parameters?An m3core specific hack in the config file or cm3?Easy enough in the config file.Very m3core specific.I suppose you could argue that quake isn't a generic build system,but it is Modula-3's build system, and that m3core is really special. The result btw, would likely be no change at all to any *.i3 or *.m3 file. I still think function pointers are the way to go.Even with function pointers, the changes to *.i3 and *.m3 would be very minor.Just the export list would vary.And new *.i3 files introduced. - Jay From: hoskingTo: jayDate: Wed, 14 Jan 2009 21:31:22 +1100CC: m3deveSubject: Re: [M3devel] how to switch between user and kernel threads..I don't want dynamic switching. A link-time switch is just fine. Also, please don't go messing about with this right now -- I have changes pending for the threads system that will be harder to integrate if you change with it further. On 14 Jan 2009, at 20:14, Jay wrote: Are people really against using function pointers for this?Either changing the interface to have function pointer variables (I'm not sure Modula-3 allows this, but in C you can fairly transparently replace functions with function pointers; client code just keeps working; it breaks down in C++ with overloading), or having a set of functions that just call/jump through function pointers? There would be no if, no conditional branches. Dynamic linking on Windows always goes through function pointers already. So while yes it adds another instruction, it is already never getting inlined.Don't other platforms do that too?Or they patch every call site? I'm not sure otherwise of a simple method.Easiest might be to have a parallel directory structure to m3core, with just m3core files.That would wastefully rebuild all of m3core a second time, for just a small amount of variation. I think function pointers are the way to go here. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jan 15 01:31:17 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 15 Jan 2009 11:31:17 +1100 Subject: [M3devel] how to switch between user and kernel threads.. In-Reply-To: References: Message-ID: <56CF4A94-6620-4A69-B4DC-D72268811AEA@cs.purdue.edu> No function pointers please. Let the installer decide whether to use native or user threads. On 15 Jan 2009, at 08:30, Jay wrote: > I'll wait. > So, build two different m3core.lib/a/so/dylib? > m3core and m3coreuserthreads > > Compile both thread directories, if the platform supports it, and > call quake make_lib twice with slightly different parameters? > An m3core specific hack in the config file or cm3? > Easy enough in the config file. > Very m3core specific. > I suppose you could argue that quake isn't a generic build system, > but it is Modula-3's build system, and that m3core is really special. > > The result btw, would likely be no change at all to any *.i3 or *.m3 > file. > > I still think function pointers are the way to go. > Even with function pointers, the changes to *.i3 and *.m3 would be > very minor. > Just the export list would vary. > And new *.i3 files introduced. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Wed, 14 Jan 2009 21:31:22 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] how to switch between user and kernel threads.. > > I don't want dynamic switching. A link-time switch is just fine. > > Also, please don't go messing about with this right now -- I have > changes pending for the threads system that will be harder to > integrate if you change with it further. > > On 14 Jan 2009, at 20:14, Jay wrote: > > Are people really against using function pointers for this? > Either changing the interface to have function pointer variables > (I'm not sure Modula-3 allows this, but in C you can fairly > transparently replace functions with function pointers; client code > just keeps working; it breaks down in C++ with overloading), or > having a set of functions that just call/jump through function > pointers? There would be no if, no conditional branches. > > Dynamic linking on Windows always goes through function pointers > already. > So while yes it adds another instruction, it is already never > getting inlined. > Don't other platforms do that too? > Or they patch every call site? > > I'm not sure otherwise of a simple method. > Easiest might be to have a parallel directory structure to m3core, > with just m3core files. > That would wastefully rebuild all of m3core a second time, for just > a small amount of variation. > > I think function pointers are the way to go here. > > - Jay > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 15 04:03:23 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 15 Jan 2009 03:03:23 +0000 Subject: [M3devel] how to switch between user and kernel threads.. In-Reply-To: <56CF4A94-6620-4A69-B4DC-D72268811AEA@cs.purdue.edu> References: <56CF4A94-6620-4A69-B4DC-D72268811AEA@cs.purdue.edu> Message-ID: The installer? I thought the granularity was at the time of linking an executable. I personally thought a command line parameter would be reasonable. Why not function pointers? It is a simple straightforward method to implement. It should add one instruction per call. It does reduce inlinability but I'm sure we aren't getting any such such inlinability anyway. Dynamic linking already kills inlinability, as does separate compilation of modules in most systems. I'm not sure how the types work out in such a scheme, but probably assuming Thread.T is already a reference type, it can become ADDRESS and then loopholed to ThreadPosix.T or ThreadPThread.T. Function pointers are also the easiest method to build. I'm not sure what the others are. I can try making m3-libs/m3coreuserthreads that contains only m3makefiles. Probably it can say: LibraryName = "m3coreuserthreads" include_dir("../m3core/m3makefile") and m3core/m3makefile can say if not defined("LibraryName") LibraryName = "m3core" end Library(LibraryName) If that works, not bad. And then cm3 or the config file can translate m3core to m3coreuserthreads at some point. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Thu, 15 Jan 2009 11:31:17 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] how to switch between user and kernel threads.. No function pointers please. Let the installer decide whether to use native or user threads. On 15 Jan 2009, at 08:30, Jay wrote: I'll wait.So, build two different m3core.lib/a/so/dylib?m3core and m3coreuserthreads Compile both thread directories, if the platform supports it, andcall quake make_lib twice with slightly different parameters?An m3core specific hack in the config file or cm3?Easy enough in the config file.Very m3core specific.I suppose you could argue that quake isn't a generic build system,but it is Modula-3's build system, and that m3core is really special. The result btw, would likely be no change at all to any *.i3 or *.m3 file. I still think function pointers are the way to go.Even with function pointers, the changes to *.i3 and *.m3 would be very minor.Just the export list would vary.And new *.i3 files introduced. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Wed, 14 Jan 2009 21:31:22 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] how to switch between user and kernel threads..I don't want dynamic switching. A link-time switch is just fine. Also, please don't go messing about with this right now -- I have changes pending for the threads system that will be harder to integrate if you change with it further. On 14 Jan 2009, at 20:14, Jay wrote: Are people really against using function pointers for this?Either changing the interface to have function pointer variables (I'm not sure Modula-3 allows this, but in C you can fairly transparently replace functions with function pointers; client code just keeps working; it breaks down in C++ with overloading), or having a set of functions that just call/jump through function pointers? There would be no if, no conditional branches. Dynamic linking on Windows always goes through function pointers already. So while yes it adds another instruction, it is already never getting inlined.Don't other platforms do that too?Or they patch every call site? I'm not sure otherwise of a simple method.Easiest might be to have a parallel directory structure to m3core, with just m3core files.That would wastefully rebuild all of m3core a second time, for just a small amount of variation. I think function pointers are the way to go here. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jan 15 04:18:16 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 15 Jan 2009 14:18:16 +1100 Subject: [M3devel] how to switch between user and kernel threads.. In-Reply-To: References: <56CF4A94-6620-4A69-B4DC-D72268811AEA@cs.purdue.edu> Message-ID: We do get inlining within modules by virtue of the gcc-backend at -O3. On 15 Jan 2009, at 14:03, Jay wrote: > The installer? > I thought the granularity was at the time of linking an executable. > I personally thought a command line parameter would be reasonable. > > > Why not function pointers? > It is a simple straightforward method to implement. > It should add one instruction per call. > It does reduce inlinability but I'm sure we aren't getting any such > such inlinability anyway. > Dynamic linking already kills inlinability, as does separate > compilation of modules in most systems. > > > I'm not sure how the types work out in such a scheme, but probably > assuming Thread.T is already a reference type, it can become ADDRESS > and then loopholed to ThreadPosix.T or ThreadPThread.T. > > > Function pointers are also the easiest method to build. I'm not sure > what the others are. > I can try making m3-libs/m3coreuserthreads that contains only > m3makefiles. > Probably it can say: > LibraryName = "m3coreuserthreads" > include_dir("../m3core/m3makefile") > > > and m3core/m3makefile can say > if not defined("LibraryName") > LibraryName = "m3core" > end > Library(LibraryName) > > > If that works, not bad. > > > And then cm3 or the config file can translate m3core to > m3coreuserthreads at some point. > > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Thu, 15 Jan 2009 11:31:17 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] how to switch between user and kernel threads.. > > > No function pointers please. Let the installer decide whether to > use native or user threads. > > On 15 Jan 2009, at 08:30, Jay wrote: > > I'll wait. > So, build two different m3core.lib/a/so/dylib? > m3core and m3coreuserthreads > > Compile both thread directories, if the platform supports it, and > call quake make_lib twice with slightly different parameters? > An m3core specific hack in the config file or cm3? > Easy enough in the config file. > Very m3core specific. > I suppose you could argue that quake isn't a generic build system, > but it is Modula-3's build system, and that m3core is really special. > > The result btw, would likely be no change at all to any *.i3 or *.m3 > file. > > I still think function pointers are the way to go. > Even with function pointers, the changes to *.i3 and *.m3 would be > very minor. > Just the export list would vary. > And new *.i3 files introduced. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Wed, 14 Jan 2009 21:31:22 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] how to switch between user and kernel threads.. > > I don't want dynamic switching. A link-time switch is just fine. > > Also, please don't go messing about with this right now -- I have > changes pending for the threads system that will be harder to > integrate if you change with it further. > > On 14 Jan 2009, at 20:14, Jay wrote: > > Are people really against using function pointers for this? > Either changing the interface to have function pointer variables > (I'm not sure Modula-3 allows this, but in C you can fairly > transparently replace functions with function pointers; client code > just keeps working; it breaks down in C++ with overloading), or > having a set of functions that just call/jump through function > pointers? There would be no if, no conditional branches. > > Dynamic linking on Windows always goes through function pointers > already. > So while yes it adds another instruction, it is already never > getting inlined. > Don't other platforms do that too? > Or they patch every call site? > > I'm not sure otherwise of a simple method. > Easiest might be to have a parallel directory structure to m3core, > with just m3core files. > That would wastefully rebuild all of m3core a second time, for just > a small amount of variation. > > I think function pointers are the way to go here. > > - Jay > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 15 05:15:43 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 15 Jan 2009 04:15:43 +0000 Subject: [M3devel] how to switch between user and kernel threads.. In-Reply-To: References: <56CF4A94-6620-4A69-B4DC-D72268811AEA@cs.purdue.edu> Message-ID: That would't affected here. All the calls within ThreadPThread to within ThreadPThread would remain direct and inlinable. They would be to the "ThreadPThread" interface, and not the "Thread" interface, would be my intent. How about across modules? I expect any call from outside ThreadPThread to within ThreadPThread to never be inlined, at least not when dynamic linking and with static linking (or within the package/library) not unless there is "whole program optimization" aka "link time code generation" with static linking, which does exist out there. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Thu, 15 Jan 2009 14:18:16 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] how to switch between user and kernel threads..We do get inlining within modules by virtue of the gcc-backend at -O3. On 15 Jan 2009, at 14:03, Jay wrote: The installer?I thought the granularity was at the time of linking an executable.I personally thought a command line parameter would be reasonable. Why not function pointers?It is a simple straightforward method to implement.It should add one instruction per call.It does reduce inlinability but I'm sure we aren't getting any such such inlinability anyway.Dynamic linking already kills inlinability, as does separate compilation of modules in most systems. I'm not sure how the types work out in such a scheme, but probably assuming Thread.T is already a reference type, it can become ADDRESS and then loopholed to ThreadPosix.T or ThreadPThread.T. Function pointers are also the easiest method to build. I'm not sure what the others are.I can try making m3-libs/m3coreuserthreads that contains only m3makefiles.Probably it can say:LibraryName = "m3coreuserthreads"include_dir("../m3core/m3makefile") and m3core/m3makefile can sayif not defined("LibraryName") LibraryName = "m3core"endLibrary(LibraryName) If that works, not bad. And then cm3 or the config file can translate m3core to m3coreuserthreads at some point. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Thu, 15 Jan 2009 11:31:17 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] how to switch between user and kernel threads.. No function pointers please. Let the installer decide whether to use native or user threads. On 15 Jan 2009, at 08:30, Jay wrote: I'll wait.So, build two different m3core.lib/a/so/dylib?m3core and m3coreuserthreads Compile both thread directories, if the platform supports it, andcall quake make_lib twice with slightly different parameters?An m3core specific hack in the config file or cm3?Easy enough in the config file.Very m3core specific.I suppose you could argue that quake isn't a generic build system,but it is Modula-3's build system, and that m3core is really special. The result btw, would likely be no change at all to any *.i3 or *.m3 file. I still think function pointers are the way to go.Even with function pointers, the changes to *.i3 and *.m3 would be very minor.Just the export list would vary.And new *.i3 files introduced. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Wed, 14 Jan 2009 21:31:22 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] how to switch between user and kernel threads..I don't want dynamic switching. A link-time switch is just fine. Also, please don't go messing about with this right now -- I have changes pending for the threads system that will be harder to integrate if you change with it further. On 14 Jan 2009, at 20:14, Jay wrote: Are people really against using function pointers for this?Either changing the interface to have function pointer variables (I'm not sure Modula-3 allows this, but in C you can fairly transparently replace functions with function pointers; client code just keeps working; it breaks down in C++ with overloading), or having a set of functions that just call/jump through function pointers? There would be no if, no conditional branches. Dynamic linking on Windows always goes through function pointers already. So while yes it adds another instruction, it is already never getting inlined.Don't other platforms do that too?Or they patch every call site? I'm not sure otherwise of a simple method.Easiest might be to have a parallel directory structure to m3core, with just m3core files.That would wastefully rebuild all of m3core a second time, for just a small amount of variation. I think function pointers are the way to go here. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinbishop at bellsouth.net Fri Jan 16 03:25:04 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Thu, 15 Jan 2009 20:25:04 -0600 Subject: [M3devel] Percent to REAL? Message-ID: <496FF000.1030506@bellsouth.net> I'm feeling silly, but I need to convert a percentage (stored as an INTEGER) into a REAL, so I tried FLOAT(num) / 100.0 but that doesn't work. I tried using FLOAT(num DIV 100) but that doesn't work either. I also tried FLOAT(num MOD 100) just to try everything, and that didn't work either. How can I convert a percentage into a REAL? For example, 70% -> 0.70 From rcoleburn at scires.com Fri Jan 16 03:47:54 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 15 Jan 2009 21:47:54 -0500 Subject: [M3devel] Percent to REAL? In-Reply-To: <496FF000.1030506@bellsouth.net> References: <496FF000.1030506@bellsouth.net> Message-ID: <496FAE9F.1E75.00D7.1@scires.com> Martin: The following works for me: VAR i: INTEGER; r: REAL; BEGIN i := 70; r := FLOAT(i) / 100.0; END; Regards, Randy >>> Martin Bishop 1/15/2009 9:25 PM >>> I'm feeling silly, but I need to convert a percentage (stored as an INTEGER) into a REAL, so I tried FLOAT(num) / 100.0 but that doesn't work. I tried using FLOAT(num DIV 100) but that doesn't work either. I also tried FLOAT(num MOD 100) just to try everything, and that didn't work either. How can I convert a percentage into a REAL? For example, 70% -> 0.70 -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinbishop at bellsouth.net Fri Jan 16 03:37:28 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Thu, 15 Jan 2009 20:37:28 -0600 Subject: [M3devel] Percent to REAL? In-Reply-To: <496FF000.1030506@bellsouth.net> References: <496FF000.1030506@bellsouth.net> Message-ID: <496FF2E8.5050801@bellsouth.net> Martin Bishop wrote: > I'm feeling silly, but I need to convert a percentage (stored as an > INTEGER) into a REAL, so I tried FLOAT(num) / 100.0 but that doesn't > work. I tried using FLOAT(num DIV 100) but that doesn't work either. I > also tried FLOAT(num MOD 100) just to try everything, and that didn't > work either. > > How can I convert a percentage into a REAL? For example, 70% -> 0.70 > Disregard that, I knew I was feeling silly, FLOAT(num) / 100.0 DOES work. From jay.krell at cornell.edu Fri Jan 16 10:28:46 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 16 Jan 2009 09:28:46 +0000 Subject: [M3devel] how to switch between user and kernel threads.. In-Reply-To: References: <56CF4A94-6620-4A69-B4DC-D72268811AEA@cs.purdue.edu> Message-ID: I was able to easily build this alternate library, just by creating one small m3makefile and optionally editing one other very little. I wasn't able to find a way to get it used, other than maybe shipping it on top of the "real" m3core. A compiler hack that knows to replace package "m3core" with "m3coreuserthreads" may be appropriate. I can look into that. But I still don't know why not function pointers. Plenty else to do in the meantime (Cygwin/pthreads, portability, a bunch of ports..). - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] how to switch between user and kernel threads..Date: Thu, 15 Jan 2009 04:15:43 +0000 That would't affected here. All the calls within ThreadPThread to within ThreadPThread would remain direct and inlinable. They would be to the "ThreadPThread" interface, and not the "Thread" interface, would be my intent. How about across modules? I expect any call from outside ThreadPThread to within ThreadPThread to never be inlined, at least not when dynamic linking and with static linking (or within the package/library) not unless there is "whole program optimization" aka "link time code generation" with static linking, which does exist out there. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Thu, 15 Jan 2009 14:18:16 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] how to switch between user and kernel threads..We do get inlining within modules by virtue of the gcc-backend at -O3. On 15 Jan 2009, at 14:03, Jay wrote: The installer?I thought the granularity was at the time of linking an executable.I personally thought a command line parameter would be reasonable. Why not function pointers?It is a simple straightforward method to implement.It should add one instruction per call.It does reduce inlinability but I'm sure we aren't getting any such such inlinability anyway.Dynamic linking already kills inlinability, as does separate compilation of modules in most systems. I'm not sure how the types work out in such a scheme, but probably assuming Thread.T is already a reference type, it can become ADDRESS and then loopholed to ThreadPosix.T or ThreadPThread.T. Function pointers are also the easiest method to build. I'm not sure what the others are.I can try making m3-libs/m3coreuserthreads that contains only m3makefiles.Probably it can say:LibraryName = "m3coreuserthreads"include_dir("../m3core/m3makefile") and m3core/m3makefile can sayif not defined("LibraryName") LibraryName = "m3core"endLibrary(LibraryName) If that works, not bad. And then cm3 or the config file can translate m3core to m3coreuserthreads at some point. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Thu, 15 Jan 2009 11:31:17 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] how to switch between user and kernel threads.. No function pointers please. Let the installer decide whether to use native or user threads. On 15 Jan 2009, at 08:30, Jay wrote: I'll wait.So, build two different m3core.lib/a/so/dylib?m3core and m3coreuserthreads Compile both thread directories, if the platform supports it, andcall quake make_lib twice with slightly different parameters?An m3core specific hack in the config file or cm3?Easy enough in the config file.Very m3core specific.I suppose you could argue that quake isn't a generic build system,but it is Modula-3's build system, and that m3core is really special. The result btw, would likely be no change at all to any *.i3 or *.m3 file. I still think function pointers are the way to go.Even with function pointers, the changes to *.i3 and *.m3 would be very minor.Just the export list would vary.And new *.i3 files introduced. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Wed, 14 Jan 2009 21:31:22 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] how to switch between user and kernel threads..I don't want dynamic switching. A link-time switch is just fine. Also, please don't go messing about with this right now -- I have changes pending for the threads system that will be harder to integrate if you change with it further. On 14 Jan 2009, at 20:14, Jay wrote: Are people really against using function pointers for this?Either changing the interface to have function pointer variables (I'm not sure Modula-3 allows this, but in C you can fairly transparently replace functions with function pointers; client code just keeps working; it breaks down in C++ with overloading), or having a set of functions that just call/jump through function pointers? There would be no if, no conditional branches. Dynamic linking on Windows always goes through function pointers already. So while yes it adds another instruction, it is already never getting inlined.Don't other platforms do that too?Or they patch every call site? I'm not sure otherwise of a simple method.Easiest might be to have a parallel directory structure to m3core, with just m3core files.That would wastefully rebuild all of m3core a second time, for just a small amount of variation. I think function pointers are the way to go here. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jan 16 14:05:17 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 16 Jan 2009 13:05:17 +0000 Subject: [M3devel] "new old" ports, or no ports at all? Message-ID: Would people mind "new" ports like: HPPA32_HPUX (HPPA_HPUX? There is "HPPA")I386_FREEBSD (There is FreeBSD4.)I386_NETBSD (There is NetBSD2_i386.)MIPS32_IRIX (MIPS_IRIX? There is IRIX5.)ALPHA_FREEBSD (There FBSD_ALPHA.) and then for that matter:SPARC32_SOLARIS, I386_LINUX Or some mix?This is not hypothetical. I do now have HPPA, Alpha, SGI hardware. :) I can either do the little bit of correct testable valid small etc. work of using my "more portable" approach to these platforms, which gets things up and running easily and fast and perfectly acceptably, or I could "proofread" all the gunk, I mean cloned headers, fix them for current system, worry if they break old system, or delete them, possibly doing some hypothetical damage to the old ports. It seems easier and a better result to "start over" and leave the old stuff alone, maybe delete it, depending on what people think of history preservation and history vs. deletes (deleted stuff isn't very visible). Or maybe hardly any of this matters. Nobody uses these platforms or anything like them? (I recall Randy saying he is still using 4.1 on HP-UX though. I'm on a fun little long running errand here of getting not ancient but not current systems.. :) ) The "4", "2", "5" in FreeBSD4, NetBSD2_i386, IRIX5 make them seen somewhat "wrong". The "4" in FreeBSD4 (err, in i686-freebsd4) does have a surprising semantic, in the backend..but maybe not. C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(53): builtin_define_with_int_value ("__FreeBSD__", FBSD_MAJOR); \ C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(122):#if FBSD_MAJOR < 5 C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(141):#if FBSD_MAJOR < 6 though I think if you look closely, these don't matter to us.They affect the gcc driver and the C/C++ front end, but maybe not the m3cg backend. Even the "LIBC6" in "LINUXLIBC6" seems dubious, because, for example, I amtempted to make "ARM_LINUX_UCLIBC", which suggests either thatthere might be an "I386_LINUX_UCLIBC" or "generic" "I386_LINUX" thatis portable across libc6/uclibc/dietlibc/newlib either by seeingwhat they have in common, or skipping them and using the kernel interfacesmore directly. There is another angle here.To what extent is the compiler platform specific? (I mostly know the answer to this. It is a leading question.)Could ports go away?Almost? Historically there were a bunch of platform-specific .i3 files.That is dwindling much in some platforms and could dwindle much overall.A little more C code in the system and the Modula-3 .i3 files are all "portable". It ends up being, roughly, that there is: endian, and even this is often not an issue; I saw like one reference in the compiler to it, and there is a little bit in m3core/libm3 The byte swap functions and maybe the Float stuff (there is endian specific and generic stuff, not all is used). It would affect e.g. the layout of the Uexec types, but they are gone. Such endian-specificity could occur anywhere but maybe "cm3 -generic" errors for it? word size -- 32bit or 64bit. There is no escaping this, as long as there are any 32bit platforms. So ok, two ports, 32bit and 64bit. That's a small matrix. IEEE or not -- everything is IEEE now. I don't plan on getting a VAX. :) (The compiler seems suspicious here wrt cross building.) The name of setjmp. However this could be made the same everywhere -- m3_setjmp or M3Try or M3SaveState, and use an #ifdef .c file to decide. The size of the jmpbuf. Ah, there's the rub. A "generic" platform could blow up the size of the jmpbuf to something that works on all known platforms. Very very wasteful. Some platforms have tiny, some have huge. I'm not sure where stack layout is done. If the front end does it or not. You could imagine something like M3Try allocating the same..but this seems bad. If the front end defers enough work to the backend, you could introduce an abstracted notion of the jmpbuf and leave it to m3cg to fill in? Leave it to #ifdef on the target? m3cg, in its current form as gcc based is always going to have be configured to be target specific. Or all platforms could have stack walkers and this platform-specificity would go away. But that is a very long ways off, if ever. My point is, you know, can we in fact eliminate the notion of porting? At least of cm3 knowing anything about the target, and only m3cg? Because the system is nearly portable enough? All that is left is configuring gcc? It seems very close to possible. Like, "have gcc, will travel"?And nothing else changes?No value then in doing any porting work up front? You know..think of the author of hello world..some highly portable program. Or more realistic example such as bash, awk, make, ld and gcc on a particular host (not target), etc.They don't go around much and port to this or that or the other system. They do a mix of "just try to be portable" and "leave autoconf to figure out". Modula-3 is almost in the same boat? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Jan 16 17:04:53 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 16 Jan 2009 11:04:53 -0500 Subject: [M3devel] "new old" ports, or no ports at all? In-Reply-To: References: Message-ID: <49706962.1E75.00D7.1@scires.com> Jay: I do have some HP-UX machines that I could use to test whatever you come up with for HPPA. You are correct that right now I run cm3 v4.1 on these. I have not tried to move beyond 4.1 on them yet. Regards, Randy >>> Jay 1/16/2009 8:05 AM >>> Would people mind "new" ports like: HPPA32_HPUX (HPPA_HPUX? There is "HPPA") I386_FREEBSD (There is FreeBSD4.) I386_NETBSD (There is NetBSD2_i386.) MIPS32_IRIX (MIPS_IRIX? There is IRIX5.) ALPHA_FREEBSD (There FBSD_ALPHA.) and then for that matter: SPARC32_SOLARIS, I386_LINUX Or some mix? This is not hypothetical. I do now have HPPA, Alpha, SGI hardware. :) I can either do the little bit of correct testable valid small etc. work of using my "more portable" approach to these platforms, which gets things up and running easily and fast and perfectly acceptably, or I could "proofread" all the gunk, I mean cloned headers, fix them for current system, worry if they break old system, or delete them, possibly doing some hypothetical damage to the old ports. It seems easier and a better result to "start over" and leave the old stuff alone, maybe delete it, depending on what people think of history preservation and history vs. deletes (deleted stuff isn't very visible). Or maybe hardly any of this matters. Nobody uses these platforms or anything like them? (I recall Randy saying he is still using 4.1 on HP-UX though. I'm on a fun little long running errand here of getting not ancient but not current systems.. :) ) The "4", "2", "5" in FreeBSD4, NetBSD2_i386, IRIX5 make them seen somewhat "wrong". The "4" in FreeBSD4 (err, in i686-freebsd4) does have a surprising semantic, in the backend..but maybe not. C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(53): builtin_define_with_int_value ("__FreeBSD__", FBSD_MAJOR); \ C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(122):#if FBSD_MAJOR < 5 C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(141):#if FBSD_MAJOR < 6 though I think if you look closely, these don't matter to us. They affect the gcc driver and the C/C++ front end, but maybe not the m3cg backend. Even the "LIBC6" in "LINUXLIBC6" seems dubious, because, for example, I am tempted to make "ARM_LINUX_UCLIBC", which suggests either that there might be an "I386_LINUX_UCLIBC" or "generic" "I386_LINUX" that is portable across libc6/uclibc/dietlibc/newlib either by seeing what they have in common, or skipping them and using the kernel interfaces more directly. There is another angle here. To what extent is the compiler platform specific? (I mostly know the answer to this. It is a leading question.) Could ports go away? Almost? Historically there were a bunch of platform-specific .i3 files. That is dwindling much in some platforms and could dwindle much overall. A little more C code in the system and the Modula-3 .i3 files are all "portable". It ends up being, roughly, that there is: endian, and even this is often not an issue; I saw like one reference in the compiler to it, and there is a little bit in m3core/libm3 The byte swap functions and maybe the Float stuff (there is endian specific and generic stuff, not all is used). It would affect e.g. the layout of the Uexec types, but they are gone. Such endian-specificity could occur anywhere but maybe "cm3 -generic" errors for it? word size -- 32bit or 64bit. There is no escaping this, as long as there are any 32bit platforms. So ok, two ports, 32bit and 64bit. That's a small matrix. IEEE or not -- everything is IEEE now. I don't plan on getting a VAX. :) (The compiler seems suspicious here wrt cross building.) The name of setjmp. However this could be made the same everywhere -- m3_setjmp or M3Try or M3SaveState, and use an #ifdef .c file to decide. The size of the jmpbuf. Ah, there's the rub. A "generic" platform could blow up the size of the jmpbuf to something that works on all known platforms. Very very wasteful. Some platforms have tiny, some have huge. I'm not sure where stack layout is done. If the front end does it or not. You could imagine something like M3Try allocating the same..but this seems bad. If the front end defers enough work to the backend, you could introduce an abstracted notion of the jmpbuf and leave it to m3cg to fill in? Leave it to #ifdef on the target? m3cg, in its current form as gcc based is always going to have be configured to be target specific. Or all platforms could have stack walkers and this platform-specificity would go away. But that is a very long ways off, if ever. My point is, you know, can we in fact eliminate the notion of porting? At least of cm3 knowing anything about the target, and only m3cg? Because the system is nearly portable enough? All that is left is configuring gcc? It seems very close to possible. Like, "have gcc, will travel"? And nothing else changes? No value then in doing any porting work up front? You know..think of the author of hello world..some highly portable program. Or more realistic example such as bash, awk, make, ld and gcc on a particular host (not target), etc. They don't go around much and port to this or that or the other system. They do a mix of "just try to be portable" and "leave autoconf to figure out". Modula-3 is almost in the same boat? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Jan 17 05:06:18 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 17 Jan 2009 15:06:18 +1100 Subject: [M3devel] how to switch between user and kernel threads.. In-Reply-To: References: <56CF4A94-6620-4A69-B4DC-D72268811AEA@cs.purdue.edu> Message-ID: Please leave it the way it is as an install-time option. -DNOPTHREAD enables user threads. On 16 Jan 2009, at 20:28, Jay wrote: > I was able to easily build this alternate library, just by creating > one small m3makefile and optionally editing one other very little. > I wasn't able to find a way to get it used, other than maybe > shipping it on top of the "real" m3core. > A compiler hack that knows to replace package "m3core" with > "m3coreuserthreads" may be appropriate. > I can look into that. > But I still don't know why not function pointers. > Plenty else to do in the meantime (Cygwin/pthreads, portability, a > bunch of ports..). > > - Jay > > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] how to switch between user and kernel threads.. > Date: Thu, 15 Jan 2009 04:15:43 +0000 > > That would't affected here. > All the calls within ThreadPThread to within ThreadPThread would > remain direct and inlinable. > They would be to the "ThreadPThread" interface, and not the > "Thread" interface, would be my intent. > > How about across modules? > I expect any call from outside ThreadPThread to within > ThreadPThread to never be inlined, at least not when dynamic linking > and with static linking (or within the package/library) not unless > there is "whole program optimization" aka "link time code > generation" with static linking, which does exist out there. > > - Jay > > > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Thu, 15 Jan 2009 14:18:16 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] how to switch between user and kernel threads.. > > We do get inlining within modules by virtue of the gcc-backend at -O3. > > > On 15 Jan 2009, at 14:03, Jay wrote: > > The installer? > I thought the granularity was at the time of linking an executable. > I personally thought a command line parameter would be reasonable. > > > Why not function pointers? > It is a simple straightforward method to implement. > It should add one instruction per call. > It does reduce inlinability but I'm sure we aren't getting any such > such inlinability anyway. > Dynamic linking already kills inlinability, as does separate > compilation of modules in most systems. > > > I'm not sure how the types work out in such a scheme, but probably > assuming Thread.T is already a reference type, it can become ADDRESS > and then loopholed to ThreadPosix.T or ThreadPThread.T. > > > Function pointers are also the easiest method to build. I'm not sure > what the others are. > I can try making m3-libs/m3coreuserthreads that contains only > m3makefiles. > Probably it can say: > LibraryName = "m3coreuserthreads" > include_dir("../m3core/m3makefile") > > > and m3core/m3makefile can say > if not defined("LibraryName") > LibraryName = "m3core" > end > Library(LibraryName) > > > If that works, not bad. > > > And then cm3 or the config file can translate m3core to > m3coreuserthreads at some point. > > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Thu, 15 Jan 2009 11:31:17 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] how to switch between user and kernel threads.. > > > No function pointers please. Let the installer decide whether to > use native or user threads. > > On 15 Jan 2009, at 08:30, Jay wrote: > > I'll wait. > So, build two different m3core.lib/a/so/dylib? > m3core and m3coreuserthreads > > Compile both thread directories, if the platform supports it, and > call quake make_lib twice with slightly different parameters? > An m3core specific hack in the config file or cm3? > Easy enough in the config file. > Very m3core specific. > I suppose you could argue that quake isn't a generic build system, > but it is Modula-3's build system, and that m3core is really special. > > The result btw, would likely be no change at all to any *.i3 or *.m3 > file. > > I still think function pointers are the way to go. > Even with function pointers, the changes to *.i3 and *.m3 would be > very minor. > Just the export list would vary. > And new *.i3 files introduced. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Wed, 14 Jan 2009 21:31:22 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] how to switch between user and kernel threads.. > > I don't want dynamic switching. A link-time switch is just fine. > > Also, please don't go messing about with this right now -- I have > changes pending for the threads system that will be harder to > integrate if you change with it further. > > On 14 Jan 2009, at 20:14, Jay wrote: > > Are people really against using function pointers for this? > Either changing the interface to have function pointer variables > (I'm not sure Modula-3 allows this, but in C you can fairly > transparently replace functions with function pointers; client code > just keeps working; it breaks down in C++ with overloading), or > having a set of functions that just call/jump through function > pointers? There would be no if, no conditional branches. > > Dynamic linking on Windows always goes through function pointers > already. > So while yes it adds another instruction, it is already never > getting inlined. > Don't other platforms do that too? > Or they patch every call site? > > I'm not sure otherwise of a simple method. > Easiest might be to have a parallel directory structure to m3core, > with just m3core files. > That would wastefully rebuild all of m3core a second time, for just > a small amount of variation. > > I think function pointers are the way to go here. > > - Jay > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinbishop at bellsouth.net Sat Jan 17 06:19:51 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Fri, 16 Jan 2009 23:19:51 -0600 Subject: [M3devel] What is M3SU? Message-ID: <49716A77.60405@bellsouth.net> I was reading the FAQ for Modula-3, and noticed they mentioned a program called "m3su". The link they give to an ftp server is no longer available, but with a little poking around I found where it is located at, however they do not have 'm3su' on it anymore. What is (or was?) m3su? From hosking at cs.purdue.edu Sat Jan 17 12:03:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 17 Jan 2009 22:03:19 +1100 Subject: [M3devel] "new old" ports, or no ports at all? In-Reply-To: References: Message-ID: <715A8E4A-CDC4-453B-96F8-67E377E8EDF2@cs.purdue.edu> Historically, there have been non-gcc-based backends. We would not want to preclude those. On 17 Jan 2009, at 00:05, Jay wrote: > Would people mind "new" ports like: > > > HPPA32_HPUX (HPPA_HPUX? There is "HPPA") > I386_FREEBSD (There is FreeBSD4.) > I386_NETBSD (There is NetBSD2_i386.) > MIPS32_IRIX (MIPS_IRIX? There is IRIX5.) > ALPHA_FREEBSD (There FBSD_ALPHA.) > and then for that matter: > SPARC32_SOLARIS, I386_LINUX > > > Or some mix? > This is not hypothetical. I do now have HPPA, Alpha, SGI hardware. :) > > > I can either do the little bit of correct testable valid small etc. > work > of using my "more portable" approach to these platforms, which > gets things up and running easily and fast and perfectly acceptably, > or I could "proofread" all the gunk, I mean cloned headers, fix them > for current system, worry if they break old system, or delete them, > possibly doing some hypothetical damage to the old ports. > > > It seems easier and a better result to "start over" and leave the > old stuff alone, > maybe delete it, depending on what people think of history > preservation and > history vs. deletes (deleted stuff isn't very visible). > > > Or maybe hardly any of this matters. Nobody uses these platforms or > anything like them? > (I recall Randy saying he is still using 4.1 on HP-UX though. I'm on > a fun little > long running errand here of getting not ancient but not current > systems.. :) ) > > > The "4", "2", "5" in FreeBSD4, NetBSD2_i386, IRIX5 make them seen > somewhat "wrong". > > > The "4" in FreeBSD4 (err, in i686-freebsd4) does have a surprising > semantic, in the backend..but maybe not. > C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(53): > builtin_define_with_int_value ("__FreeBSD__", FBSD_MAJOR); \ > C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(122):#if > FBSD_MAJOR < 5 > C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(141):#if > FBSD_MAJOR < 6 > > > though I think if you look closely, these don't matter to us. > They affect the gcc driver and the C/C++ front end, but maybe not > the m3cg backend. > > > Even the "LIBC6" in "LINUXLIBC6" seems dubious, because, for > example, I am > tempted to make "ARM_LINUX_UCLIBC", which suggests either that > there might be an "I386_LINUX_UCLIBC" or "generic" "I386_LINUX" that > is portable across libc6/uclibc/dietlibc/newlib either by seeing > what they have in common, or skipping them and using the kernel > interfaces > more directly. > > > There is another angle here. > To what extent is the compiler platform specific? > (I mostly know the answer to this. It is a leading question.) > Could ports go away? > Almost? > > > Historically there were a bunch of platform-specific .i3 files. > That is dwindling much in some platforms and could dwindle much > overall. > A little more C code in the system and the Modula-3 .i3 files are > all "portable". > > > It ends up being, roughly, that there is: > > > endian, and even this is often not an issue; I saw like > one reference in the compiler to it, and there is a little bit in > m3core/libm3 > The byte swap functions and maybe the Float stuff (there is > endian specific > and generic stuff, not all is used). > It would affect e.g. the layout of the Uexec types, but they are > gone. > Such endian-specificity could occur anywhere but maybe "cm3 - > generic" errors for it? > > > word size -- 32bit or 64bit. There is no escaping this, as long as > there are any 32bit platforms. > So ok, two ports, 32bit and 64bit. That's a small matrix. > > > IEEE or not -- everything is IEEE now. I don't plan on getting a > VAX. :) > (The compiler seems suspicious here wrt cross building.) > > > The name of setjmp. > However this could be made the same everywhere -- m3_setjmp or > M3Try or M3SaveState, > and use an #ifdef .c file to decide. > > > The size of the jmpbuf. Ah, there's the rub. > A "generic" platform could blow up the size of the jmpbuf to > something that works > on all known platforms. Very very wasteful. Some platforms have > tiny, some have huge. > > > I'm not sure where stack layout is done. If the front end does it > or not. > You could imagine something like M3Try allocating the same..but > this seems bad. > If the front end defers enough work to the backend, you could > introduce an abstracted > notion of the jmpbuf and leave it to m3cg to fill in? Leave it to > #ifdef on the target? > m3cg, in its current form as gcc based is always going to have be > configured to be > target specific. > > > Or all platforms could have stack walkers and this platform- > specificity would go away. > But that is a very long ways off, if ever. > > > My point is, you know, can we in fact eliminate the notion of > porting? > At least of cm3 knowing anything about the target, and only m3cg? > Because the system is nearly portable enough? All that is left is > configuring gcc? > It seems very close to possible. > > > Like, "have gcc, will travel"? > And nothing else changes? > No value then in doing any porting work up front? > > > You know..think of the author of hello world..some highly portable > program. > Or more realistic example such as bash, awk, make, ld and gcc on a > particular host (not target), etc. > They don't go around much and port to this or that or the other > system. > They do a mix of "just try to be portable" and "leave autoconf to > figure out". > > > Modula-3 is almost in the same boat? > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jan 17 12:36:39 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 17 Jan 2009 11:36:39 +0000 Subject: [M3devel] "new old" ports, or no ports at all? In-Reply-To: <715A8E4A-CDC4-453B-96F8-67E377E8EDF2@cs.purdue.edu> References: <715A8E4A-CDC4-453B-96F8-67E377E8EDF2@cs.purdue.edu> Message-ID: Ah -- you mean if there more integrated backends written in Modula-3, then it would become "impossible" to push such knowledge of the target as its processor, endianness, etc. out of cm3? Or rather, it would be /possible/, but it would be counterproductive. That makes sense. Good point. But that could be added back. if platform = "nt386" UseIntegratedBackend(); else if ... ... else gcc backend handles it (almost) all ? No need, perhaps, for a big enum and switch. Just about. You know..as it stands..cm3 knows just a little about each target, and it doesn't even use all it knows kinda. Word size it uses in computing layout. Endianness it uses rarely I think. "aligned procedures" it uses in about one place. Some of the data in Target.i3 was unused and I removed it. I guess nevermind. I'm just thinking about, you know, declaring all ports either done, or so trivial that there is little point in doing one until someone needs it, merely tedium. That isn't actually the case yet -- there should be C program(s) to generate the "residue", Usysdep.i3, Csetjmp.i3, etc. The other backends are the NT386 one, and it adapted to Linux/x86, right? And maybe what used to generate C? (Can someone give me details as to why C generation isn't a great idea?) - Jay ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] "new old" ports, or no ports at all? > Date: Sat, 17 Jan 2009 22:03:19 +1100 > > Historically, there have been non-gcc-based backends. We would not want to preclude those. > > On 17 Jan 2009, at 00:05, Jay wrote: > > Would people mind "new" ports like: > > > HPPA32_HPUX (HPPA_HPUX? There is "HPPA") > I386_FREEBSD (There is FreeBSD4.) > I386_NETBSD (There is NetBSD2_i386.) > MIPS32_IRIX (MIPS_IRIX? There is IRIX5.) > ALPHA_FREEBSD (There FBSD_ALPHA.) > and then for that matter: > SPARC32_SOLARIS, I386_LINUX > > > Or some mix? > This is not hypothetical. I do now have HPPA, Alpha, SGI hardware. :) > > > I can either do the little bit of correct testable valid small etc. work > of using my "more portable" approach to these platforms, which > gets things up and running easily and fast and perfectly acceptably, > or I could "proofread" all the gunk, I mean cloned headers, fix them > for current system, worry if they break old system, or delete them, > possibly doing some hypothetical damage to the old ports. > > > It seems easier and a better result to "start over" and leave the old stuff alone, > maybe delete it, depending on what people think of history preservation and > history vs. deletes (deleted stuff isn't very visible). > > > Or maybe hardly any of this matters. Nobody uses these platforms or anything like them? > (I recall Randy saying he is still using 4.1 on HP-UX though. I'm on a fun little > long running errand here of getting not ancient but not current systems.. :) ) > > > The "4", "2", "5" in FreeBSD4, NetBSD2_i386, IRIX5 make them seen somewhat "wrong". > > > The "4" in FreeBSD4 (err, in i686-freebsd4) does have a surprising semantic, in the backend..but maybe not. > C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(53): builtin_define_with_int_value ("__FreeBSD__", FBSD_MAJOR); \ > C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(122):#if FBSD_MAJOR < 5 > C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(141):#if FBSD_MAJOR < 6 > > > though I think if you look closely, these don't matter to us. > They affect the gcc driver and the C/C++ front end, but maybe not the m3cg backend. > > > Even the "LIBC6" in "LINUXLIBC6" seems dubious, because, for example, I am > tempted to make "ARM_LINUX_UCLIBC", which suggests either that > there might be an "I386_LINUX_UCLIBC" or "generic" "I386_LINUX" that > is portable across libc6/uclibc/dietlibc/newlib either by seeing > what they have in common, or skipping them and using the kernel interfaces > more directly. > > > There is another angle here. > To what extent is the compiler platform specific? > (I mostly know the answer to this. It is a leading question.) > Could ports go away? > Almost? > > > Historically there were a bunch of platform-specific .i3 files. > That is dwindling much in some platforms and could dwindle much overall. > A little more C code in the system and the Modula-3 .i3 files are all "portable". > > > It ends up being, roughly, that there is: > > > endian, and even this is often not an issue; I saw like > one reference in the compiler to it, and there is a little bit in m3core/libm3 > The byte swap functions and maybe the Float stuff (there is endian specific > and generic stuff, not all is used). > It would affect e.g. the layout of the Uexec types, but they are gone. > Such endian-specificity could occur anywhere but maybe "cm3 -generic" errors for it? > > > word size -- 32bit or 64bit. There is no escaping this, as long as there are any 32bit platforms. > So ok, two ports, 32bit and 64bit. That's a small matrix. > > > IEEE or not -- everything is IEEE now. I don't plan on getting a VAX. :) > (The compiler seems suspicious here wrt cross building.) > > > The name of setjmp. > However this could be made the same everywhere -- m3_setjmp or M3Try or M3SaveState, > and use an #ifdef .c file to decide. > > > The size of the jmpbuf. Ah, there's the rub. > A "generic" platform could blow up the size of the jmpbuf to something that works > on all known platforms. Very very wasteful. Some platforms have tiny, some have huge. > > > I'm not sure where stack layout is done. If the front end does it or not. > You could imagine something like M3Try allocating the same..but this seems bad. > If the front end defers enough work to the backend, you could introduce an abstracted > notion of the jmpbuf and leave it to m3cg to fill in? Leave it to #ifdef on the target? > m3cg, in its current form as gcc based is always going to have be configured to be > target specific. > > > Or all platforms could have stack walkers and this platform-specificity would go away. > But that is a very long ways off, if ever. > > > My point is, you know, can we in fact eliminate the notion of porting? > At least of cm3 knowing anything about the target, and only m3cg? > Because the system is nearly portable enough? All that is left is configuring gcc? > It seems very close to possible. > > > Like, "have gcc, will travel"? > And nothing else changes? > No value then in doing any porting work up front? > > > You know..think of the author of hello world..some highly portable program. > Or more realistic example such as bash, awk, make, ld and gcc on a particular host (not target), etc. > They don't go around much and port to this or that or the other system. > They do a mix of "just try to be portable" and "leave autoconf to figure out". > > > Modula-3 is almost in the same boat? > > > - Jay > > From hosking at cs.purdue.edu Sat Jan 17 12:45:30 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 17 Jan 2009 22:45:30 +1100 Subject: [M3devel] What is M3SU? In-Reply-To: <49716A77.60405@bellsouth.net> References: <49716A77.60405@bellsouth.net> Message-ID: <1548D817-74A6-4411-8DBB-2CACA3C744CA@cs.purdue.edu> Never heard of it. 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 17 Jan 2009, at 16:19, Martin Bishop wrote: > I was reading the FAQ for Modula-3, and noticed they mentioned a > program > called "m3su". The link they give to an ftp server is no longer > available, but with a little poking around I found where it is located > at, however they do not have 'm3su' on it anymore. > > What is (or was?) m3su? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Jan 17 12:48:33 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 17 Jan 2009 22:48:33 +1100 Subject: [M3devel] "new old" ports, or no ports at all? In-Reply-To: References: <715A8E4A-CDC4-453B-96F8-67E377E8EDF2@cs.purdue.edu> Message-ID: <58149067-89DE-4D73-A4E4-BF48C1A9A776@cs.purdue.edu> There were BURS backends too. And C is not good for source-level debugging. On 17 Jan 2009, at 22:36, Jay wrote: > > Ah -- you mean if there more integrated backends written in > Modula-3, then it would become "impossible" to push such knowledge > of the target as its processor, endianness, etc. out of cm3? > Or rather, it would be /possible/, but it would be counterproductive. > That makes sense. Good point. > But that could be added back. > > > if platform = "nt386" > UseIntegratedBackend(); > else if ... > ... > else > gcc backend handles it (almost) all ? > > > No need, perhaps, for a big enum and switch. > Just about. > > > You know..as it stands..cm3 knows just a little about each target, > and it doesn't even use all it knows kinda. Word size it uses in > computing layout. Endianness it uses rarely I think. "aligned > procedures" it uses in about one place. Some of the data in > Target.i3 was unused and I removed it. I guess nevermind. I'm just > thinking about, you know, declaring all ports either done, or so > trivial that there is little point in doing one until someone needs > it, merely tedium. That isn't actually the case yet -- there should > be C program(s) to generate the "residue", Usysdep.i3, Csetjmp.i3, > etc. > > > The other backends are the NT386 one, and it adapted to Linux/x86, > right? > And maybe what used to generate C? > (Can someone give me details as to why C generation isn't a great > idea?) > > > - Jay > > > > ________________________________ >> CC: m3devel at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Subject: Re: [M3devel] "new old" ports, or no ports at all? >> Date: Sat, 17 Jan 2009 22:03:19 +1100 >> >> Historically, there have been non-gcc-based backends. We would not >> want to preclude those. >> >> On 17 Jan 2009, at 00:05, Jay wrote: >> >> Would people mind "new" ports like: >> >> >> HPPA32_HPUX (HPPA_HPUX? There is "HPPA") >> I386_FREEBSD (There is FreeBSD4.) >> I386_NETBSD (There is NetBSD2_i386.) >> MIPS32_IRIX (MIPS_IRIX? There is IRIX5.) >> ALPHA_FREEBSD (There FBSD_ALPHA.) >> and then for that matter: >> SPARC32_SOLARIS, I386_LINUX >> >> >> Or some mix? >> This is not hypothetical. I do now have HPPA, Alpha, SGI hardware. :) >> >> >> I can either do the little bit of correct testable valid small etc. >> work >> of using my "more portable" approach to these platforms, which >> gets things up and running easily and fast and perfectly acceptably, >> or I could "proofread" all the gunk, I mean cloned headers, fix them >> for current system, worry if they break old system, or delete them, >> possibly doing some hypothetical damage to the old ports. >> >> >> It seems easier and a better result to "start over" and leave the >> old stuff alone, >> maybe delete it, depending on what people think of history >> preservation and >> history vs. deletes (deleted stuff isn't very visible). >> >> >> Or maybe hardly any of this matters. Nobody uses these platforms or >> anything like them? >> (I recall Randy saying he is still using 4.1 on HP-UX though. I'm >> on a fun little >> long running errand here of getting not ancient but not current >> systems.. :) ) >> >> >> The "4", "2", "5" in FreeBSD4, NetBSD2_i386, IRIX5 make them seen >> somewhat "wrong". >> >> >> The "4" in FreeBSD4 (err, in i686-freebsd4) does have a surprising >> semantic, in the backend..but maybe not. >> C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(53): >> builtin_define_with_int_value ("__FreeBSD__", FBSD_MAJOR); \ >> C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(122):#if >> FBSD_MAJOR < 5 >> C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(141):#if >> FBSD_MAJOR < 6 >> >> >> though I think if you look closely, these don't matter to us. >> They affect the gcc driver and the C/C++ front end, but maybe not >> the m3cg backend. >> >> >> Even the "LIBC6" in "LINUXLIBC6" seems dubious, because, for >> example, I am >> tempted to make "ARM_LINUX_UCLIBC", which suggests either that >> there might be an "I386_LINUX_UCLIBC" or "generic" "I386_LINUX" that >> is portable across libc6/uclibc/dietlibc/newlib either by seeing >> what they have in common, or skipping them and using the kernel >> interfaces >> more directly. >> >> >> There is another angle here. >> To what extent is the compiler platform specific? >> (I mostly know the answer to this. It is a leading question.) >> Could ports go away? >> Almost? >> >> >> Historically there were a bunch of platform-specific .i3 files. >> That is dwindling much in some platforms and could dwindle much >> overall. >> A little more C code in the system and the Modula-3 .i3 files are >> all "portable". >> >> >> It ends up being, roughly, that there is: >> >> >> endian, and even this is often not an issue; I saw like >> one reference in the compiler to it, and there is a little bit in >> m3core/libm3 >> The byte swap functions and maybe the Float stuff (there is endian >> specific >> and generic stuff, not all is used). >> It would affect e.g. the layout of the Uexec types, but they are >> gone. >> Such endian-specificity could occur anywhere but maybe "cm3 - >> generic" errors for it? >> >> >> word size -- 32bit or 64bit. There is no escaping this, as long as >> there are any 32bit platforms. >> So ok, two ports, 32bit and 64bit. That's a small matrix. >> >> >> IEEE or not -- everything is IEEE now. I don't plan on getting a >> VAX. :) >> (The compiler seems suspicious here wrt cross building.) >> >> >> The name of setjmp. >> However this could be made the same everywhere -- m3_setjmp or >> M3Try or M3SaveState, >> and use an #ifdef .c file to decide. >> >> >> The size of the jmpbuf. Ah, there's the rub. >> A "generic" platform could blow up the size of the jmpbuf to >> something that works >> on all known platforms. Very very wasteful. Some platforms have >> tiny, some have huge. >> >> >> I'm not sure where stack layout is done. If the front end does it >> or not. >> You could imagine something like M3Try allocating the same..but >> this seems bad. >> If the front end defers enough work to the backend, you could >> introduce an abstracted >> notion of the jmpbuf and leave it to m3cg to fill in? Leave it to >> #ifdef on the target? >> m3cg, in its current form as gcc based is always going to have be >> configured to be >> target specific. >> >> >> Or all platforms could have stack walkers and this platform- >> specificity would go away. >> But that is a very long ways off, if ever. >> >> >> My point is, you know, can we in fact eliminate the notion of >> porting? >> At least of cm3 knowing anything about the target, and only m3cg? >> Because the system is nearly portable enough? All that is left is >> configuring gcc? >> It seems very close to possible. >> >> >> Like, "have gcc, will travel"? >> And nothing else changes? >> No value then in doing any porting work up front? >> >> >> You know..think of the author of hello world..some highly portable >> program. >> Or more realistic example such as bash, awk, make, ld and gcc on a >> particular host (not target), etc. >> They don't go around much and port to this or that or the other >> system. >> They do a mix of "just try to be portable" and "leave autoconf to >> figure out". >> >> >> Modula-3 is almost in the same boat? >> >> >> - Jay >> >> From eiserlohpp at yahoo.com Sun Jan 18 04:09:35 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sat, 17 Jan 2009 19:09:35 -0800 (PST) Subject: [M3devel] Multiple CM3_ROOTs Message-ID: <495761.443.qm@web56802.mail.re3.yahoo.com> Hi Tony and Gang, The hypothetical scenario is a system providing multiple user accounts. The sysadmin will install a released version of CM3, not a daily snapshot. Any user should be able to install a daily snapshot, and old one, or a custom version, for their particular use. This would go within a directory of their choosing (within their personal HOME). These users, may have many customized versions of libm3 (and m3core), and hence many installations of an M3 compiler. A git repository has already been imported from the main CVS repository at elego. Any user (at the moment thats just me) may create any number of branches and play with the code. How can I ship to a different CM3_ROOT, than the one that built it? When using a different CM3_ROOT than the standard one, the user would obviously have to set their PATH and CM3 environment variables appropriately. How does the cm3 compiler frontend know the path to its config file? Does it walk argv[0] up the directory chain, and use the PATH to find itself, or is the path build-in? Does it use the environment variable CM3 if found? +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From dabenavidesd at yahoo.es Sun Jan 18 05:50:16 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 17 Jan 2009 20:50:16 -0800 (PST) Subject: [M3devel] Multiple CM3_ROOTs In-Reply-To: <495761.443.qm@web56802.mail.re3.yahoo.com> Message-ID: <224644.55641.qm@web24707.mail.ird.yahoo.com> Hi Peter: what I learned is that the cm3 compiler finds it's config file in the same directory of the cm3 compiler executable, otherwise it reports an error (about it). I know from cm3 -? that: from http://www.opencm3.net/doc/help/cm3/cm3-quickref.html environment variables: M3CONFIG platform dependent configuration file to use (cm3.cfg) used if no suitable file is found in the local packageHowever I don't how can be used the compiler to ship and compile according the abstracted config files made by Jay specially in the NT386 and derived platforms (I guess would be nice to set that in the command itself like select to alternative not common configurations of graphic libs? or back ends, etc, ...) with the same libm3 and m3core. Thanks in advance --- El s?b, 17/1/09, Peter Eiserloh escribi?: De: Peter Eiserloh Asunto: [M3devel] Multiple CM3_ROOTs Para: m3devel at elegosoft.com Fecha: s?bado, 17 enero, 2009 10:09 Hi Tony and Gang, The hypothetical scenario is a system providing multiple user accounts. The sysadmin will install a released version of CM3, not a daily snapshot. Any user should be able to install a daily snapshot, and old one, or a custom version, for their particular use. This would go within a directory of their choosing (within their personal HOME). These users, may have many customized versions of libm3 (and m3core), and hence many installations of an M3 compiler. A git repository has already been imported from the main CVS repository at elego. Any user (at the moment thats just me) may create any number of branches and play with the code. How can I ship to a different CM3_ROOT, than the one that built it? When using a different CM3_ROOT than the standard one, the user would obviously have to set their PATH and CM3 environment variables appropriately. How does the cm3 compiler frontend know the path to its config file? Does it walk argv[0] up the directory chain, and use the PATH to find itself, or is the path build-in? Does it use the environment variable CM3 if found? +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 18 10:04:57 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 18 Jan 2009 09:04:57 +0000 Subject: [M3devel] Multiple CM3_ROOTs In-Reply-To: <224644.55641.qm@web24707.mail.ird.yahoo.com> References: <495761.443.qm@web56802.mail.re3.yahoo.com> <224644.55641.qm@web24707.mail.ird.yahoo.com> Message-ID: I didn't change how the compiler "starts", how it finds the first config file. Config files can go off and include others. The below sounds slightly wrong. I believe the M3CONFIG environment variable is checked before the cm3.cfg file "next to" cm3 is used. What I do is my cm3.cfg "next to" cm3 then goes and looks for the "real" config file. It is guided by - knowing where the source tree is, via the environment variable CM3_ROOT - knowing the host, via the HOST variable that I added to cm3 - if HOST isn't defined, it generally fails, except on NT it can use the OS environment variable. CM3_INSTALL or INSTALLROOT is the root of the cm3 installation. CM3_ROOT or ROOT is the root of the cm3 source tree. I don't find these names ideal, but I also am not super keen on changing them. Clearer and more consistent would be CM3_INSTALL_ROOT and CM3_SOURCE_ROOT. Within quake are available variables without the leading "CM3_". Environment variables with leading "CM3_" I think are the way to go. And that is /generally/ how it works, but not necessarily exactly. Also, my cm3.cfg sets INSTALLROOT based on its own location. To learn how to ship to another root... My make-dist.py accomplishes this. I think the way it works though is it copies cm3 out to a new location and runs it from there. And the cm3.cfg. INSTALLROOT or CM3_INSTALL is therefore the location of wherever cm3 is copied to and run from. Personally I think the system is somewhat misdesigned. Regarding link output and shipped output, there should just be one place. The only point in a two step link and ship/install is if you are installing over a live system. A simpler better approach is to always use a new or staging area for the link output, and if you are happy with it, you merely do a recursive copy on top of your live system. Or, you change PATH to point to the new cm3 and adopt it as your new system. This also addresses the problem that cm3 can't ship itself. This also could be part of giving an alternate location for the "intermediate" outputs that never shipped -- the .obj file. They should not litter the source tree. You know, on a package basis, Modula-3 is/was progressive in that not only does it support "out of source" builds, but it only supports them. And you can cons up arbitrary new intermediate locations on demand by changing BUILD_DIR. Though sometimes assumptions creep in that BUILD_DIR == TARGET. However, if you consider multiple packages, then the intermediate outputs actually are in the source tree. There aren't many very visible analogs in the world. However one is how gcc builds. It ties together multiple packages (optionally) and all the outputs go outside of the entire source tree. - Jay ________________________________ > Date: Sat, 17 Jan 2009 20:50:16 -0800 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com; eiserlohpp at yahoo.com > Subject: Re: [M3devel] Multiple CM3_ROOTs > > Hi Peter: > what I learned is that the cm3 compiler finds it's config file in the same directory of the cm3 compiler executable, otherwise it reports an error (about it). > I know from cm3 -? that: > from http://www.opencm3.net/doc/help/cm3/cm3-quickref.html > environment variables: > > M3CONFIG platform dependent configuration file to use (cm3.cfg) > used if no suitable file is found in the local package > > However I don't how can be used the compiler to ship and compile according the abstracted config files made by Jay specially in the NT386 and derived platforms (I guess would be nice to set that in the command itself like select to alternative not common configurations of graphic libs or back ends, etc, ...) with the same libm3 and m3core. > > Thanks in advance > --- El s?b, 17/1/09, Peter Eiserloh > escribi?: > De: Peter Eiserloh > Asunto: [M3devel] Multiple CM3_ROOTs > Para: m3devel at elegosoft.com > Fecha: s?bado, 17 enero, 2009 10:09 > > > Hi Tony and Gang, > > The hypothetical scenario is a system providing multiple > user accounts. The sysadmin will install a released > version of CM3, not a daily snapshot. Any user should be > able to install a daily snapshot, and old one, or a custom > version, for their particular use. This would go within > a directory of their choosing (within their personal HOME). > > These users, may have many customized versions of libm3 > (and m3core), and hence many installations of an M3 > compiler. > > A git repository has already been imported from the main > CVS repository at elego. Any user (at the moment > thats > just me) may create any number of branches and play with > the code. > > How can I ship to a different CM3_ROOT, than the one that > built it? > > When using a different CM3_ROOT than the standard one, the > user would obviously have to set their PATH and CM3 > environment variables appropriately. How does the cm3 > compiler frontend know the path to its config file? > Does it walk argv[0] up the directory chain, and use the > PATH to find itself, or is the path build-in? Does it use > the environment variable CM3 if found? > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > > > From jay.krell at cornell.edu Mon Jan 19 13:47:15 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 19 Jan 2009 12:47:15 +0000 Subject: [M3devel] "new old" ports, or no ports at all? In-Reply-To: <49706962.1E75.00D7.1@scires.com> References: <49706962.1E75.00D7.1@scires.com> Message-ID: I assume they can run 64bit? My system can/is. I have to research if 1.1 is 32bit, 2.0 is 64bit, or if there is a larger matrix. Any preference among "HPPA64_HPUX" vs. "PA64_HPUX" -- the double "HP" is kind of redundant. The minimum gcc configuration names I found to work are hppa64-hpux11 and presumably hppa-hpux11. The major version is required, else configure errors out "unsupported". Similarly: reusing existing "HPPA" or introduce "HPPA32_HPUX" or "PA32_HPUX"? My inclination is PA32_HPUX, PA64_HPUX, but any is ok. "PA" is shorter, but "HPPA64" is not record settingly long -- we have "SPARC64", and "SPARC32" that I introduced. The names will then apply to *_LINUX as well. Also you must have GNU as for this port. m3cc/src/m3makefile indicates that was already the case for the old HPPA. gcc 3.3.6 is ok with the HP assembler, though I don't remember if -g worked. But gcc 4.3.2 is not ok with the HP assembler. - Jay ________________________________ > Date: Fri, 16 Jan 2009 11:04:53 -0500 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] "new old" ports, or no ports at all? > > > > > > > > > > Jay: > > > > I do have some HP-UX machines that I could use to test whatever you come up with for HPPA. You are correct that right now I run cm3 v4.1 on these. I have not tried to move beyond 4.1 on them yet. > > > > Regards, > > Randy > >>>> Jay 1/16/2009 8:05 AM>>> > Would people mind "new" ports like: > > > HPPA32_HPUX (HPPA_HPUX? There is "HPPA") > I386_FREEBSD (There is FreeBSD4.) > I386_NETBSD (There is NetBSD2_i386.) > MIPS32_IRIX (MIPS_IRIX? There is IRIX5.) > ALPHA_FREEBSD (There FBSD_ALPHA.) > and then for that matter: > SPARC32_SOLARIS, I386_LINUX > > > Or some mix? > This is not hypothetical. I do now have HPPA, Alpha, SGI hardware. :) > > > I can either do the little bit of correct testable valid small etc. work > of using my "more portable" approach to these platforms, which > gets things up and running easily and fast and perfectly acceptably, > or I could "proofread" all the gunk, I mean cloned headers, fix them > for current system, worry if they break old system, or delete them, > possibly doing some hypothetical damage to the old ports. > > > It seems easier and a better result to "start over" and leave the old stuff alone, > maybe delete it, depending on what people think of history preservation and > history vs. deletes (deleted stuff isn't very visible). > > > Or maybe hardly any of this matters. Nobody uses these platforms or anything like them? > (I recall Randy saying he is still using 4.1 on HP-UX though. I'm on a fun little > long running errand here of getting not ancient but not current systems.. :) ) > > > The "4", "2", "5" in FreeBSD4, NetBSD2_i386, IRIX5 make them seen somewhat "wrong". > > > The "4" in FreeBSD4 (err, in i686-freebsd4) does have a surprising semantic, in the backend..but maybe not. > C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(53): builtin_define_with_int_value ("__FreeBSD__", FBSD_MAJOR); \ > C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(122):#if FBSD_MAJOR < 5 > C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(141):#if FBSD_MAJOR < 6 > > > though I think if you look closely, these don't matter to us. > They affect the gcc driver and the C/C++ front end, but maybe not the m3cg backend. > > > Even the "LIBC6" in "LINUXLIBC6" seems dubious, because, for example, I am > tempted to make "ARM_LINUX_UCLIBC", which suggests either that > there might be an "I386_LINUX_UCLIBC" or "generic" "I386_LINUX" that > is portable across libc6/uclibc/dietlibc/newlib either by seeing > what they have in common, or skipping them and using the kernel interfaces > more directly. > > > There is another angle here. > To what extent is the compiler platform specific? > (I mostly know the answer to this. It is a leading question.) > Could ports go away? > Almost? > > > Historically there were a bunch of platform-specific .i3 files. > That is dwindling much in some platforms and could dwindle much overall. > A little more C code in the system and the Modula-3 .i3 files are all "portable". > > > It ends up being, roughly, that there is: > > > endian, and even this is often not an issue; I saw like > one reference in the compiler to it, and there is a little bit in m3core/libm3 > The byte swap functions and maybe the Float stuff (there is endian specific > and generic stuff, not all is used). > It would affect e.g. the layout of the Uexec types, but they are gone. > Such endian-specificity could occur anywhere but maybe "cm3 -generic" errors for it? > > > word size -- 32bit or 64bit. There is no escaping this, as long as there are any 32bit platforms. > So ok, two ports, 32bit and 64bit. That's a small matrix. > > > IEEE or not -- everything is IEEE now. I don't plan on getting a VAX. :) > (The compiler seems suspicious here wrt cross building.) > > > The name of setjmp. > However this could be made the same everywhere -- m3_setjmp or M3Try or M3SaveState, > and use an #ifdef .c file to decide. > > > The size of the jmpbuf. Ah, there's the rub. > A "generic" platform could blow up the size of the jmpbuf to something that works > on all known platforms. Very very wasteful. Some platforms have tiny, some have huge. > > > I'm not sure where stack layout is done. If the front end does it or not. > You could imagine something like M3Try allocating the same..but this seems bad. > If the front end defers enough work to the backend, you could introduce an abstracted > notion of the jmpbuf and leave it to m3cg to fill in? Leave it to #ifdef on the target? > m3cg, in its current form as gcc based is always going to have be configured to be > target specific. > > > Or all platforms could have stack walkers and this platform-specificity would go away. > But that is a very long ways off, if ever. > > > My point is, you know, can we in fact eliminate the notion of porting? > At least of cm3 knowing anything about the target, and only m3cg? > Because the system is nearly portable enough? All that is left is configuring gcc? > It seems very close to possible. > > > Like, "have gcc, will travel"? > And nothing else changes? > No value then in doing any porting work up front? > > > You know..think of the author of hello world..some highly portable program. > Or more realistic example such as bash, awk, make, ld and gcc on a particular host (not target), etc. > They don't go around much and port to this or that or the other system. > They do a mix of "just try to be portable" and "leave autoconf to figure out". > > > Modula-3 is almost in the same boat? > > > - Jay > From wagner at elegosoft.com Mon Jan 19 16:09:21 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 19 Jan 2009 16:09:21 +0100 Subject: [M3devel] What is M3SU? In-Reply-To: <49716A77.60405@bellsouth.net> References: <49716A77.60405@bellsouth.net> Message-ID: <20090119160921.s5v4nsv3j4g4g0oo@mail.elegosoft.com> Quoting Martin Bishop : > I was reading the FAQ for Modula-3, and noticed they mentioned a program > called "m3su". The link they give to an ftp server is no longer > available, but with a little poking around I found where it is located > at, however they do not have 'm3su' on it anymore. > > What is (or was?) m3su? The FAQ says it is an emcas macro package; I've never used it AFAIK. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jan 19 23:39:34 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 19 Jan 2009 22:39:34 +0000 Subject: [M3devel] move to version 5.7.1? Message-ID: 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 rcoleburn at scires.com Tue Jan 20 00:50:40 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 19 Jan 2009 18:50:40 -0500 Subject: [M3devel] move to version 5.7.1? In-Reply-To: References: Message-ID: <4974CB61.1E75.00D7.1@scires.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jan 20 03:28:07 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 20 Jan 2009 02:28:07 +0000 Subject: [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: 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 jay.krell at cornell.edu Tue Jan 20 07:03:09 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 20 Jan 2009 06:03:09 +0000 Subject: [M3devel] ship vs. where build outputs go, etc.? In-Reply-To: References: <4974CB61.1E75.00D7.1@scires.com> Message-ID: > [was truncated and forward to m3commit instead of m3devel, now more content/drivel..] ps: >> 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. "Clean" doesn't really work imho..I guess it deletes the output files that the compiler knows about? Perhaps it is a bug when the config file doesn't tell it about all the outputs? "realclean" deletes the entire output directory, no matter what files it thinks it produced. It does assume they are all in the particular directory that they strongly tend to be in. It's dumb imho. Clean should probably be fixed. The m3-sys/m3cc directory and probably m3gdb also have their own special in-between state of "configure having been one", that they create a marker file to indicate. And then there is an environment variable to override that. Quake is a fairly general purpose language including the ability to read environment variables, so various directories are free to do whatever they want. m3cc and m3gdb are two of the longest to build package and configuration is also a slow step, that "rarely" has different output, so going back only to this "partly built" state perhaps is interesting. I rarely do that, at least on purpose. The Linux kernel and ucLibc (an alternative C runtime) do something similar. They store their configuration in file starting with a dot, so that on Unix rm -rf * won't delete it, because it skips "hidden" "dot" files. As well you can define arbitrary things on the cm3 command line, to guide arbitrary decisions around the tree, such as kernel vs. user threads. Given foo\src build outputs are generally in foo\target where "outputs" include "intermediate" files such as object files and "final" outputs such as executables and .dlls. You know...really I think, it's just that the Modula-3 folks knew/thought they were smarter than everyone else and made up their own terminology. In many other projects you have "make" and "make install". "ship" is "make install". I think that is all people need to know: "ship" == "install". It copies some of the outputs from foo\target to the installroot. Just as "make install" copies some of the outputs from the "intermediate" tree to the "live" tree. They can both be "dangerous" on a live system, and they can both be pointed at "new" empty location for safety (typical GNU make/automake/autoconf install option is make install DESTDIR=somewhere). I propose a different model. Always put the "final" outputs directly in a "live" tree, BUT for the case where you are doing something "risky" and would not immediately "ship" / "install", you would be encouraged to define a new clean output root, or an existing "test" root. "Actual install" would then be just a recursive copy from one root to another. Perhaps that is too inefficient? cm3 tries to do an incremental copy for example. I'm not sure if it is timestamp based or if they compare entire file contents. The downside to this proposal is that source files also get shipped, and doing that for every compile/link is wasteful. This is optional though and maybe can/should be turned off except when "making a distribution"? I'm not sure how optional it is. I'll try out turning it off locally. An upside to this proposal is it supercedes the "override" mechanism. You would never need to "override". "override" imho is broken because today, in order to keep "override" working, you are expected to encode the source tree structure all over the place. This seems redundant. Perhaps another idea would be for CM3_INSTALL to be colon/semicolon delimited? Search multiple package stores? That offers functionality not in the current model. A related proposal I have is that even the intermediate files be relocated. As I said, on a package-by-package basis, they are not in the source tree. Good. But on a multi-package basis, they are. Not good. I want the source tree to have no outputs, to stay "clean", unless I edit a file. Concretely this all looks like: 1) There is already the CM3_INSTALL environment variable. That is where "binaries" should be output, in the same structure that "ship" uses today. 2) There shall be a new environment variable, something like CM3_OBJECT_ROOT. 3) The existing CM3_ROOT that is the root of the source tree shall come into play. Given building in CM3_ROOT/foo/bar output shall go into: CM3_OBJECT_ROOT/foo/bar/target or maybe CM3_OBJECT_ROOT/target/foo/bar or maybe CM3_OBJECT_ROOT/foo/bar instead of CM3_ROOT/foo/bar/target. If you are not building under CM3_ROOT, there are a few viable options. 1) Do things as they are today. 2) Form up a form of CM3_OBJECT_ROOT/the path you are building that is valid and predictable. For example, in Windows, given a full path with a colon in it, remove the colon and you have a valid relative path you can append to another root. 3) Give user a way to specify what their "root" or "relative path from root" is. Because outputs litter the source tree today..unless you engage in changing BUILD_DIR, which maybe is the way in a few ways actually..you can't do multiple concurrent builds of the same target, such as with a different %PATH% to a different cm3.exe. Now, there is already BUILD_DIR. Perhaps all this is as simple as a change in the config file, changing BUILD_DIR to something like CM3_ROOT/path_of(foo.m3)/TARGET. I'll try that later. Maybe it just works. ? I'm not confident it'll work but maybe. Am I crazy? Wrong? Too disruptive? Most likely the last. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3commit at elegosoft.com; rcoleburn at scires.com > Date: Tue, 20 Jan 2009 05:40:07 +0000 > Subject: [M3commit] FW: [M3devel] move to version 5.7.1? > > > [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 jay.krell at cornell.edu Tue Jan 20 13:20:03 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 20 Jan 2009 12:20:03 +0000 Subject: [M3devel] win32 vs. Posix struct_linger code backwards?? Message-ID: Isn't this highly suspicious? It looks like Win32 turns "linger" off, and Posix turns it on. Win32: PROCEDURE InitSock (sock: WinSock.SOCKET) = (* We assume that the runtime ignores SIGPIPE signals *) (* LL = mu *) VAR one := 1; linger := WinSock.struct_linger{0, 0}; BEGIN (***** EVAL WinSock.setsockopt (sock, WinSock.SOL_SOCKET, WinSock.SO_SNDBUF, ADR(SysSendBufSize), BYTESIZE(SysSendBufSize)); EVAL WinSock.setsockopt (sock, WinSock.SOL_SOCKET, WinSock.SO_RCVBUF, ADR(SysRcvBufSize), BYTESIZE(SysRcvBufSize)); ******) EVAL WinSock.setsockopt (sock, WinSock.SOL_SOCKET, WinSock.SO_LINGER, ADR(linger), BYTESIZE(linger)); (**** WinSock documentation warns that this may cause problems ****) EVAL WinSock.setsockopt (sock, WinSock.IPPROTO_TCP, WinSock.TCP_NODELAY, ADR(one), BYTESIZE(one)); END InitSock; Posix: PROCEDURE InitStream (fd: CARDINAL) RAISES {OSError.E} = (* We assume that the runtime ignores SIGPIPE signals *) VAR one := 1; linger := Usocket.struct_linger{1, 1}; BEGIN (***** EVAL Usocket.setsockopt(fd, Usocket.SOL_SOCKET, Usocket.SO_SNDBUF, ADR(SysSendBufSize), BYTESIZE(SysSendBufSize)); EVAL Usocket.setsockopt(fd, Usocket.SOL_SOCKET, Usocket.SO_RCVBUF, ADR(SysRcvBufSize), BYTESIZE(SysRcvBufSize)); ******) EVAL Usocket.setsockopt(fd, Usocket.SOL_SOCKET, Usocket.SO_LINGER, ADR(linger), BYTESIZE(linger)); EVAL Usocket.setsockopt(fd, Uin.IPPROTO_TCP, TCP_NODELAY, ADR(one), BYTESIZE(one)); MakeNonBlocking (fd); END InitStream; From jay.krell at cornell.edu Tue Jan 20 15:12:55 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 20 Jan 2009 14:12:55 +0000 Subject: [M3devel] chosing SIG_SUSPEND? Message-ID: What is the algorithm for chosing SIG_SUSPEND? Something like: #include #ifdef __APPLE__ /* nothing -- SIG_SUSPEND not used */ #elif defined(NSIG) #define SIG_SUSPEND (NSIG - 1) #elif defined(_NSIG) #define SIG_SUSPEND (_NSIG - 1) #elif defined(SIGRTMAX) #define SIG_SUSPEND SIGRTMAX #else #define SIG_SUSPEND SIGUSR2 #endif ? Whatever it is, I think it should be in RTSignalC.c. - Jay From mika at async.caltech.edu Tue Jan 20 15:39:20 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 20 Jan 2009 06:39:20 -0800 Subject: [M3devel] [M3commit] FW: move to version 5.7.1? In-Reply-To: Your message of "Tue, 20 Jan 2009 05:40:07 GMT." Message-ID: <200901201439.n0KEdKr0094091@camembert.async.caltech.edu> Jay writes: ... >---------------------------------------- >> 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 ... >> >> 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. How about in Scheme? I have written/am writing a Scheme interpreter in Modula-3 that I am happy to release with CM3; it's very easily extensible (that's sort of the point of it), so one can easily add low-level features to it as necessary. The system would be self-contained with that interpreter. Maybe writing scripts in Scheme is a little "weird"... (but I do it :-) ) Mika From hosking at cs.purdue.edu Tue Jan 20 17:42:01 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 21 Jan 2009 03:42:01 +1100 Subject: [M3devel] chosing SIG_SUSPEND? In-Reply-To: References: Message-ID: Choose SIGRTMAX first if defined, then SIGUSR2. I don't thing NSIG-1 is reliable, but just works on some systems. On 21 Jan 2009, at 01:12, Jay wrote: > > What is the algorithm for chosing SIG_SUSPEND? > > Something like: > > #include > > #ifdef __APPLE__ > /* nothing -- SIG_SUSPEND not used */ > #elif defined(NSIG) > #define SIG_SUSPEND (NSIG - 1) > #elif defined(_NSIG) > #define SIG_SUSPEND (_NSIG - 1) > #elif defined(SIGRTMAX) > #define SIG_SUSPEND SIGRTMAX > #else > #define SIG_SUSPEND SIGUSR2 > #endif > > ? > > Whatever it is, I think it should be in RTSignalC.c. > > - Jay From rcoleburn at scires.com Tue Jan 20 18:07:01 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 20 Jan 2009 12:07:01 -0500 Subject: [M3devel] ship vs. where build outputs go, etc.? In-Reply-To: References: <4974CB61.1E75.00D7.1@scires.com> Message-ID: <4975BE3A.1E75.00D7.1@scires.com> Jay: I think your email illustrates part of what I was trying to say in that there are a lot of things that aren't documented very well at this point that differ from the current documentation and practice that we've followed over the years. I'm not sure I agree with some of the proposals you offer. To be fair though, I think we should single out one proposal at a time for discussion. As for m3overrides and private vs. public repositories, I think you are going to get a lot of push-back on the idea to always ship everything to the public repository. I for one, don't like this idea. I do agree that the compiler's idea of certain options, e.g., clean, may not match what everyone expects. Of course, many of us have written scripts, etc. that invoke the compiler with certain options and that do other "stuff" using some of the same terminology (e.g. clean, ship, build, buildship, realclean, zap, etc.). I am arguing that the terminology should be standardized to have a consistent meaning across all of these. Depending on the definitions, some code will need to change make the implementation match the definition. Regards, Randy >>> Jay 1/20/2009 1:03 AM >>> > [was truncated and forward to m3commit instead of m3devel, now more content/drivel..] ps: >> 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. "Clean" doesn't really work imho..I guess it deletes the output files that the compiler knows about? Perhaps it is a bug when the config file doesn't tell it about all the outputs? "realclean" deletes the entire output directory, no matter what files it thinks it produced. It does assume they are all in the particular directory that they strongly tend to be in. It's dumb imho. Clean should probably be fixed. The m3-sys/m3cc directory and probably m3gdb also have their own special in-between state of "configure having been one", that they create a marker file to indicate. And then there is an environment variable to override that. Quake is a fairly general purpose language including the ability to read environment variables, so various directories are free to do whatever they want. m3cc and m3gdb are two of the longest to build package and configuration is also a slow step, that "rarely" has different output, so going back only to this "partly built" state perhaps is interesting. I rarely do that, at least on purpose. The Linux kernel and ucLibc (an alternative C runtime) do something similar. They store their configuration in file starting with a dot, so that on Unix rm -rf * won't delete it, because it skips "hidden" "dot" files. As well you can define arbitrary things on the cm3 command line, to guide arbitrary decisions around the tree, such as kernel vs. user threads. Given foo\src build outputs are generally in foo\target where "outputs" include "intermediate" files such as object files and "final" outputs such as executables and .dlls. You know...really I think, it's just that the Modula-3 folks knew/thought they were smarter than everyone else and made up their own terminology. In many other projects you have "make" and "make install". "ship" is "make install". I think that is all people need to know: "ship" == "install". It copies some of the outputs from foo\target to the installroot. Just as "make install" copies some of the outputs from the "intermediate" tree to the "live" tree. They can both be "dangerous" on a live system, and they can both be pointed at "new" empty location for safety (typical GNU make/automake/autoconf install option is make install DESTDIR=somewhere). I propose a different model. Always put the "final" outputs directly in a "live" tree, BUT for the case where you are doing something "risky" and would not immediately "ship" / "install", you would be encouraged to define a new clean output root, or an existing "test" root. "Actual install" would then be just a recursive copy from one root to another. Perhaps that is too inefficient? cm3 tries to do an incremental copy for example. I'm not sure if it is timestamp based or if they compare entire file contents. The downside to this proposal is that source files also get shipped, and doing that for every compile/link is wasteful. This is optional though and maybe can/should be turned off except when "making a distribution"? I'm not sure how optional it is. I'll try out turning it off locally. An upside to this proposal is it supercedes the "override" mechanism. You would never need to "override". "override" imho is broken because today, in order to keep "override" working, you are expected to encode the source tree structure all over the place. This seems redundant. Perhaps another idea would be for CM3_INSTALL to be colon/semicolon delimited? Search multiple package stores? That offers functionality not in the current model. A related proposal I have is that even the intermediate files be relocated. As I said, on a package-by-package basis, they are not in the source tree. Good. But on a multi-package basis, they are. Not good. I want the source tree to have no outputs, to stay "clean", unless I edit a file. Concretely this all looks like: 1) There is already the CM3_INSTALL environment variable. That is where "binaries" should be output, in the same structure that "ship" uses today. 2) There shall be a new environment variable, something like CM3_OBJECT_ROOT. 3) The existing CM3_ROOT that is the root of the source tree shall come into play. Given building in CM3_ROOT/foo/bar output shall go into: CM3_OBJECT_ROOT/foo/bar/target or maybe CM3_OBJECT_ROOT/target/foo/bar or maybe CM3_OBJECT_ROOT/foo/bar instead of CM3_ROOT/foo/bar/target. If you are not building under CM3_ROOT, there are a few viable options. 1) Do things as they are today. 2) Form up a form of CM3_OBJECT_ROOT/the path you are building that is valid and predictable. For example, in Windows, given a full path with a colon in it, remove the colon and you have a valid relative path you can append to another root. 3) Give user a way to specify what their "root" or "relative path from root" is. Because outputs litter the source tree today..unless you engage in changing BUILD_DIR, which maybe is the way in a few ways actually..you can't do multiple concurrent builds of the same target, such as with a different %PATH% to a different cm3.exe. Now, there is already BUILD_DIR. Perhaps all this is as simple as a change in the config file, changing BUILD_DIR to something like CM3_ROOT/path_of(foo.m3)/TARGET. I'll try that later. Maybe it just works. ? I'm not confident it'll work but maybe. Am I crazy? Wrong? Too disruptive? Most likely the last. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3commit at elegosoft.com; rcoleburn at scires.com > Date: Tue, 20 Jan 2009 05:40:07 +0000 > Subject: [M3commit] FW: [M3devel] move to version 5.7.1? > > > [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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jan 20 19:32:46 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 20 Jan 2009 18:32:46 +0000 Subject: [M3devel] FW: move to version 5.7.1? In-Reply-To: <200901201439.n0KEdKr0094091@camembert.async.caltech.edu> References: Your message of "Tue, 20 Jan 2009 05:40:07 GMT." <200901201439.n0KEdKr0094091@camembert.async.caltech.edu> Message-ID: If it is part of the cm3 tree then I (for one) am ok with it. It would have to be part of the "min" set. Will it work on Windows or is it Posix-specific? Working on Windows is kind of the point in question, since the *.sh files are fine for Unix. JScript, Python, and maybe Quake should also do. Possible problem with Quake and Scheme is it won't work for bootstrapping from older release. Problem with JScript is it'll be Windows specific. Therefore you are stuck still with two (or three or four!) sets of files. Best to have one set that work "everywhere". Bash and Python don't have these problems, they work with older cm3 and on all platforms. (I reluctantly lump Bash in with Python as being good because I still haven't gotten around to get Python to compile on my MIPS64_OPENBSD system and use the Bash files on it.) Bootstrapping eventually isn't an issue, eventually. - Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Tue, 20 Jan 2009 06:39:20 -0800 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] FW: move to version 5.7.1? > > > Jay writes: > ... >>---------------------------------------- >>> 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 > ... >>> >>> 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. > > How about in Scheme? I have written/am writing a Scheme interpreter > in Modula-3 that I am happy to release with CM3; it's very easily > extensible (that's sort of the point of it), so one can easily add > low-level features to it as necessary. The system would be > self-contained with that interpreter. Maybe writing scripts in > Scheme is a little "weird"... (but I do it :-) ) > > Mika > From jay.krell at cornell.edu Tue Jan 20 19:50:40 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 20 Jan 2009 18:50:40 +0000 Subject: [M3devel] ship vs. where build outputs go, etc.? In-Reply-To: <4975BE3A.1E75.00D7.1@scires.com> References: <4974CB61.1E75.00D7.1@scires.com> <4975BE3A.1E75.00D7.1@scires.com> Message-ID: The point is it would not always be the "public" repositoy. Today we have two places, the source tree and the repository. They have different structures. Instead, you could just have multiple repositories. They would all have the same structure. "Install" or "ship" is just recursive copy from a "private" repository to the "public" repository, instead of arbitrary rearrangement of files. OR merely "blessing" a private repository and making it the new public repository, such as by setting and an environment variable or possibly delete/rename. You could get something closer to the current experience by having two environment variables, CM3_PUBLIC, CM3_PRIVATE. cm3 -buildship would output to CM3_PUBLIC. cm3 -build would output to CM3_PRIVATE. Ideally it would do no extra writes vs. the current scheme. "Upgrade" would look like: set CM3_PRIVATE= some new temporary place build everything if successful rm -rf CM3_PUBLIC mv CM3_PUBLIC CM3_PRIVATE See, today "upgrade" writes over the live system and is therefore "dangerous". In this new scheme, "ship" would lose much of its danger. Rather than making changes as it goes, the final "commit" would not occur until the end, and would be easier to keep backups and such. Granted, if you look at what make-dist does, this is already possible today, by twiddling with CM3_INSTALL and always shipping. Though that costs extra I/O and you do have to prepopulate CM3_INSTALL..at least with a compiler, eh, just two files. Also with m3core/libm3 in some bootstrapping scenarios. (make-dist assumes so, though it usually is not the case). Along with an alternate root for intermediate outputs, this would enable multiple concurrent builds as well. A similar proposal is that "CM3_PUBLIC" could be colon or semicolon delimited -- a "search path" for reads, write to the first location. This would probably be confusing if it contained more than two paths though. publlic/private is "limited" in that it only supports two, but you can always use recursive copy to merge. Fixing clean would not take away realclean as an option if that is necessary for compat (I forget if compiler even implements realclean; the scripts implement it and I always use that version). I find it hard to believe that anyone depends on that clean leaves a few files around. Which files does it even leave around? I'm not sure what is documented or not. Could be that a lot is? - Jay ________________________________ > Date: Tue, 20 Jan 2009 12:07:01 -0500 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] ship vs. where build outputs go, etc.? > > > > > > > > Jay: > > > > I think your email illustrates part of what I was trying to say in that there are a lot of things that aren't documented very well at this point that differ from the current documentation and practice that we've followed over the years. > > > > I'm not sure I agree with some of the proposals you offer. To be fair though, I think we should single out one proposal at a time for discussion. > > > > As for m3overrides and private vs. public repositories, I think you are going to get a lot of push-back on the idea to always ship everything to the public repository. I for one, don't like this idea. > > > > I do agree that the compiler's idea of certain options, e.g., clean, may not match what everyone expects. Of course, many of us have written scripts, etc. that invoke the compiler with certain options and that do other "stuff" using some of the same terminology (e.g. clean, ship, build, buildship, realclean, zap, etc.). I am arguing that the terminology should be standardized to have a consistent meaning across all of these. Depending on the definitions, some code will need to change make the implementation match the definition. > > > > Regards, > > Randy > >>>> Jay 1/20/2009 1:03 AM>>> > >> [was truncated and forward to m3commit instead of m3devel, now more content/drivel..] > > ps: > > >>> 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. > > > > "Clean" doesn't really work imho..I guess it deletes the output files > that the compiler knows about? Perhaps it is a bug when the > config file doesn't tell it about all the outputs? > > > "realclean" deletes the entire output directory, no matter what files it thinks it produced. > It does assume they are all in the particular directory that they strongly tend to be in. > > > It's dumb imho. > Clean should probably be fixed. > > > The m3-sys/m3cc directory and probably m3gdb also have their own special > in-between state of "configure having been one", that they create a marker > file to indicate. And then there is an environment variable to override that. > Quake is a fairly general purpose language including the ability to read > environment variables, so various directories are free to do whatever they want. > > > m3cc and m3gdb are two of the longest to build package and configuration is also a slow step, that "rarely" has different output, so going back only to this "partly built" state perhaps is interesting. I rarely do that, at least on purpose. > > > The Linux kernel and ucLibc (an alternative C runtime) do something similar. > They store their configuration in file starting with a dot, so that on Unix rm -rf * won't delete it, because it skips "hidden" "dot" files. > > > > As well you can define arbitrary things on the cm3 command line, to guide > arbitrary decisions around the tree, such as kernel vs. user threads. > > > Given > foo\src > build outputs are generally in > foo\target > > > where "outputs" include "intermediate" files such as object files and "final" outputs such as executables and .dlls. > > > You know...really I think, it's just that the Modula-3 folks knew/thought they were smarter than everyone else and made up their own terminology. > > > In many other projects you have "make" and "make install". > "ship" is "make install". I think that is all people need to know: "ship" == "install". > > > It copies some of the outputs from foo\target to the installroot. > Just as "make install" copies some of the outputs from the "intermediate" tree to the "live" tree. They can both be "dangerous" on a live system, and they can both be pointed at "new" empty location for safety (typical GNU make/automake/autoconf install option is make install DESTDIR=somewhere). > > > I propose a different model. > Always put the "final" outputs directly in a "live" tree, BUT for the case where you are doing something "risky" and would not immediately "ship" / "install", you would be encouraged to define a new clean output root, or an existing "test" root. > > > "Actual install" would then be just a recursive copy from one root to another. > Perhaps that is too inefficient? cm3 tries to do an incremental copy for example. > I'm not sure if it is timestamp based or if they compare entire file contents. > > > The downside to this proposal is that source files also get shipped, and doing that for every compile/link is wasteful. This is optional though and maybe can/should be turned off except when "making a distribution"? I'm not sure how optional it is. I'll try out turning it off locally. > > > An upside to this proposal is it supercedes the "override" mechanism. > You would never need to "override". > "override" imho is broken because today, in order to keep "override" working, you are expected to encode the source tree structure all over the place. This seems redundant. > > > Perhaps another idea would be for CM3_INSTALL to be colon/semicolon delimited? > Search multiple package stores? > That offers functionality not in the current model. > > > A related proposal I have is that even the intermediate files be relocated. > As I said, on a package-by-package basis, they are not in the source tree. > Good. But on a multi-package basis, they are. Not good. > > > I want the source tree to have no outputs, to stay "clean", unless I edit a file. > > > Concretely this all looks like: > 1) There is already the CM3_INSTALL environment variable. That is where "binaries" should be output, in the same structure that "ship" uses today. > > > 2) There shall be a new environment variable, something like CM3_OBJECT_ROOT. > > 3) The existing CM3_ROOT that is the root of the source tree shall come into play. > > > Given building in > CM3_ROOT/foo/bar > > > output shall go into: > CM3_OBJECT_ROOT/foo/bar/target > or maybe CM3_OBJECT_ROOT/target/foo/bar > or maybe CM3_OBJECT_ROOT/foo/bar > > > instead of CM3_ROOT/foo/bar/target. > > > If you are not building under CM3_ROOT, there are a few viable options. > 1) Do things as they are today. > 2) Form up a form of CM3_OBJECT_ROOT/the path you are building that is valid and predictable. For example, in Windows, given a full path with a colon in it, remove the colon and you have a valid relative path you can append to another root. > 3) Give user a way to specify what their "root" or "relative path from root" is. > > > Because outputs litter the source tree today..unless you engage in changing BUILD_DIR, which maybe is the way in a few ways actually..you can't do multiple concurrent builds of the same target, such as with a different %PATH% to a different cm3.exe. > > > Now, there is already BUILD_DIR. > Perhaps all this is as simple as a change in the config file, changing BUILD_DIR to something like CM3_ROOT/path_of(foo.m3)/TARGET. I'll try that later. > Maybe it just works. ? > I'm not confident it'll work but maybe. > > > Am I crazy? Wrong? Too disruptive? > Most likely the last. > > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3commit at elegosoft.com; rcoleburn at scires.com >> Date: Tue, 20 Jan 2009 05:40:07 +0000 >> Subject: [M3commit] FW: [M3devel] move to version 5.7.1? >> >> >> [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 rodney.bates at wichita.edu Tue Jan 20 22:04:34 2009 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Tue, 20 Jan 2009 15:04:34 -0600 Subject: [M3devel] [M3commit] FW: move to version 5.7.1? In-Reply-To: <200901201439.n0KEdKr0094091@camembert.async.caltech.edu> References: <200901201439.n0KEdKr0094091@camembert.async.caltech.edu> Message-ID: <49763C62.8050509@wichita.edu> I like the Scheme interpreter idea. I think Modula-3 partially refutes the oft-repeated argument that every programming language has a narrow range of suitability. Among the imperative languages, there's not a lot around that can beat it, even for specific application areas. Builtin complex and non-integer fixed-point arithmetic are about the only things I can think of. But the functional languages are an area Modula-3 doesn't cover. Actually, you can write a lot of code in functional style in Modula-3, including, I think, some polymorphic stuff, but it's syntactically an awfully lot more ponderous than in a traditional functional language. With a true functional language tied into the implementation, we could claim very broad coverage. Mika Nystrom wrote: > Jay writes: > ... >> ---------------------------------------- >>> 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 > ... >>> 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. > > How about in Scheme? I have written/am writing a Scheme interpreter > in Modula-3 that I am happy to release with CM3; it's very easily > extensible (that's sort of the point of it), so one can easily add > low-level features to it as necessary. The system would be > self-contained with that interpreter. Maybe writing scripts in > Scheme is a little "weird"... (but I do it :-) ) > > Mika > From jay.krell at cornell.edu Wed Jan 21 14:37:53 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 21 Jan 2009 13:37:53 +0000 Subject: [M3devel] chosing SIG_SUSPEND? In-Reply-To: References: Message-ID: Solaris at least currently has SIGRTMAX. I want to switch RTSignalC.c to "something" here. I can preserve compat, like #ifdef __sun SIGUSR2 #else.. or..? I could do #ifdef SIGUSR2 #define SIG_SUSPEND SIGUSR2 #elif defined(SIGRTMAX) #define SIG_SUSPEND SIGRTMAX #else #error #endif I'll go with a compatible version for now and you can change it if you want. I'll test on Linux/x86, FreeBSD (AMD64, but hopefully there is gcc -m32), Linux/PPC, Solaris, Cygwin, Darwin/PPC (uh, actually, no, Darwin isn't really relevant, but I'll make sure the result does what is intended.) It looks like SIGRTMAX is a function call on Solaris. This stuff is like broken, right? I mean, there's a small number of signals and there's no arbitration. People just take them over and hope nobody else cares. There's no way to just queue a function call to a thread, in portable/general? Windows has QueueUserAPC or SuspendThread (SuspendThread is dangerous, thread could be doing anything), QueueUserAPC only interrupts at certain times. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Wed, 21 Jan 2009 03:42:01 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] chosing SIG_SUSPEND? > > Choose SIGRTMAX first if defined, then SIGUSR2. I don't thing NSIG-1 > is reliable, but just works on some systems. > > On 21 Jan 2009, at 01:12, Jay wrote: > >> >> What is the algorithm for chosing SIG_SUSPEND? >> >> Something like: >> >> #include >> >> #ifdef __APPLE__ >> /* nothing -- SIG_SUSPEND not used */ >> #elif defined(NSIG) >> #define SIG_SUSPEND (NSIG - 1) >> #elif defined(_NSIG) >> #define SIG_SUSPEND (_NSIG - 1) >> #elif defined(SIGRTMAX) >> #define SIG_SUSPEND SIGRTMAX >> #else >> #define SIG_SUSPEND SIGUSR2 >> #endif >> >> ? >> >> Whatever it is, I think it should be in RTSignalC.c. >> >> - Jay > From jay.krell at cornell.edu Wed Jan 21 15:37:53 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 21 Jan 2009 14:37:53 +0000 Subject: [M3devel] FW: chosing SIG_SUSPEND? In-Reply-To: References: Message-ID: [truncated again] I'm almost done with this change..just trying to decide to put the constants in a new runtime/common/RTConstants.c or the existing unix/common/Uconstants.c. At first I had them in thread/PTHREAD/ThreadPThreadC.c, but that isn't compiled on user-thread only platforms. :( - Jay ---------------------------------------- > From: jay > To: hosking > CC: m3devel > Subject: RE: [M3devel] chosing SIG_SUSPEND? > Date: Wed, 21 Jan 2009 13:37:53 +0000 > > > Solaris at least currently has SIGRTMAX. > I want to switch RTSignalC.c to "something" here. > I can preserve compat, like > > #ifdef __sun > SIGUSR2 > #else.. > > or..? > > I could do > #ifdef SIGUSR2 > #define SIG_SUSPEND SIGUSR2 > #elif defined(SIGRTMAX) > #define SIG_SUSPEND SIGRTMAX > #else > #error > #endif > > I'll go with a compatible version for now and you can change it if you want. > I'll test on Linux/x86, FreeBSD (AMD64, but hopefully there is gcc -m32), > Linux/PPC, Solaris, Cygwin, Darwin/PPC (uh, actually, no, Darwin isn't > really relevant, but I'll make sure the result does what is intended.) > > It looks like SIGRTMAX is a function call on Solaris. > > This stuff is like broken, right? > I mean, there's a small number of signals and there's no arbitration. > People just take them over and hope nobody else cares. > > > There's no way to just queue a function call to a thread, in portable/general? > Windows has QueueUserAPC or SuspendThread (SuspendThread is dangerous, > thread could be doing anything), QueueUserAPC only interrupts at certain times. > > > - Jay > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Wed, 21 Jan 2009 03:42:01 +1100 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] chosing SIG_SUSPEND? >> >> Choose SIGRTMAX first if defined, then SIGUSR2. I don't thing NSIG-1 >> is reliable, but just works on some systems. >> >> On 21 Jan 2009, at 01:12, Jay wrote: >> >>> >>> What is the algorithm for chosing SIG_SUSPEND? >>> >>> Something like: >>> >>> #include >>> >>> #ifdef __APPLE__ >>> /* nothing -- SIG_SUSPEND not used */ >>> #elif defined(NSIG) >>> #define SIG_SUSPEND (NSIG - 1) >>> #elif defined(_NSIG) >>> #define SIG_SUSPEND (_NSIG - 1) >>> #elif defined(SIGRTMAX) >>> #define SIG_SUSPEND SIGRTMAX >>> #else >>> #define SIG_SUSPEND SIGUSR2 >>> #endif >>> >>> ? >>> >>> Whatever it is, I think it should be in RTSignalC.c. >>> >>> - Jay >> From jay.krell at cornell.edu Wed Jan 21 15:48:26 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 21 Jan 2009 14:48:26 +0000 Subject: [M3devel] FW: chosing SIG_SUSPEND? In-Reply-To: References: Message-ID: Oh partially nevermind -- user threads doesn't use SIG_SUSPEND. SIG_SUSPEND will go away and ThreadPThreadC.c will define SIG, which will be used by it and ThreadPThread.i3. No RTConstants.c, no change in Uconstants.c. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Date: Wed, 21 Jan 2009 14:37:53 +0000 > Subject: [M3devel] FW: chosing SIG_SUSPEND? > > > [truncated again] > > > I'm almost done with this change..just trying to decide > to put the constants in a new runtime/common/RTConstants.c > or the existing unix/common/Uconstants.c. > > At first I had them in thread/PTHREAD/ThreadPThreadC.c, > but that isn't compiled on user-thread only platforms. :( > > - Jay > > ---------------------------------------- >> From: jay >> To: hosking >> CC: m3devel >> Subject: RE: [M3devel] chosing SIG_SUSPEND? >> Date: Wed, 21 Jan 2009 13:37:53 +0000 >> >> >> Solaris at least currently has SIGRTMAX. >> I want to switch RTSignalC.c to "something" here. >> I can preserve compat, like >> >> #ifdef __sun >> SIGUSR2 >> #else.. >> >> or..? >> >> I could do >> #ifdef SIGUSR2 >> #define SIG_SUSPEND SIGUSR2 >> #elif defined(SIGRTMAX) >> #define SIG_SUSPEND SIGRTMAX >> #else >> #error >> #endif >> >> I'll go with a compatible version for now and you can change it if you want. >> I'll test on Linux/x86, FreeBSD (AMD64, but hopefully there is gcc -m32), >> Linux/PPC, Solaris, Cygwin, Darwin/PPC (uh, actually, no, Darwin isn't >> really relevant, but I'll make sure the result does what is intended.) >> >> It looks like SIGRTMAX is a function call on Solaris. >> >> This stuff is like broken, right? >> I mean, there's a small number of signals and there's no arbitration. >> People just take them over and hope nobody else cares. >> >> >> There's no way to just queue a function call to a thread, in portable/general? >> Windows has QueueUserAPC or SuspendThread (SuspendThread is dangerous, >> thread could be doing anything), QueueUserAPC only interrupts at certain times. >> >> >> - Jay >> >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Wed, 21 Jan 2009 03:42:01 +1100 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] chosing SIG_SUSPEND? >>> >>> Choose SIGRTMAX first if defined, then SIGUSR2. I don't thing NSIG-1 >>> is reliable, but just works on some systems. >>> >>> On 21 Jan 2009, at 01:12, Jay wrote: >>> >>>> >>>> What is the algorithm for chosing SIG_SUSPEND? >>>> >>>> Something like: >>>> >>>> #include >>>> >>>> #ifdef __APPLE__ >>>> /* nothing -- SIG_SUSPEND not used */ >>>> #elif defined(NSIG) >>>> #define SIG_SUSPEND (NSIG - 1) >>>> #elif defined(_NSIG) >>>> #define SIG_SUSPEND (_NSIG - 1) >>>> #elif defined(SIGRTMAX) >>>> #define SIG_SUSPEND SIGRTMAX >>>> #else >>>> #define SIG_SUSPEND SIGUSR2 >>>> #endif >>>> >>>> ? >>>> >>>> Whatever it is, I think it should be in RTSignalC.c. >>>> >>>> - Jay >>> From wagner at elegosoft.com Wed Jan 21 15:49:36 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 21 Jan 2009 15:49:36 +0100 Subject: [M3devel] ship vs. where build outputs go, etc.? In-Reply-To: References: <4974CB61.1E75.00D7.1@scires.com> <4975BE3A.1E75.00D7.1@scires.com> Message-ID: <20090121154936.64zgzaj280g884o0@mail.elegosoft.com> Quoting Jay : > > The point is it would not always be the "public" repositoy. > > > Today we have two places, the source tree and the repository. > They have different structures. > > > Instead, you could just have multiple repositories. > They would all have the same structure. > > > "Install" or "ship" is just recursive copy from a "private" > repository to the "public" repository, instead of > arbitrary rearrangement of files. This does only work reliably if you keep exact version info for all files in the derived package pools (I'd like to reserve the term repository for source repository). A repository contains the source code (complete with history), while package pools contain derived files (intermediate results). A third (complementing) notion would be a deployable package (an installable archive or package). CM3 checks the consistency of one build wrt. a package pool and allows shipping into this pool only if everything is OK. Thus any override must inhibit any shipping, as it is not guaranteed that the overriden packages are available in the pool (in this version). If you ship packages from one pool to the other, there is no consistency check at all, unless you know exactly what versions of packages are in both pools. > OR merely "blessing" a private repository and making it the new > public repository, such as by setting and an environment variable > or possibly delete/rename. > > You could get something closer to the current experience by having > two environment variables, CM3_PUBLIC, CM3_PRIVATE. > cm3 -buildship would output to CM3_PUBLIC. > cm3 -build would output to CM3_PRIVATE. > Ideally it would do no extra writes vs. the current scheme. I've got no problem with multiple package pools, but we need to consider carefully what operations will be needed and which ones are safe. > "Upgrade" would look like: > > set CM3_PRIVATE= some new temporary place > build everything > if successful > rm -rf CM3_PUBLIC > mv CM3_PUBLIC CM3_PRIVATE > > See, today "upgrade" writes over the live system and is therefore > "dangerous". In this new scheme, "ship" would lose much of its > danger. Rather than making changes as it goes, the final "commit" > would not occur until the end, and would be easier to keep backups > and such. Granted, if you look at what make-dist does, this is > already possible today, by twiddling with CM3_INSTALL and always > shipping. Though that costs extra I/O and you do have to prepopulate > CM3_INSTALL..at least with a compiler, eh, just two files. > Also with m3core/libm3 in some bootstrapping scenarios. > (make-dist assumes so, though it usually is not the case). You mix concepts from the base CM3 builder with concepts from the maintenance scripts. I never intended these scripts to be used as a general build system for the everyday M3 user. Indeed it does not keep any of the guarantees that M3 gives. > Along with an alternate root for intermediate outputs, this would > enable multiple concurrent builds as well. > > A similar proposal is that "CM3_PUBLIC" could be colon or semicolon > delimited -- a "search path" for reads, write to the first location. > This would probably be confusing if it contained more than two paths though. > publlic/private is "limited" in that it only supports two, but you can > always use recursive copy to merge. I could imagine the following extensions (without deep consideration of the consequences): o allow to ship to more than one package pool (but keep it consistent with the builds) o allow multiple package pools for imports (e.g. by using a package pool path) o allow shipping only if all imports come from the destination package pool (as it is now) > Fixing clean would not take away realclean as an option if that is necessary > for compat (I forget if compiler even implements realclean; the scripts > implement it and I always use that version). I find it hard to believe > that anyone depends on that clean leaves a few files around. > Which files does it even leave around? > > I'm not sure what is documented or not. Could be that a lot is? cm3 -clean should be correct insofar as it removes all derived files (that the compiler knows of). It only works if all imports can be found, which also means that cleaning must be done in the correct order. As the builder currently doesn't work on package sets but only on one package this turns out to be little useful for large projects. Thus the maintenance scripts introduced the realclean command. Again, this was not intended as a general end user solution. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Wed Jan 21 15:42:38 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 21 Jan 2009 09:42:38 -0500 Subject: [M3devel] chosing SIG_SUSPEND? In-Reply-To: References: Message-ID: <46D5FC1C-7F28-4C9B-83CD-8FE0E4290A56@cs.purdue.edu> Yes, we want a signal no-one else is using to stop the threads. On 21 Jan 2009, at 08:37, Jay wrote: > > Solaris at least currently has SIGRTMAX. > I want to switch RTSignalC.c to "something" here. > I can preserve compat, like > > #ifdef __sun > SIGUSR2 > #else.. > > or..? > > I could do > #ifdef SIGUSR2 > #define SIG_SUSPEND SIGUSR2 > #elif defined(SIGRTMAX) > #define SIG_SUSPEND SIGRTMAX > #else > #error > #endif > > I'll go with a compatible version for now and you can change it if > you want. > I'll test on Linux/x86, FreeBSD (AMD64, but hopefully there is gcc - > m32), > Linux/PPC, Solaris, Cygwin, Darwin/PPC (uh, actually, no, Darwin isn't > really relevant, but I'll make sure the result does what is intended.) > > It looks like SIGRTMAX is a function call on Solaris. > > This stuff is like broken, right? > I mean, there's a small number of signals and there's no arbitration. > People just take them over and hope nobody else cares. > > > There's no way to just queue a function call to a thread, in > portable/general? > Windows has QueueUserAPC or SuspendThread (SuspendThread is dangerous, > thread could be doing anything), QueueUserAPC only interrupts at > certain times. > > > - Jay > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Wed, 21 Jan 2009 03:42:01 +1100 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] chosing SIG_SUSPEND? >> >> Choose SIGRTMAX first if defined, then SIGUSR2. I don't thing NSIG-1 >> is reliable, but just works on some systems. >> >> On 21 Jan 2009, at 01:12, Jay wrote: >> >>> >>> What is the algorithm for chosing SIG_SUSPEND? >>> >>> Something like: >>> >>> #include >>> >>> #ifdef __APPLE__ >>> /* nothing -- SIG_SUSPEND not used */ >>> #elif defined(NSIG) >>> #define SIG_SUSPEND (NSIG - 1) >>> #elif defined(_NSIG) >>> #define SIG_SUSPEND (_NSIG - 1) >>> #elif defined(SIGRTMAX) >>> #define SIG_SUSPEND SIGRTMAX >>> #else >>> #define SIG_SUSPEND SIGUSR2 >>> #endif >>> >>> ? >>> >>> Whatever it is, I think it should be in RTSignalC.c. >>> >>> - 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: [M3devel] m3commit not working? Message-ID: I'm not seeing m3commit mail. - Jay From jay.krell at cornell.edu Thu Jan 22 02:19:43 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 22 Jan 2009 01:19:43 +0000 Subject: [M3devel] dependency on platform list removed Message-ID: I removed the dependency libm3 had on the list of platforms that the compiler has. This should make the system easier to build. You'll no longer get the error about SocketPosix and Compiler disagreeing. I thought m3core had a dependency that would harder to remove but I'm not sure. The SOLgnu Tinderbox had been failing due to this dependency but about the time I made the change, it started succeeding. (I thought Tinderbox ran "upgrade.sh" first, which gets around this.) Removing the dependency should actually be a /little/ more efficient as well, not noticably. A bunch of unused strings are removed from libm3. Even the ones remaining are a dubious error fallback. This could be viewed as a bad thing, since before there was a "check" that you had things up to date. Now more mixes can be used, for better or worse. - Jay From jay.krell at cornell.edu Thu Jan 22 02:34:38 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 22 Jan 2009 01:34:38 +0000 Subject: [M3devel] chosing SIG_SUSPEND? In-Reply-To: <46D5FC1C-7F28-4C9B-83CD-8FE0E4290A56@cs.purdue.edu> References: <46D5FC1C-7F28-4C9B-83CD-8FE0E4290A56@cs.purdue.edu> Message-ID: The code is now: #define SIG_SUSPEND ThreadPThreadC_SIG_SUSPEND /* expected values for compat, if compat matters: Solaris: 17 (at least 32bit SPARC?) Cygwin: 19 -- er, but maybe that's wrong Linux: 64 FreeBSD: 31 OpenBSD: 31 HPUX: 44 Look at the history of Usignal and RTMachine to find more values. There was RTMachine.SIG_SUSPEND and SIG was aliased to it. Both SIG and SIG_SUSPEND were only defined for systems using pthreads. SIG was shorthand. */ #if defined(__APPLE__) const int SIG_SUSPEND = 0; #elif defined(__sun) || defined(__CYGWIN__) || defined(__FreeBSD__) const int SIG_SUSPEND = SIGUSR2; #elif defined(__linux) const int SIG_SUSPEND = NSIG - 1; #elif defined(SIGRTMAX) /* This might be a function call, in which case try _SIGRTMAX or initializing it somewhere. */ const int SIG_SUSPEND = SIGRTMAX; #elif defined(SIGUSR2) const int SIG_SUSPEND = SIGUSR2; #else #error Unable to determine SIG_SUSPEND. #endif Compatible but perhaps not ideal. It'll automatically port to "something" now, less per-machine work. The #ifdefs are overly broad, since __sun and __FreeBSD__ will cover more than just older platforms but also newer ones -- need to check processor. "SIG" is gone, it was private and I think merely "shorthand", not important. Uses say SIG_SUSPEND. SIG_SUSPEND gone from RTMachine.i3 and in ThreadPThreadC.{c,i3} - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Wed, 21 Jan 2009 09:42:38 -0500 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] chosing SIG_SUSPEND? > > Yes, we want a signal no-one else is using to stop the threads. > > On 21 Jan 2009, at 08:37, Jay wrote: > >> >> Solaris at least currently has SIGRTMAX. >> I want to switch RTSignalC.c to "something" here. >> I can preserve compat, like >> >> #ifdef __sun >> SIGUSR2 >> #else.. >> >> or..? >> >> I could do >> #ifdef SIGUSR2 >> #define SIG_SUSPEND SIGUSR2 >> #elif defined(SIGRTMAX) >> #define SIG_SUSPEND SIGRTMAX >> #else >> #error >> #endif >> >> I'll go with a compatible version for now and you can change it if >> you want. >> I'll test on Linux/x86, FreeBSD (AMD64, but hopefully there is gcc - >> m32), >> Linux/PPC, Solaris, Cygwin, Darwin/PPC (uh, actually, no, Darwin isn't >> really relevant, but I'll make sure the result does what is intended.) >> >> It looks like SIGRTMAX is a function call on Solaris. >> >> This stuff is like broken, right? >> I mean, there's a small number of signals and there's no arbitration. >> People just take them over and hope nobody else cares. >> >> >> There's no way to just queue a function call to a thread, in >> portable/general? >> Windows has QueueUserAPC or SuspendThread (SuspendThread is dangerous, >> thread could be doing anything), QueueUserAPC only interrupts at >> certain times. >> >> >> - Jay >> >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Wed, 21 Jan 2009 03:42:01 +1100 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] chosing SIG_SUSPEND? >>> >>> Choose SIGRTMAX first if defined, then SIGUSR2. I don't thing NSIG-1 >>> is reliable, but just works on some systems. >>> >>> On 21 Jan 2009, at 01:12, Jay wrote: >>> >>>> >>>> What is the algorithm for chosing SIG_SUSPEND? >>>> >>>> Something like: >>>> >>>> #include >>>> >>>> #ifdef __APPLE__ >>>> /* nothing -- SIG_SUSPEND not used */ >>>> #elif defined(NSIG) >>>> #define SIG_SUSPEND (NSIG - 1) >>>> #elif defined(_NSIG) >>>> #define SIG_SUSPEND (_NSIG - 1) >>>> #elif defined(SIGRTMAX) >>>> #define SIG_SUSPEND SIGRTMAX >>>> #else >>>> #define SIG_SUSPEND SIGUSR2 >>>> #endif >>>> >>>> ? >>>> >>>> Whatever it is, I think it should be in RTSignalC.c. >>>> >>>> - Jay >>> > 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: [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: [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 jay.krell at cornell.edu Fri Jan 23 08:09:40 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 23 Jan 2009 07:09:40 +0000 Subject: [M3devel] chosing SIG_SUSPEND? In-Reply-To: <46D5FC1C-7F28-4C9B-83CD-8FE0E4290A56@cs.purdue.edu> References: <46D5FC1C-7F28-4C9B-83CD-8FE0E4290A56@cs.purdue.edu> Message-ID: I noticed in some of the code..I think for SegV, Quit,etc., not for thread suspension, that if the signalis already set to other than SIG_DFL, Modula-3 refrainsfrom changing it. So, I was thinking, would it be reasonable to iterate through, saySIGUSR1, SIGUSR2, and SIGRTMIN through SIGRTMAX, anduse the "first" one that isn't set to SIG_DFL?By "first", I don't mean to imply what order to check in,probably my statement has the order backwards.The point is to check them and not just hijack them. OR, is there another way to do this? Doesn't or can't the Modula-3 code "check a flag""every so often" and then voluntarily yield?Of course, the allocator would check the flag. Perhaps I just really need to get "that paper" into my head?Understand the issue around "other threads running intight computation loops for a long time", and therefore not checkingon yielding? Is the signal mechanism actually preemptive anyway? - Jay> From: hosking at cs.purdue.edu> To: jay.krell at cornell.edu> Date: Wed, 21 Jan 2009 09:42:38 -0500> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] chosing SIG_SUSPEND?> > Yes, we want a signal no-one else is using to stop the threads.> > On 21 Jan 2009, at 08:37, Jay wrote:> > >> > Solaris at least currently has SIGRTMAX.> > I want to switch RTSignalC.c to "something" here.> > I can preserve compat, like> >> > #ifdef __sun> > SIGUSR2> > #else..> >> > or..?> >> > I could do> > #ifdef SIGUSR2> > #define SIG_SUSPEND SIGUSR2> > #elif defined(SIGRTMAX)> > #define SIG_SUSPEND SIGRTMAX> > #else> > #error> > #endif> >> > I'll go with a compatible version for now and you can change it if > > you want.> > I'll test on Linux/x86, FreeBSD (AMD64, but hopefully there is gcc - > > m32),> > Linux/PPC, Solaris, Cygwin, Darwin/PPC (uh, actually, no, Darwin isn't> > really relevant, but I'll make sure the result does what is intended.)> >> > It looks like SIGRTMAX is a function call on Solaris.> >> > This stuff is like broken, right?> > I mean, there's a small number of signals and there's no arbitration.> > People just take them over and hope nobody else cares.> >> >> > There's no way to just queue a function call to a thread, in > > portable/general?> > Windows has QueueUserAPC or SuspendThread (SuspendThread is dangerous,> > thread could be doing anything), QueueUserAPC only interrupts at > > certain times.> >> >> > - Jay> >> >> > ----------------------------------------> >> From: hosking at cs.purdue.edu> >> To: jay.krell at cornell.edu> >> Date: Wed, 21 Jan 2009 03:42:01 +1100> >> CC: m3devel at elegosoft.com> >> Subject: Re: [M3devel] chosing SIG_SUSPEND?> >>> >> Choose SIGRTMAX first if defined, then SIGUSR2. I don't thing NSIG-1> >> is reliable, but just works on some systems.> >>> >> On 21 Jan 2009, at 01:12, Jay wrote:> >>> >>>> >>> What is the algorithm for chosing SIG_SUSPEND?> >>>> >>> Something like:> >>>> >>> #include> >>>> >>> #ifdef __APPLE__> >>> /* nothing -- SIG_SUSPEND not used */> >>> #elif defined(NSIG)> >>> #define SIG_SUSPEND (NSIG - 1)> >>> #elif defined(_NSIG)> >>> #define SIG_SUSPEND (_NSIG - 1)> >>> #elif defined(SIGRTMAX)> >>> #define SIG_SUSPEND SIGRTMAX> >>> #else> >>> #define SIG_SUSPEND SIGUSR2> >>> #endif> >>>> >>> ?> >>>> >>> Whatever it is, I think it should be in RTSignalC.c.> >>>> >>> - Jay> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Jan 23 14:27:39 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 23 Jan 2009 08:27:39 -0500 Subject: [M3devel] chosing SIG_SUSPEND? In-Reply-To: References: <46D5FC1C-7F28-4C9B-83CD-8FE0E4290A56@cs.purdue.edu> Message-ID: On 23 Jan 2009, at 02:09, Jay wrote: > I noticed in some of the code..I think for SegV, Quit, > etc., not for thread suspension, that if the signal > is already set to other than SIG_DFL, Modula-3 refrains > from changing it. > > So, I was thinking, would it be reasonable to iterate through, say > SIGUSR1, SIGUSR2, and SIGRTMIN through SIGRTMAX, and > use the "first" one that isn't set to SIG_DFL? > By "first", I don't mean to imply what order to check in, > probably my statement has the order backwards. > The point is to check them and not just hijack them. Maybe. I would argue the opposite: that M3 apps that use signals should avoid using the one dedicated to thread suspension. > OR, is there another way to do this? > > Doesn't or can't the Modula-3 code "check a flag" > "every so often" and then voluntarily yield? > Of course, the allocator would check the flag. This is a reasonable approach for Modula-3-compiled code: the polling points are called GC-safe-points. You just need to insert poll-points on backward branches and calls. The real problem is stopping threads that are off in native code and system calls. We could wrap every native call with a code to save GC-relevant state before going native, and then check the flag on return from native in case a GC is in progress. Many Java implementations use that approach. > Perhaps I just really need to get "that paper" into my head? > Understand the issue around "other threads running in > tight computation loops for a long time", and therefore not checking > on yielding? > > Is the signal mechanism actually preemptive anyway? Preemptive in what sense? Depending on the OS, signals tend to get delivered at system calls or thread context-switches. > > > - Jay > > > > > > > > From: hosking at cs.purdue.edu > > To: jay.krell at cornell.edu > > Date: Wed, 21 Jan 2009 09:42:38 -0500 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] chosing SIG_SUSPEND? > > > > Yes, we want a signal no-one else is using to stop the threads. > > > > On 21 Jan 2009, at 08:37, Jay wrote: > > > > > > > > Solaris at least currently has SIGRTMAX. > > > I want to switch RTSignalC.c to "something" here. > > > I can preserve compat, like > > > > > > #ifdef __sun > > > SIGUSR2 > > > #else.. > > > > > > or..? > > > > > > I could do > > > #ifdef SIGUSR2 > > > #define SIG_SUSPEND SIGUSR2 > > > #elif defined(SIGRTMAX) > > > #define SIG_SUSPEND SIGRTMAX > > > #else > > > #error > > > #endif > > > > > > I'll go with a compatible version for now and you can change it if > > > you want. > > > I'll test on Linux/x86, FreeBSD (AMD64, but hopefully there is > gcc - > > > m32), > > > Linux/PPC, Solaris, Cygwin, Darwin/PPC (uh, actually, no, Darwin > isn't > > > really relevant, but I'll make sure the result does what is > intended.) > > > > > > It looks like SIGRTMAX is a function call on Solaris. > > > > > > This stuff is like broken, right? > > > I mean, there's a small number of signals and there's no > arbitration. > > > People just take them over and hope nobody else cares. > > > > > > > > > There's no way to just queue a function call to a thread, in > > > portable/general? > > > Windows has QueueUserAPC or SuspendThread (SuspendThread is > dangerous, > > > thread could be doing anything), QueueUserAPC only interrupts at > > > certain times. > > > > > > > > > - Jay > > > > > > > > > ---------------------------------------- > > >> From: hosking at cs.purdue.edu > > >> To: jay.krell at cornell.edu > > >> Date: Wed, 21 Jan 2009 03:42:01 +1100 > > >> CC: m3devel at elegosoft.com > > >> Subject: Re: [M3devel] chosing SIG_SUSPEND? > > >> > > >> Choose SIGRTMAX first if defined, then SIGUSR2. I don't thing > NSIG-1 > > >> is reliable, but just works on some systems. > > >> > > >> On 21 Jan 2009, at 01:12, Jay wrote: > > >> > > >>> > > >>> What is the algorithm for chosing SIG_SUSPEND? > > >>> > > >>> Something like: > > >>> > > >>> #include > > >>> > > >>> #ifdef __APPLE__ > > >>> /* nothing -- SIG_SUSPEND not used */ > > >>> #elif defined(NSIG) > > >>> #define SIG_SUSPEND (NSIG - 1) > > >>> #elif defined(_NSIG) > > >>> #define SIG_SUSPEND (_NSIG - 1) > > >>> #elif defined(SIGRTMAX) > > >>> #define SIG_SUSPEND SIGRTMAX > > >>> #else > > >>> #define SIG_SUSPEND SIGUSR2 > > >>> #endif > > >>> > > >>> ? > > >>> > > >>> Whatever it is, I think it should be in RTSignalC.c. > > >>> > > >>> - Jay > > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Fri Jan 23 15:01:49 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 23 Jan 2009 06:01:49 -0800 Subject: [M3devel] chosing SIG_SUSPEND? In-Reply-To: Your message of "Fri, 23 Jan 2009 08:27:39 EST." Message-ID: <200901231401.n0NE1ngq007378@camembert.async.caltech.edu> Tony Hosking writes: > ... >> probably my statement has the order backwards. >> The point is to check them and not just hijack them. > >Maybe. I would argue the opposite: that M3 apps that use signals >should avoid using the one dedicated to thread suspension. I agree! Signals are not the Modula-3 Way. Something you mess with only when you're trying to interface with C code that hasn't heard of "threads". Yuck. ... >> Is the signal mechanism actually preemptive anyway? > >Preemptive in what sense? Depending on the OS, signals tend to get >delivered at system calls or thread context-switches. Isn't the whole point of signals to interrupt a computation...? ctrl-C, ctrl-Z, ctrl-\, SIGALRM, etc.... Mika From rcoleburn at scires.com Mon Jan 26 01:43:27 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 25 Jan 2009 19:43:27 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20090125163615.DABA3904003@birch.elegosoft.com> References: <20090125163615.DABA3904003@birch.elegosoft.com> Message-ID: <497CC069.1E75.00D7.1@scires.com> Jay: Please explain what you are doing here. I don't want to break stuff just to make extremely old and no longer supported toolsets work. My recollection is that the cvtres program is used in getting icon resources et al added to the executable. I know that the CM3IDE package is dependent on the WindowsResources package as are a lot of my programs. If you make changes here, we need to make sure it doesn't break existing stuff. Also, if there is a better way to go about it, I don't mind learning, but we will need to deal with making everything that depends on windowsResources continue to work. Regards, Randy >>> Jay Krell 1/25/2009 5:36 PM >>> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 26 02:50:35 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 26 Jan 2009 01:50:35 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <497CC069.1E75.00D7.1@scires.com> References: <20090125163615.DABA3904003@birch.elegosoft.com> <497CC069.1E75.00D7.1@scires.com> Message-ID: There is never any need to run cvtres. I have never seen anyone do this. You just pass the .res file to the linker and it works. I would turn things around and ask why it was written this way in the first place, different than all other systems? I can imagine one very marginal very minor point. If the .res file is linked into multiple executables, there might be microscropic build perf win in running cvtres once. I would like further simplification here but I didn't do the research needed. In particular, I don't think clients should have to say if equal (TARGET, "WIN32"). The Quake code already does that, but you'd have to make sure the package is shipped for all platforms so they have the .tmpl file. - Jay _______________________________ > Date: Sun, 25 Jan 2009 19:43:27 -0500 > From: rcoleburn at scires.com > To: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Jay: > > > > Please explain what you are doing here. I don't want to break stuff just to make extremely old and no longer supported toolsets work. > > > > My recollection is that the cvtres program is used in getting icon resources et al added to the executable. I know that the CM3IDE package is dependent on the WindowsResources package as are a lot of my programs. If you make changes here, we need to make sure it doesn't break existing stuff. > > > > Also, if there is a better way to go about it, I don't mind learning, but we will need to deal with making everything that depends on windowsResources continue to work. > > > > Regards, > > Randy > >>>> Jay Krell 1/25/2009 5:36 PM>>> > 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 jay.krell at cornell.edu Wed Jan 28 15:37:20 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 28 Jan 2009 14:37:20 +0000 Subject: [M3devel] gratuitous platform differences? Message-ID: I'm looking to add user thread support to the stuff I'm working on. As part of this, I'm surveying various platform-specific code, to find the commonality. Some of this should be common Modula-3 code. Where there are dealings with struct sigaction or sigset_t, the code should be rewritten in C to avoid requiring other additional platform-dependent code. It seems to me that many of the differences are gratuitous. Here are two: - some platforms unmap, or at least take away write access, to the last page in the stack; and then remap it (or add back write access) before disposing Now, I'm not going to move all ports to "my rewritten headers", just ones that I can test and are "somewhat active". In this case, I think that leads to all platforms being the same. So the question of "why not always do this?" doesn't matter. - Regarding disallow_sigvtalrm, allow_sigvtalrm, some platforms initialize the mask in the module's initializer, some recreate it for every call. Is there a reason for this? Creating it once is faster. But does require the initializer run early enough. And one would hope that the cached struct isn't too huge and memory wasting. To be safe, I could just provide two versions here, one that makes the mask over and over, one that does not. - Jay From jay.krell at cornell.edu Wed Jan 28 15:57:17 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 28 Jan 2009 14:57:17 +0000 Subject: [M3devel] sigbus? Message-ID: Here is something very suspicious, that I find by comparing similar platform-specific code to other similar platforms, trying to find what needs to be forked or #ifdefed per-platfform and why: All the Darwin ports, and no other ports, have: C:\dev2\cm3.2\m3-libs\m3core\src\runtime\AMD64_DARWIN\RTSignal.m3(34): SetHandler (6, Usignal.SIGBUS, SegV); but none of them do anything with SIGBUS in RestoreHandlers. - It must be a mistake to not RestoreHandler, right? - Either all of the ports should handle SIGBUS, or none of them, right? At least if all the underlying platforms define it? Granted, no x86 or AMD64 platform is likely to ever issue it, but maybe for, like, using sse or cmpxchg 8b? - Jay From jay.krell at cornell.edu Wed Jan 28 16:56:42 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 28 Jan 2009 15:56:42 +0000 Subject: [M3devel] gratuitous platform differences? In-Reply-To: References: Message-ID: Another difference is that some platforms set the last page of the stack to be PROT_NONE, while others use PROT_READ, with a comment: (* The protection should be 0, but making the page read-only is good enough to prevent unchecked runtime errors *) except ALPHA_OSF says: (* The protection should be 0, but a bug in MIPS/Ultrix 4.2 (vmdup) causes kernel panics when it is. Making the page read-only is good enough to prevent unchecked runtime errors *) Also, whenever calling Usignal stuff, there are three styles i := Usignal.something() WITH i = Usignal.something() DO END; EVAL Usignal.something() It COULD be that the functions fail on some platforms and EVAL is used to ignore the result. I favor the first style -- I find that code should avoid indentation in general -- given a choice between an if/else and if/continue, I'll use if/continue, adding a local variable or using WITH, add a local variable. Etc. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Wed, 28 Jan 2009 14:37:20 +0000 > Subject: [M3devel] gratuitous platform differences? > > > I'm looking to add user thread support to the stuff I'm working on. > As part of this, I'm surveying various platform-specific code, > to find the commonality. > Some of this should be common Modula-3 code. > Where there are dealings with struct sigaction or sigset_t, the > code should be rewritten in C to avoid requiring other additional > platform-dependent code. > > > It seems to me that many of the differences are gratuitous. > > > Here are two: > > > - some platforms unmap, or at least take away write access, to the > last page in the stack; and then remap it (or add back write access) > before disposing > Now, I'm not going to move all ports to "my rewritten headers", > just ones that I can test and are "somewhat active". > In this case, I think that leads to all platforms being the same. > So the question of "why not always do this?" doesn't matter. > > > - Regarding disallow_sigvtalrm, allow_sigvtalrm, some platforms > initialize the mask in the module's initializer, some recreate it > for every call. > Is there a reason for this? > Creating it once is faster. > But does require the initializer run early enough. > And one would hope that the cached struct isn't too huge and memory wasting. > > > To be safe, I could just provide two versions here, one that makes the mask > over and over, one that does not. > > > - Jay From jay.krell at cornell.edu Wed Jan 28 17:04:34 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 28 Jan 2009 16:04:34 +0000 Subject: [M3devel] gratuitous platform differences? In-Reply-To: References: Message-ID: (There is an ASSERT in two of the styles, but it apparently got removed by some buggy mail software in the stack..) - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Wed, 28 Jan 2009 15:56:42 +0000 > Subject: Re: [M3devel] gratuitous platform differences? > > > Another difference is that some platforms set the last page of the stack to be PROT_NONE, while others use PROT_READ, with a comment: > > (* The protection should be 0, but making the page read-only > is good enough to prevent unchecked runtime errors *) > > except ALPHA_OSF says: > > (* The protection should be 0, but a bug in MIPS/Ultrix 4.2 (vmdup) > causes kernel panics when it is. Making the page read-only > is good enough to prevent unchecked runtime errors *) > > Also, whenever calling Usignal stuff, there are three styles > > i := Usignal.something() > > > > WITH i = Usignal.something() DO > > END; > > > EVAL Usignal.something() > > > > It COULD be that the functions fail on some platforms and EVAL is used to ignore the result. > I favor the first style -- I find that code should avoid indentation in general -- given a choice between an if/else and if/continue, I'll use if/continue, adding a local variable or using WITH, add a local variable. Etc. > > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Wed, 28 Jan 2009 14:37:20 +0000 >> Subject: [M3devel] gratuitous platform differences? >> >> >> I'm looking to add user thread support to the stuff I'm working on. >> As part of this, I'm surveying various platform-specific code, >> to find the commonality. >> Some of this should be common Modula-3 code. >> Where there are dealings with struct sigaction or sigset_t, the >> code should be rewritten in C to avoid requiring other additional >> platform-dependent code. >> >> >> It seems to me that many of the differences are gratuitous. >> >> >> Here are two: >> >> >> - some platforms unmap, or at least take away write access, to the >> last page in the stack; and then remap it (or add back write access) >> before disposing >> Now, I'm not going to move all ports to "my rewritten headers", >> just ones that I can test and are "somewhat active". >> In this case, I think that leads to all platforms being the same. >> So the question of "why not always do this?" doesn't matter. >> >> >> - Regarding disallow_sigvtalrm, allow_sigvtalrm, some platforms >> initialize the mask in the module's initializer, some recreate it >> for every call. >> Is there a reason for this? >> Creating it once is faster. >> But does require the initializer run early enough. >> And one would hope that the cached struct isn't too huge and memory wasting. >> >> >> To be safe, I could just provide two versions here, one that makes the mask >> over and over, one that does not. >> >> >> - Jay From jay.krell at cornell.edu Thu Jan 29 18:10:53 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 29 Jan 2009 17:10:53 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <495B901F.1E75.00D7.1@scires.com> References: <20081231105208.9CF4710D5DDE@birch.elegosoft.com> <495B4846.1E75.00D7.1@scires.com> <495B901F.1E75.00D7.1@scires.com> Message-ID: > In reading your post, you state that you deoptimized the native implementation > to make it match Cygwin. Now, I'm not sure how I was wrong on this point. Cygwin's setjmp.h incorrectly typedefs jmp_buf, indeed, to be much larger than "native", but the header is incorrect. Cygwin actually has a slightly smaller jmp_buf than native (13 ints vs. 16 ints), but we use the native size always, deoptimizing the Cygwin case. - Jay ________________________________ > Date: Wed, 31 Dec 2008 15:30:40 -0500 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > > > > > Jay: > > > > First, I do want to say thanks for all you are doing for the cause of Modula-3. I don't think we say thanks enough for what others do for us. THANK YOU! > > > > I don't want to be perceived as "complaining", rather I am trying to voice my opinion in the hopes of influencing future direction. Of course, since I'm not doing the work, I can only make suggestions. > > > > In reading your post, you state that you deoptimized the native implementation to make it match Cygwin. Now, I'm not sure how much effect this deoptimization has (maybe little), but it is clear that in this case your implementation choice has favored the non-native implementation over the native one. IMO, tradeoffs of this type are not good. If one is trying to convince someone to use Modula-3, why would you want to give them a "deoptimized" version just to make it easier to support a non-native environment---indeed, one that they may not even want/use? If we have to make a trade-off, I say favor the native implementation always over the non-native one. > > > > What I'm trying to say here is that my experience as a software, systems, and program engineer is that I've always been forced to justify the cost/benefit of development tools for any project. Many times I've had to go head to head with folks higher up in my own organization or in the customer's organization whose preconceived opinions were based on rumor and what they've heard rather than actual factual hands-on experience. I want to pick the best tool for the job instead of being forced to pick an inferior tool because someone higher in the food chain demanded it based on faulty preconceived opinion. I like Modula-3. I've found that I am more productive using it. But, if the compiler doesn't produce efficient code, I lose ground in arguing with the higher-ups. > > > > As for Python, I've never ventured to learn it, so for me, it is something of a mystery. But you miss the point. I'm not arguing the merits of Python, I'm just saying that anything Modula-3 requires on top of what is provided by the standard host platform represents a potential obstacle or barrier to ease of use/implementation. It also sends the message that somehow Modula-3 is not complete on its own, we have get Python just to install and oh yes we need a C compiler and a linker and a ...? IMO, ultimately we need a turn-key download and install routine for Modula-3 that just works, out-of-the-box. If you give me an EXE, a CMD, or a BAT, for the install, I can run it on Windows, but if you give me an install routine that requires I first install something else, e.g. Python, then that becomes a barrier to the folks who don't know Python or already have it installed. > > > > Am I alone in this line of thought? If so, I'll just be quiet. > > > > BTW, I can certainly help in maintaining the CMD/BAT install routines or in making a better CMINSTALL. My problem is that right now, it is hard to understand all the dependencies for proper building of cm3 from scratch. Indeed, I've contributed some CMD/BAT install stuff in the past, but it is now out of date. Perhaps if there is a way we could better document the proper build order and dependencies, it would be easier for folks in the community to help in this area. I certainly would volunteer to do the CMD files as long as I had enough information to do it right. At one point, I thought we had a file that showed the package build order and dependencies. Not sure if the format of this file is well-documented or if the file is kept up-to-date. > > > > Regards, > > Randy > > >>>> Jay 12/31/2008 1:34 PM>>> >> you've made the CYGWIN implementation "appear" >> be the same as the native Windows implementation. >> But they are not the same. > > > But they mostly are, from the front end's point of view. > They are both little endian, x86, use the same jump_buf size (I grew it to match Cygwin's, which is a deoptimization of stack use on native NT386), the same type sizes and alignments..er..not sure about LONGINT. > They might vary in newline and one uses the internal backend and one the external, however which backend they use is actually minor to the front end, though I think it affects if the front end "deals with" calling conventions, particularly left-to-right vs. right-to-left and struct returns. > Object code produced by one can generally be linked with object code produced by the other. > > > SOLgnu and SOLsun are a better example of this, though they do go ahead and duplicate tons of stuff that if I had implemented them, I would have avoided. > They are truly identical in every respect in the front end and back end. > They only vary in the config file. > This is wasteful, because, "by default", if I'm put together a comprehensive cross build system without being a little smarter, I end up building two identical m3cgs. My config files are willing to "probe across" SOLsun and SOLgnu though, so I need only one m3cg for the two of them. > > > Given that "NT386" can describe a combinatorial explosion of configurations, it makes some sense to keep it just one if possible. The compiler mostly doesn't care. > > > >> "- BUILD_DIR does not necessarily equal HOST or TARGET, >> because of how I structured I386_CYGWIN to be a "configuration" >> where TARGET is still NT386." > >> IMO, it would be wrong to change the meaning of things like "BUILD_DIR", "HOST", and "TARGET". > > BUILD_DIR also does not equal HOST or TARGET when doing profiled builds, which admittedly I never have. > Therefore, BUILD_DIR is arbitrary. > I might be confusing something here though -- since I have never built a profiled build, I also haven't shipped one. It could be that "shipped BUILD_DIR" does equal TARGET, for profiled builds, in which case I did set a precedent. But the "override" code isn't using shipped files, so.. > I have to check. > >> as long as it does not compromise the native Windows implementation > > Agreed and it basically doesn't. > Show me where it does. > The only thing I can think of is the jmpbuf size. > >> I don't want to have to install CYGWIN either in order to make >> the native implementation work on Windows. > > Please don't complain about stuff that isn't true or without being more specific. > I know of no dependency by the native implementation on Cygwin. > > In fact, installing Cygwin does tend to break the native implementation, depending on $PATH, because it has a link.exe that is a completely different program (ie: ln.exe). > I tried experimenting with using cl to drive link.exe but couldn't quite get it to work, for stupid reasons related to response files, which surely is fixable by extending response file support in cm3... > > As it is, I usually delete \cygwin\bin\link.exe, or remove cygwin from $PATH. > True, I don't ever uninstall Cygwin for testing, so the dependency could creep in by accident. > > >> I also still prefer the CMINSTALL, CMD, or BAT files >> for install as opposed to having to get Python or something else. Just my 2 cents. > > Once built and installed, there is no dependency on cmd, bat, cminstall, or python. > cminstall is pretty worthless imho, as long as you set PATH, INCLUDE, and LIB. > That is also a competing workaround for paths with spaces. > And allows moving around among different versions of Visual C++, which is good and bad. > Either you can have n installs of cm3, each configured tightly for one specific Visual C++, > or you can have 1 install of cm3, that is flexibly configured, that you "reconfigure" by altering the environment. I do the second. > > If you want to build the system, in a well automated way, with cmd and bat, you are welcome to write them. > Maybe the ones I left in the tree work, but i never use them any longer. > I use the Python all the time. > > Or you can manually cd around (as I suspect Tony does). > Personally I find cmd/bat among the worst programming languages ever and would rather not write it. > jscript via cscript.exe would be a good alternative, it is always there at least as of Windows 2000 or perhaps with IE installed on older versions, but then you have to duplicate work across Unix and Windows. > That is, for Windows-only no-cmd, no-install command line automation, JScript and VBScript are good choices, but Windows-only rules them out. The install is worth it. > Python is a very decent programming language that is very portable across "all" systems. > Perl would be the next best choice, though..I just don't like much. > sh/bash requires an install on Windows, so its built-inness on Posix I claim isn't a conclusive win. > I strongly encourage you to try out Python. > > Another avenue is to merge the sh/cmd/python into cm3 itself. > It shouldn't be all that hard. > > Modula-3 still needs a C linker. > And there is C code that I didn't put in -- hand.c and dtoa.c. > If someone writes a linker in Modula-3, or gets the .obj loader working, I'll be more open to eliminating C. > > But using C is much less error prone and much more portable, in some parts of the system. > > You may label C as "evil", but the other "evil" I am battling is tedious error prone "header cloning". > You pretty much must chose one. > The header cloning can be reduced, and its error proned-ness and difficulty various per system, depending on how gnarled up the headers are with ifdefs, compatibility hacks, processor-specificty, "cleansing" (where the installed headers are processor specific, deriving from #ifdef'ed or somesuch other files, but now I argue both sides, #ifdef is hard to read, but removing them removes information unless you track further back), etc. For example the OpenBSD headers are much more readable. I suspect NetBSD are too but haven't looked yet. The Linux headers contain a lot of #ifdef and they are also processor-specific I think -- you know, my /usr/include/errno.h on one system I think didn't show that x86 and SPARC use different values. > > > - Jay > > > > ________________________________ > > > Date: Wed, 31 Dec 2008 10:28:37 -0500 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay: > > > > Please explain what you mean by: > > > > "- BUILD_DIR does not necessarily equal HOST or TARGET, > because of how I structured I386_CYGWIN to be a "configuration" > where TARGET is still NT386." > > > > IMO, it would be wrong to change the meaning of things like "BUILD_DIR", "HOST", and "TARGET". Indeed, I have stuff that depends on the meaning of these things. Your statement seems to imply that "under the covers" you've made the CYGWIN implementation "appear" to be the same as the native Windows implementation. But they are not the same. > > > > On another note, All this CYGWIN stuff may be a nice way for die-hard Unix fans to run Modula-3 on Windows, and I have no objection to providing it, as long as it does not compromise the native Windows implementation. My main concern is the native implementation of Modula-3 on Windows. My preference would be to keep the NT386 implementation's dependencies on other stuff to a bare minimum, i.e., don't introduce anything that would require someone to have to acquire something besides what comes in the standard Windows OS in order to make Modula-3 run. As it is now, we already have to get a C compiler and linker. Fortunately, Microsoft has made the Visual Studio Express editions a free download, so this is not too bad. I don't want to have to install CYGWIN either in order to make the native implementation work on Windows. I also still prefer the CMINSTALL, CMD, or BAT files for install as opposed to having to get Python or something else. Just my 2 cents. > > > > Finally, I would go a step further and suggest that the Modula-3 implementation on every platform should strive to require minimal dependencies on anything not provided standard with that platform's operating system. > > > > Call me an idealist, but it just galls me that I have to have a C compiler/linker to build Modula-3. Modula-3 is a systems programming language. It should stand on its own. From a purely economical viewpoint, why should I have to buy something I don't want (C language development environment) in order to have the privilege of using what I do want (Modula-3 language development environment). > > > > Regards, > > Randy > >>>> Jay Krell 12/31/2008 11:52 AM>>> > CVSROOT:/usr/cvs > Changes by:jkrell at birch.08/12/31 11:52:08 > > Modified files: > cm3/m3-comm/netobj/src/: netobj-ov.tmpl > cm3/m3-comm/sharedobj/src/: sharedobj-ov.tmpl > cm3/m3-libs/libm3/src/bundleintf/: bundle-ov.tmpl > cm3/m3-ui/zeus/src/: m3zume-ov.tmpl > cm3/m3-ui/juno-2/juno-app/src/: m3makefile > > Log message: > Partly kinda sorta fix some cross build scenarios, without > affecting native builds. > > It's a larger more general problem though. > > - BUILD_DIR does not necessarily equal HOST or TARGET, > because of how I structured I386_CYGWIN to be a "configuration" > where TARGET is still NT386. > > - a cross build can run the shipped binary anyway, > and probably should (I didn't have the unshipped binaries around) > > - There should probably be automation to ensure all the tools are build. > ie: do-cm3-tools or do-cm3-crosstools. ie: build just the needed packages, > for the sniffed native platform. > > Cross builds have other problems. > > I keep hitting the following annoyances: > > ignoring foo/bar override when foo\bar already overridden > override paths should either be canonicalized to one slash type > or at least when there is a duplicate, canonicalize then and only > complain if canonicals vary > This is due to mixing I386_NT and I386_CYGWIN. > Similarly the problem demonstrated regarding m3unix.h in Uwaitpid.quake. > > Perhaps the change I made to allow forward slashes on Win32 was not good, esp. due to > its apparent inadequacy. > > The "lib" directory, specifically \cm3\lib\hand.obj is target..er, configuration dependent > the gcc hand.obj cannot be directly linked by Visual C++, for reasons to do with libgcc > > lib should probably have "target" or "build_dir" under it > > and/or hand.obj specifically should be merged into m3core.lib > > The mentor quake code generally fails in cross environments, probably due to slashes. > > host=NT386 (GNU?), target=LINUXLIBC6 m3zume is access violating > > I'm also highly suspicious of all this "override" stuff. > It clearly causes too much duplication and distribution of information. > I shouldn't have to know the directory structure of my dependencies, > and even if I do, I should be able to share that knowledge with their many > other dependents. The "scripts" directory also figures this sort of stuff out automatically.. > Being able to have multiple package stores is well and good. > I'm not sure they need to ever be used in an "unshipped" form, but instead just > use alternate roots and create new empty roots as needed. ? > > From rodney.bates at wichita.edu Thu Jan 29 22:43:37 2009 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 29 Jan 2009 15:43:37 -0600 Subject: [M3devel] Semantics of HasWideChars Message-ID: <49822309.7030407@wichita.edu> CM3's Text.HasWideChars, as implemented, has some strange behavior. From Text.i3: PROCEDURE HasWideChars (t: T): BOOLEAN; (* Returns "TRUE" if "t" contains any "WIDECHAR" characters. *) This reads to me like it refers to the actual characters comprising t, which also makes sense to a client of this interface. In fact, the implementation returns TRUE if the internal representation used is capable of representing any wide characters, even though they could all be narrow. Some examples: Text.HasWideChars(W"ABC") = TRUE Text.HasWideChars(W"ABC"&"def") = TRUE Text.HasWideChars(Text.Sub(W"ABC"&"def",3,3)) = FALSE Text.HasWideChars(Text.Sub(W"ABC"&"def",2,3)) = TRUE These results have nothing to do with the abstract view of TEXT as a string of characters. Moreover, a principal reason a client of Text would call HasWideChars would be to know whether it could subsequently call, e.g., Text.GetChar without having the value silently truncated to 8 bits. So I propose to fix HasWideChars. This will entail some performance penalties, as in many cases, it will have to go through the character values one at at time in a loop and range-check each one. The alternative would be to redefine HasWideChars as a one-sided approximation, (which is really is now) i.e., such that a result of FALSE means the string is guaranteed to contain no wide characters, but TRUE only means the real answer is unknown. Not very useful, and in that case, it really should be be renamed MightHaveWideChars. What do others think? Anybody using GetWideChars who would be affected? Rodney Bates From hosking at cs.purdue.edu Fri Jan 30 04:43:24 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 30 Jan 2009 14:43:24 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20090130032538.030B410D5DAA@birch.elegosoft.com> References: <20090130032538.030B410D5DAA@birch.elegosoft.com> Message-ID: Probably the wrong place for this. If it is x86-dependent it should go somewhere in the x86 hierarchy, not in a top-level directory like "context". On 30 Jan 2009, at 04:25, Jay Krell wrote: > 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 wagner at elegosoft.com Fri Jan 30 12:19:29 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 30 Jan 2009 12:19:29 +0100 Subject: [M3devel] Semantics of HasWideChars In-Reply-To: <49822309.7030407@wichita.edu> References: <49822309.7030407@wichita.edu> Message-ID: <20090130121929.vz7bla8tm8sc8ggk@mail.elegosoft.com> Quoting "Rodney M. Bates" : > CM3's Text.HasWideChars, as implemented, has some strange behavior. > From Text.i3: > > PROCEDURE HasWideChars (t: T): BOOLEAN; > (* Returns "TRUE" if "t" contains any "WIDECHAR" characters. *) > > This reads to me like it refers to the actual characters comprising t, > which also makes sense to a client of this interface. > > In fact, the implementation returns TRUE if the internal representation > used is capable of representing any wide characters, even though they > could all be narrow. > > Some examples: > > Text.HasWideChars(W"ABC") = TRUE > > Text.HasWideChars(W"ABC"&"def") = TRUE > > Text.HasWideChars(Text.Sub(W"ABC"&"def",3,3)) = FALSE > > Text.HasWideChars(Text.Sub(W"ABC"&"def",2,3)) = TRUE > > These results have nothing to do with the abstract view of TEXT as > a string of characters. Moreover, a principal reason a client of > Text would call HasWideChars would be to know whether it could > subsequently call, e.g., Text.GetChar without having the value > silently truncated to 8 bits. > > So I propose to fix HasWideChars. This will entail some performance > penalties, as in many cases, it will have to go through the character > values one at at time in a loop and range-check each one. > > The alternative would be to redefine HasWideChars as a one-sided > approximation, (which is really is now) i.e., such that a result > of FALSE means the string is guaranteed to contain no wide characters, > but TRUE only means the real answer is unknown. Not very useful, and in > that case, it really should be be renamed MightHaveWideChars. > > What do others think? Anybody using GetWideChars who would be > affected? I think it should be fixed. If anybody really needs the current semantics, we can add the `might have' predicate later, but I don't see that it is very useful ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Fri Jan 30 15:35:45 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 30 Jan 2009 15:35:45 +0100 Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various Message-ID: <1233326145.8086.12.camel@faramir.m3w.org> As I can see, structure and naming of cm3-min archive for AMD64_LINUX is not consistent with LINUXLIBC6 one... And there is no cminstall inside... What to do? What am I supposed to do with these two per configuration? m3core/src/unix% grep Uucon **/m3m* Common/m3makefile: Interface("Uucontext") darwin-amd64/m3makefile:Interface ("Uucontext") darwin-i386/m3makefile:Interface ("Uucontext") darwin-ppc/m3makefile:Interface ("Uucontext") freebsd-4/m3makefile:Interface ("Uucontext") linux-64/m3makefile:Interface ("Uucontext") linux-i386/m3makefile:Interface("Uucontext") solaris-2-x/m3makefile:Interface ("Uucontext") I've added my cm3.spec to archive and built binaries for LINUXLIBC6 without problem... Same day I tried AMD64_LINUX through analog process and - build fails. Anybody had success with AMD64_LINUX build in recent CVS heads? TIA, -- Dragi?a Duri? From jay.krell at cornell.edu Fri Jan 30 16:37:05 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 30 Jan 2009 15:37:05 +0000 Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various In-Reply-To: <1233326145.8086.12.camel@faramir.m3w.org> References: <1233326145.8086.12.camel@faramir.m3w.org> Message-ID: The alternate naming and lack of cminstall is mostly deliberate. The "posix" in "amd64 linux posix" is redundant. I just call it "amd64 linux". Deliberate. The lack of a timestamp is due to "not yet implemented". (Thus "mostly" deliberate.) cminstall isn't needed. Deliberate. You just extract the archive and set $PATH. The cm3.cfg file in the archive should just work. If it doesn't, please let me know. All the releases I make and upload are like this, including the LINUXLIBC6 ones. The Uucontext.i3 problem should be fixed now. - Jay ---------------------------------------- > From: dragisha at m3w.org > To: m3devel at elegosoft.com > Date: Fri, 30 Jan 2009 15:35:45 +0100 > Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various > > As I can see, structure and naming of cm3-min archive for AMD64_LINUX is > not consistent with LINUXLIBC6 one... And there is no cminstall > inside... What to do? > > What am I supposed to do with these two per configuration? > > m3core/src/unix% grep Uucon **/m3m* > Common/m3makefile: Interface("Uucontext") > darwin-amd64/m3makefile:Interface ("Uucontext") > darwin-i386/m3makefile:Interface ("Uucontext") > darwin-ppc/m3makefile:Interface ("Uucontext") > freebsd-4/m3makefile:Interface ("Uucontext") > linux-64/m3makefile:Interface ("Uucontext") > linux-i386/m3makefile:Interface("Uucontext") > solaris-2-x/m3makefile:Interface ("Uucontext") > > I've added my cm3.spec to archive and built binaries for LINUXLIBC6 > without problem... Same day I tried AMD64_LINUX through analog process > and - build fails. Anybody had success with AMD64_LINUX build in recent > CVS heads? > > TIA, > > -- > Dragi?a Duri? > From dragisha at m3w.org Fri Jan 30 22:33:16 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 30 Jan 2009 22:33:16 +0100 Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various In-Reply-To: References: <1233326145.8086.12.camel@faramir.m3w.org> Message-ID: <1233351197.8086.268.camel@faramir.m3w.org> What remains as a problem is /lib vs. /lib64 thing. I've done this by applying this: @@ -37,9 +37,13 @@ %------------------------------------------------------------------------------ readonly BIN_INSTALL = INSTALL_ROOT & SL & "bin" % executables -readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & PROFILING_P % libraries +if equal(TARGET, "AMD64_LINUX") + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib64" & PROFILING_P % libraries +else + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & PROFILING_P % libraries +end readonly PKG_INSTALL = INSTALL_ROOT & SL & "pkg" % packages readonly DOC_INSTALL = INSTALL_ROOT & SL & "doc" % documents This way I can choose which development to use, while maintaining both runtimes on-system. LINUXLIBC6 and AMD64_LINUX separation will work for pkg, but folder containing links - $INSTALLROOT + SL + "lib" on AMD64_LINUX must use lib64. On Fri, 2009-01-30 at 15:37 +0000, Jay wrote: > The alternate naming and lack of cminstall is mostly deliberate. > > The "posix" in "amd64 linux posix" is redundant. I just call it "amd64 linux". Deliberate. > > The lack of a timestamp is due to "not yet implemented". (Thus "mostly" deliberate.) > > cminstall isn't needed. Deliberate. > > You just extract the archive and set $PATH. > The cm3.cfg file in the archive should just work. > If it doesn't, please let me know. > > > All the releases I make and upload are like this, including the LINUXLIBC6 ones. > > > The Uucontext.i3 problem should be fixed now. > > - Jay > > ---------------------------------------- > > From: dragisha at m3w.org > > To: m3devel at elegosoft.com > > Date: Fri, 30 Jan 2009 15:35:45 +0100 > > Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various > > > > As I can see, structure and naming of cm3-min archive for AMD64_LINUX is > > not consistent with LINUXLIBC6 one... And there is no cminstall > > inside... What to do? > > > > What am I supposed to do with these two per configuration? > > > > m3core/src/unix% grep Uucon **/m3m* > > Common/m3makefile: Interface("Uucontext") > > darwin-amd64/m3makefile:Interface ("Uucontext") > > darwin-i386/m3makefile:Interface ("Uucontext") > > darwin-ppc/m3makefile:Interface ("Uucontext") > > freebsd-4/m3makefile:Interface ("Uucontext") > > linux-64/m3makefile:Interface ("Uucontext") > > linux-i386/m3makefile:Interface("Uucontext") > > solaris-2-x/m3makefile:Interface ("Uucontext") > > > > I've added my cm3.spec to archive and built binaries for LINUXLIBC6 > > without problem... Same day I tried AMD64_LINUX through analog process > > and - build fails. Anybody had success with AMD64_LINUX build in recent > > CVS heads? > > > > TIA, > > > > -- > > Dragi?a Duri? > > -- Dragi?a Duri? From jay.krell at cornell.edu Fri Jan 30 22:53:17 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 30 Jan 2009 21:53:17 +0000 Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various In-Reply-To: <1233351197.8086.268.camel@faramir.m3w.org> References: <1233326145.8086.12.camel@faramir.m3w.org> <1233351197.8086.268.camel@faramir.m3w.org> Message-ID: That's very reasonable. You could just commit that imho. More general and reasonable would be: > + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & WORD_SIZE & PROFILING_P % libraries or even > + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib/" & TARGET & PROFILING_P % libraries though granted, most systems aren't biarch/multiarch, so what you have is maybe best, possibly manually adding in biarch/multiarch systems as they are discovered -- e.g. most but not all x86 systems. (This area is actually "surprisingly large" Irix has two 32bit ABIs, there are 32bit ABIs for IA64, I think like on HP-UX). The full lib/TARGET helps for NT386 vs. NT386GNU. - Jay ---------------------------------------- > Subject: RE: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various > From: dragisha at m3w.org > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Date: Fri, 30 Jan 2009 22:33:16 +0100 > > What remains as a problem is /lib vs. /lib64 thing. > > I've done this by applying this: > > @@ -37,9 +37,13 @@ > > %------------------------------------------------------------------------------ > > readonly BIN_INSTALL = INSTALL_ROOT & SL & "bin" % executables > -readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & PROFILING_P % libraries > +if equal(TARGET, "AMD64_LINUX") > + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib64" & PROFILING_P % libraries > +else > + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & PROFILING_P % libraries > +end > readonly PKG_INSTALL = INSTALL_ROOT & SL & "pkg" % packages > readonly DOC_INSTALL = INSTALL_ROOT & SL & "doc" % documents > > > This way I can choose which development to use, while maintaining both > runtimes on-system. LINUXLIBC6 and AMD64_LINUX separation will work for > pkg, but folder containing links - $INSTALLROOT + SL + "lib" on > AMD64_LINUX must use lib64. > > On Fri, 2009-01-30 at 15:37 +0000, Jay wrote: >> The alternate naming and lack of cminstall is mostly deliberate. >> >> The "posix" in "amd64 linux posix" is redundant. I just call it "amd64 linux". Deliberate. >> >> The lack of a timestamp is due to "not yet implemented". (Thus "mostly" deliberate.) >> >> cminstall isn't needed. Deliberate. >> >> You just extract the archive and set $PATH. >> The cm3.cfg file in the archive should just work. >> If it doesn't, please let me know. >> >> >> All the releases I make and upload are like this, including the LINUXLIBC6 ones. >> >> >> The Uucontext.i3 problem should be fixed now. >> >> - Jay >> >> ---------------------------------------- >>> From: dragisha at m3w.org >>> To: m3devel at elegosoft.com >>> Date: Fri, 30 Jan 2009 15:35:45 +0100 >>> Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various >>> >>> As I can see, structure and naming of cm3-min archive for AMD64_LINUX is >>> not consistent with LINUXLIBC6 one... And there is no cminstall >>> inside... What to do? >>> >>> What am I supposed to do with these two per configuration? >>> >>> m3core/src/unix% grep Uucon **/m3m* >>> Common/m3makefile: Interface("Uucontext") >>> darwin-amd64/m3makefile:Interface ("Uucontext") >>> darwin-i386/m3makefile:Interface ("Uucontext") >>> darwin-ppc/m3makefile:Interface ("Uucontext") >>> freebsd-4/m3makefile:Interface ("Uucontext") >>> linux-64/m3makefile:Interface ("Uucontext") >>> linux-i386/m3makefile:Interface("Uucontext") >>> solaris-2-x/m3makefile:Interface ("Uucontext") >>> >>> I've added my cm3.spec to archive and built binaries for LINUXLIBC6 >>> without problem... Same day I tried AMD64_LINUX through analog process >>> and - build fails. Anybody had success with AMD64_LINUX build in recent >>> CVS heads? >>> >>> TIA, >>> >>> -- >>> Dragi?a Duri? >>> > -- > Dragi?a Duri? > From dragisha at m3w.org Fri Jan 30 23:02:35 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 30 Jan 2009 23:02:35 +0100 Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various In-Reply-To: References: <1233326145.8086.12.camel@faramir.m3w.org> <1233351197.8086.268.camel@faramir.m3w.org> Message-ID: <1233352955.8086.270.camel@faramir.m3w.org> "lib" & WORD_SIZE is not usual, IMO, because lib64 is addition, and lib was always there. Also - best approach would be to scratch itch by itch. Trying too generally can make mess in advance. What script do you use to make yours cm3-min? dd On Fri, 2009-01-30 at 21:53 +0000, Jay wrote: > That's very reasonable. You could just commit that imho. > > > More general and reasonable would be: > > > > + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & WORD_SIZE & PROFILING_P % libraries > > or even > > > + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib/" & TARGET & PROFILING_P % libraries > > > though granted, most systems aren't biarch/multiarch, so what you have is maybe best, possibly manually adding in biarch/multiarch systems as they are discovered -- e.g. most but not all x86 systems. (This area is actually "surprisingly large" Irix has two 32bit ABIs, there are 32bit ABIs for IA64, I think like on HP-UX). > > > The full lib/TARGET helps for NT386 vs. NT386GNU. > > - Jay > > > ---------------------------------------- > > Subject: RE: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various > > From: dragisha at m3w.org > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Date: Fri, 30 Jan 2009 22:33:16 +0100 > > > > What remains as a problem is /lib vs. /lib64 thing. > > > > I've done this by applying this: > > > > @@ -37,9 +37,13 @@ > > > > %------------------------------------------------------------------------------ > > > > readonly BIN_INSTALL = INSTALL_ROOT & SL & "bin" % executables > > -readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & PROFILING_P % libraries > > +if equal(TARGET, "AMD64_LINUX") > > + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib64" & PROFILING_P % libraries > > +else > > + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & PROFILING_P % libraries > > +end > > readonly PKG_INSTALL = INSTALL_ROOT & SL & "pkg" % packages > > readonly DOC_INSTALL = INSTALL_ROOT & SL & "doc" % documents > > > > > > This way I can choose which development to use, while maintaining both > > runtimes on-system. LINUXLIBC6 and AMD64_LINUX separation will work for > > pkg, but folder containing links - $INSTALLROOT + SL + "lib" on > > AMD64_LINUX must use lib64. > > > > On Fri, 2009-01-30 at 15:37 +0000, Jay wrote: > >> The alternate naming and lack of cminstall is mostly deliberate. > >> > >> The "posix" in "amd64 linux posix" is redundant. I just call it "amd64 linux". Deliberate. > >> > >> The lack of a timestamp is due to "not yet implemented". (Thus "mostly" deliberate.) > >> > >> cminstall isn't needed. Deliberate. > >> > >> You just extract the archive and set $PATH. > >> The cm3.cfg file in the archive should just work. > >> If it doesn't, please let me know. > >> > >> > >> All the releases I make and upload are like this, including the LINUXLIBC6 ones. > >> > >> > >> The Uucontext.i3 problem should be fixed now. > >> > >> - Jay > >> > >> ---------------------------------------- > >>> From: dragisha at m3w.org > >>> To: m3devel at elegosoft.com > >>> Date: Fri, 30 Jan 2009 15:35:45 +0100 > >>> Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various > >>> > >>> As I can see, structure and naming of cm3-min archive for AMD64_LINUX is > >>> not consistent with LINUXLIBC6 one... And there is no cminstall > >>> inside... What to do? > >>> > >>> What am I supposed to do with these two per configuration? > >>> > >>> m3core/src/unix% grep Uucon **/m3m* > >>> Common/m3makefile: Interface("Uucontext") > >>> darwin-amd64/m3makefile:Interface ("Uucontext") > >>> darwin-i386/m3makefile:Interface ("Uucontext") > >>> darwin-ppc/m3makefile:Interface ("Uucontext") > >>> freebsd-4/m3makefile:Interface ("Uucontext") > >>> linux-64/m3makefile:Interface ("Uucontext") > >>> linux-i386/m3makefile:Interface("Uucontext") > >>> solaris-2-x/m3makefile:Interface ("Uucontext") > >>> > >>> I've added my cm3.spec to archive and built binaries for LINUXLIBC6 > >>> without problem... Same day I tried AMD64_LINUX through analog process > >>> and - build fails. Anybody had success with AMD64_LINUX build in recent > >>> CVS heads? > >>> > >>> TIA, > >>> > >>> -- > >>> Dragi?a Duri? > >>> > > -- > > Dragi?a Duri? > > -- Dragi?a Duri? From jay.krell at cornell.edu Fri Jan 30 23:33:56 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 30 Jan 2009 22:33:56 +0000 Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various In-Reply-To: <1233352955.8086.270.camel@faramir.m3w.org> References: <1233326145.8086.12.camel@faramir.m3w.org> <1233351197.8086.268.camel@faramir.m3w.org> <1233352955.8086.270.camel@faramir.m3w.org> Message-ID: > What script do you use to make yours cm3-min? scripts/python/make-dist.py - Jay ---------------------------------------- > From: dragisha at m3w.org > To: jay.krell at cornell.edu > Date: Fri, 30 Jan 2009 23:02:35 +0100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various > > "lib" & WORD_SIZE is not usual, IMO, because lib64 is addition, and lib > was always there. > > Also - best approach would be to scratch itch by itch. Trying too > generally can make mess in advance. > > What script do you use to make yours cm3-min? > > dd > > On Fri, 2009-01-30 at 21:53 +0000, Jay wrote: >> That's very reasonable. You could just commit that imho. >> >> >> More general and reasonable would be: >> >> >>> + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & WORD_SIZE & PROFILING_P % libraries >> >> or even >> >>> + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib/" & TARGET & PROFILING_P % libraries >> >> >> though granted, most systems aren't biarch/multiarch, so what you have is maybe best, possibly manually adding in biarch/multiarch systems as they are discovered -- e.g. most but not all x86 systems. (This area is actually "surprisingly large" Irix has two 32bit ABIs, there are 32bit ABIs for IA64, I think like on HP-UX). >> >> >> The full lib/TARGET helps for NT386 vs. NT386GNU. >> >> - Jay >> >> >> ---------------------------------------- >>> Subject: RE: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various >>> From: dragisha at m3w.org >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Date: Fri, 30 Jan 2009 22:33:16 +0100 >>> >>> What remains as a problem is /lib vs. /lib64 thing. >>> >>> I've done this by applying this: >>> >>> @@ -37,9 +37,13 @@ >>> >>> %------------------------------------------------------------------------------ >>> >>> readonly BIN_INSTALL = INSTALL_ROOT & SL & "bin" % executables >>> -readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & PROFILING_P % libraries >>> +if equal(TARGET, "AMD64_LINUX") >>> + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib64" & PROFILING_P % libraries >>> +else >>> + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & PROFILING_P % libraries >>> +end >>> readonly PKG_INSTALL = INSTALL_ROOT & SL & "pkg" % packages >>> readonly DOC_INSTALL = INSTALL_ROOT & SL & "doc" % documents >>> >>> >>> This way I can choose which development to use, while maintaining both >>> runtimes on-system. LINUXLIBC6 and AMD64_LINUX separation will work for >>> pkg, but folder containing links - $INSTALLROOT + SL + "lib" on >>> AMD64_LINUX must use lib64. >>> >>> On Fri, 2009-01-30 at 15:37 +0000, Jay wrote: >>>> The alternate naming and lack of cminstall is mostly deliberate. >>>> >>>> The "posix" in "amd64 linux posix" is redundant. I just call it "amd64 linux". Deliberate. >>>> >>>> The lack of a timestamp is due to "not yet implemented". (Thus "mostly" deliberate.) >>>> >>>> cminstall isn't needed. Deliberate. >>>> >>>> You just extract the archive and set $PATH. >>>> The cm3.cfg file in the archive should just work. >>>> If it doesn't, please let me know. >>>> >>>> >>>> All the releases I make and upload are like this, including the LINUXLIBC6 ones. >>>> >>>> >>>> The Uucontext.i3 problem should be fixed now. >>>> >>>> - Jay >>>> >>>> ---------------------------------------- >>>>> From: dragisha at m3w.org >>>>> To: m3devel at elegosoft.com >>>>> Date: Fri, 30 Jan 2009 15:35:45 +0100 >>>>> Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various >>>>> >>>>> As I can see, structure and naming of cm3-min archive for AMD64_LINUX is >>>>> not consistent with LINUXLIBC6 one... And there is no cminstall >>>>> inside... What to do? >>>>> >>>>> What am I supposed to do with these two per configuration? >>>>> >>>>> m3core/src/unix% grep Uucon **/m3m* >>>>> Common/m3makefile: Interface("Uucontext") >>>>> darwin-amd64/m3makefile:Interface ("Uucontext") >>>>> darwin-i386/m3makefile:Interface ("Uucontext") >>>>> darwin-ppc/m3makefile:Interface ("Uucontext") >>>>> freebsd-4/m3makefile:Interface ("Uucontext") >>>>> linux-64/m3makefile:Interface ("Uucontext") >>>>> linux-i386/m3makefile:Interface("Uucontext") >>>>> solaris-2-x/m3makefile:Interface ("Uucontext") >>>>> >>>>> I've added my cm3.spec to archive and built binaries for LINUXLIBC6 >>>>> without problem... Same day I tried AMD64_LINUX through analog process >>>>> and - build fails. Anybody had success with AMD64_LINUX build in recent >>>>> CVS heads? >>>>> >>>>> TIA, >>>>> >>>>> -- >>>>> Dragi?a Duri? >>>>> >>> -- >>> Dragi?a Duri? >>> > -- > Dragi?a Duri? > From jay.krell at cornell.edu Fri Jan 30 23:49:25 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 30 Jan 2009 22:49:25 +0000 Subject: [M3devel] using *context functions for user threading? Message-ID: Tony, can you tell me more of what you have in mind here? In particular...I /think/ it goes like: use getcontext + makecontext to "create a thread" use simple struct copying/memcpy of the third parameter to the signal handler for context switching in particular -- setcontext/makecontext never used -- except to start a thread, but not to switch to/from already started threads. ? Implication here is that even on systems without context APIs, our ucontext_t needs to match what the signal handler gets. That isn't the case for what I just got "working" (prototype, proof of concept, whatever) on OpenBSD, but easy enough. An alternative is to call setcontext in the signal handler, but that makes me nervous. It seems best to exit "cleanly" out of a signal handler? And then I get to seeing very murky things, like, can a system call be interrupted by an alarm signal? If so, switching threads then...what would that do? Seems bad. So then I guess I see the origin of all the original system call wrappers -- to turn of thread switching during system calls. ? The current code does appear to longjmp out of a system call -- or rather, to longjmp from one alarm signal to another. Again this seems confusing if alarm signals can interrupt system calls. Some abstraction that encompasses Win32 fibers might be nice, though there would remain the question of how to preempt. - Jay From hosking at cs.purdue.edu Sat Jan 31 04:09:23 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 31 Jan 2009 14:09:23 +1100 Subject: [M3devel] using *context functions for user threading? In-Reply-To: References: Message-ID: On 31 Jan 2009, at 09:49, Jay wrote: > Tony, can you tell me more of what you have in mind here? I didn't plan anything other than using swapcontext instead of longjmp in switch_thread, and using makecontext instead of InitContext to get a forked thread's context. > In particular...I /think/ it goes like: > > > use getcontext + makecontext to "create a thread" > use simple struct copying/memcpy of the third parameter to the > signal handler for context switching No, swapcontext. > in particular -- setcontext/makecontext never used -- except to > start a thread, but not to switch to/from already started threads. Right. > ? > > > Implication here is that even on systems without context APIs, our > ucontext_t needs to match what the signal handler gets. That isn't > the case for what I just got "working" (prototype, proof of concept, > whatever) on OpenBSD, but easy enough. I don't know what you are saying here. swapcontext should be enough. > An alternative is to call setcontext in the signal handler, but that > makes me nervous. > It seems best to exit "cleanly" out of a signal handler? You're right, but this is probably broken for the current longjmp- based implementation too. > And then I get to seeing very murky things, like, can a system call > be interrupted by an alarm signal? If so, switching threads > then...what would that do? Seems bad. Yes, I was never convinced that the longjmp-based implementation was safe either. I figured that it probably worked only because it was a single-threaded process, but I don't know if that really prevents a timer signal arriving inside the signal handler, and what impact that might have. > So then I guess I see the origin of all the original system call > wrappers -- to turn of thread switching during system calls. No, those were only for GC. > ? > > The current code does appear to longjmp out of a system call -- or > rather, to longjmp from one alarm signal to another. Again this > seems confusing if alarm signals can interrupt system calls. Right... > Some abstraction that encompasses Win32 fibers might be nice, though > there would remain the question of how to preempt. The safest solution for all of this is to have the timer signal handler set a flag and for the M3 compiler to inject a test of the flag at calls/backward branches, and explicitly yield if the flag is set. > > > - Jay From jay.krell at cornell.edu Sat Jan 31 04:46:53 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 31 Jan 2009 03:46:53 +0000 Subject: [M3devel] using *context functions for user threading? In-Reply-To: References: Message-ID: I think setjmp/longjmp would continue to be ok. It has very little machine dependency, and I /guess/ works and is portable. I guess. We are both leary, but it's been there a while. It is InitContext imho that could be "better" -- more portable, remove all the mucking around with frames and stack pointers. I was late to see this because it is in the machine-independent chunk of code. What does swapcontext buy over setjmp/longjmp, once a thread is "already started"? I can see there is a "unifying" reason. If makecontext is used to InitContext, then swapcontext is needed to "start" a thread. setjmp/longjmp could be used to suspend/resume, but if you phrase "start" and "resume" as the same thing, then "stuck" with swapcontext. For some time I was under the impression that Modula-3 repeatedly longjmped to a buffer that only had setjmp called once, or where the function that setjmp was called from had returned, but I'm not sure of that now. It seems viable to "follow the rules" wrt setjmp/longjmp, other than the "escaping from a signal handler" aspect. > The safest solution for all of this is to have the timer signal > handler set a flag and for the M3 compiler to inject a test of the > flag at calls/backward branches, and explicitly yield if the flag is > set. Yes that makes me much more comfortable as well. Is it cut & dry agreed to and such? Someone should just do it? Or there are concerns that: - it might not be often enough? There are no "forward" or "backward" branches at the Modula-3 level, are there? It is at the whim of the backend, right? I guess you might be able to conceptually label branches as forward or backward, even if the backend "rotates" things or adds more branches (you know, like loops often starting with a forward branch). - it might be too often? - it might be too code bloating? Or too slow when "checks" greatly outweight actual switches? - a call out to a function or a check of a variable? - only do it if a compiler command line switch is given? Or for platforms known to support user threads? (given the design though..it could be every platform) Though I raise the issues, it still seems the right thing, vs. longjmping out of a signal handler. The OpenBSD sigaction manpage does seem to have in mind an ability to "switch threads" in a signal handler: "When a caught signal is delivered, the current state of the process is saved, a new signal mask is calculated (as described below), and the signal handler is invoked. The call to the handler is arranged so that if the signal han- dling routine returns normally the process will resume execution in the context from before the signal's delivery. If the process wishes to re- sume in a different context, then it must arrange to restore the previous context itself. " but the idea here is not longjmp or I think exactly swapcontext, but manually swapping a context with the third parameter to the signal handler. > single-threaded process, but I don't know if that really prevents a > timer signal arriving inside the signal handler, and what impact that > might have. Right. I don't see that control-c can't come in at about the same time as timer. Though I think sigaction allows for fixing this -- block all signals during the signal handler. I'll reread some manpages. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Sat, 31 Jan 2009 14:09:23 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] using *context functions for user threading? > > On 31 Jan 2009, at 09:49, Jay wrote: > >> Tony, can you tell me more of what you have in mind here? > > I didn't plan anything other than using swapcontext instead of longjmp > in switch_thread, and using makecontext instead of InitContext to get > a forked thread's context. > >> In particular...I /think/ it goes like: >> >> >> use getcontext + makecontext to "create a thread" >> use simple struct copying/memcpy of the third parameter to the >> signal handler for context switching > > No, swapcontext. > >> in particular -- setcontext/makecontext never used -- except to >> start a thread, but not to switch to/from already started threads. > > Right. > >> ? >> >> >> Implication here is that even on systems without context APIs, our >> ucontext_t needs to match what the signal handler gets. That isn't >> the case for what I just got "working" (prototype, proof of concept, >> whatever) on OpenBSD, but easy enough. > > I don't know what you are saying here. swapcontext should be enough. > >> An alternative is to call setcontext in the signal handler, but that >> makes me nervous. >> It seems best to exit "cleanly" out of a signal handler? > > You're right, but this is probably broken for the current longjmp- > based implementation too. > >> And then I get to seeing very murky things, like, can a system call >> be interrupted by an alarm signal? If so, switching threads >> then...what would that do? Seems bad. > > Yes, I was never convinced that the longjmp-based implementation was > safe either. I figured that it probably worked only because it was a > single-threaded process, but I don't know if that really prevents a > timer signal arriving inside the signal handler, and what impact that > might have. > >> So then I guess I see the origin of all the original system call >> wrappers -- to turn of thread switching during system calls. > > No, those were only for GC. > >> ? >> >> The current code does appear to longjmp out of a system call -- or >> rather, to longjmp from one alarm signal to another. Again this >> seems confusing if alarm signals can interrupt system calls. > > Right... > >> Some abstraction that encompasses Win32 fibers might be nice, though >> there would remain the question of how to preempt. > > The safest solution for all of this is to have the timer signal > handler set a flag and for the M3 compiler to inject a test of the > flag at calls/backward branches, and explicitly yield if the flag is > set. > >> >> >> - Jay > From hosking at cs.purdue.edu Sat Jan 31 05:08:49 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 31 Jan 2009 15:08:49 +1100 Subject: [M3devel] using *context functions for user threading? In-Reply-To: References: Message-ID: <4D53B3C7-7089-4372-AD7C-3B879D43D2C8@cs.purdue.edu> It doesn't work because of security enhancements that prevent forgery of a context as the current system does. swapcontext *is* used on Solaris (as currently implemented) but the InitContext code needs replacing with makecontext. longjmp is not async-signal-safe, and so just as bad as swapcontext when called from a signal handler. Indeed, BSD seems to imply swapcontext can be used in a signal handler. I don't want to leap into explicit polling of a yield flag without further thought. Better to get 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 31 Jan 2009, at 14:46, Jay wrote: > > I think setjmp/longjmp would continue to be ok. > It has very little machine dependency, and I /guess/ works and is > portable. > I guess. We are both leary, but it's been there a while. > It is InitContext imho that could be "better" -- more portable, > remove all the > mucking around with frames and stack pointers. > I was late to see this because it is in the machine-independent > chunk of code. > > > What does swapcontext buy over setjmp/longjmp, once a thread is > "already started"? > I can see there is a "unifying" reason. > If makecontext is used to InitContext, then swapcontext is needed to > "start" a thread. > setjmp/longjmp could be used to suspend/resume, but if you phrase > "start" and "resume" as the same thing, then "stuck" with swapcontext. > > > For some time I was under the impression that Modula-3 repeatedly > longjmped to a buffer that only had setjmp called once, or where the > function that setjmp was called from had returned, but I'm not sure > of that now. It seems viable to "follow the rules" wrt setjmp/ > longjmp, other than the "escaping from a signal handler" aspect. > > >> The safest solution for all of this is to have the timer signal >> handler set a flag and for the M3 compiler to inject a test of the >> flag at calls/backward branches, and explicitly yield if the flag is >> set. > > > Yes that makes me much more comfortable as well. > > > Is it cut & dry agreed to and such? > > > Someone should just do it? > > > Or there are concerns that: > - it might not be often enough? > There are no "forward" or "backward" branches at the Modula-3 > level, are there? > It is at the whim of the backend, right? I guess you might be > able to > conceptually label branches as forward or backward, even if the > backend "rotates" things or > adds more branches (you know, like loops often starting with a > forward branch). > - it might be too often? > - it might be too code bloating? Or too slow when "checks" greatly > outweight actual switches? > - a call out to a function or a check of a variable? > - only do it if a compiler command line switch is given? Or for > platforms known to support user threads? (given the design > though..it could be every platform) > > > Though I raise the issues, it still seems the right thing, vs. > longjmping out of a signal handler. > > > The OpenBSD sigaction manpage does seem to have in mind an ability > to "switch threads" in a signal handler: > > > "When a caught > signal is delivered, the current state of the process is saved, > a new > signal mask is calculated (as described below), and the signal > handler is > invoked. The call to the handler is arranged so that if the > signal han- > dling routine returns normally the process will resume execution > in the > context from before the signal's delivery. If the process > wishes to re- > sume in a different context, then it must arrange to restore the > previous > context itself. > " > > but the idea here is not longjmp or I think exactly swapcontext, but > manually swapping a context with the third parameter to the signal > handler. > > >> single-threaded process, but I don't know if that really prevents a >> timer signal arriving inside the signal handler, and what impact that >> might have. > > > Right. I don't see that control-c can't come in at about the same > time as timer. > Though I think sigaction allows for fixing this -- block all signals > during the signal handler. > I'll reread some manpages. > > > - Jay > > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Sat, 31 Jan 2009 14:09:23 +1100 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] using *context functions for user threading? >> >> On 31 Jan 2009, at 09:49, Jay wrote: >> >>> Tony, can you tell me more of what you have in mind here? >> >> I didn't plan anything other than using swapcontext instead of >> longjmp >> in switch_thread, and using makecontext instead of InitContext to get >> a forked thread's context. >> >>> In particular...I /think/ it goes like: >>> >>> >>> use getcontext + makecontext to "create a thread" >>> use simple struct copying/memcpy of the third parameter to the >>> signal handler for context switching >> >> No, swapcontext. >> >>> in particular -- setcontext/makecontext never used -- except to >>> start a thread, but not to switch to/from already started threads. >> >> Right. >> >>> ? >>> >>> >>> Implication here is that even on systems without context APIs, our >>> ucontext_t needs to match what the signal handler gets. That isn't >>> the case for what I just got "working" (prototype, proof of concept, >>> whatever) on OpenBSD, but easy enough. >> >> I don't know what you are saying here. swapcontext should be enough. >> >>> An alternative is to call setcontext in the signal handler, but that >>> makes me nervous. >>> It seems best to exit "cleanly" out of a signal handler? >> >> You're right, but this is probably broken for the current longjmp- >> based implementation too. >> >>> And then I get to seeing very murky things, like, can a system call >>> be interrupted by an alarm signal? If so, switching threads >>> then...what would that do? Seems bad. >> >> Yes, I was never convinced that the longjmp-based implementation was >> safe either. I figured that it probably worked only because it was a >> single-threaded process, but I don't know if that really prevents a >> timer signal arriving inside the signal handler, and what impact that >> might have. >> >>> So then I guess I see the origin of all the original system call >>> wrappers -- to turn of thread switching during system calls. >> >> No, those were only for GC. >> >>> ? >>> >>> The current code does appear to longjmp out of a system call -- or >>> rather, to longjmp from one alarm signal to another. Again this >>> seems confusing if alarm signals can interrupt system calls. >> >> Right... >> >>> Some abstraction that encompasses Win32 fibers might be nice, though >>> there would remain the question of how to preempt. >> >> The safest solution for all of this is to have the timer signal >> handler set a flag and for the M3 compiler to inject a test of the >> flag at calls/backward branches, and explicitly yield if the flag is >> set. >> >>> >>> >>> - Jay >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Jan 31 18:31:39 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 31 Jan 2009 18:31:39 +0100 Subject: [M3devel] make_dir failure Message-ID: <1233423099.16504.4.camel@faramir.m3w.org> I am trying to build rpm for AMD64_LINUX... I have this situation (strace output fragment) 25802 utimes("/tmp/cm3/usr/local/cm3/pkg/m3core/AMD64_LINUX/libm3core.so", {{1233421816, 0}, {1233421693, 0}}) = 0 25802 stat("/tmp/cm3/usr/local/cm3/bin/../lib64", 0x7fff53109270) = -1 ENOENT (No such file or directory) 25802 stat("/tmp/cm3/usr/local/cm3/bin/..", 0x7fff531090d0) = -1 ENOENT (No such file or directory) 25802 stat("/tmp/cm3/usr/local/cm3/bin", 0x7fff53108f30) = -1 ENOENT (No such file or directory) 25802 stat("/tmp/cm3/usr/local/cm3", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 25802 mkdir("/tmp/cm3/usr/local/cm3/bin", 0777) = 0 25802 mkdir("/tmp/cm3/usr/local/cm3/bin/..", 0777) = -1 EEXIST (File exists) 25802 fcntl(2, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) 25802 fcntl(2, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0 25802 write(2, "\"/usr/src/redhat/BUILD/cm3/m3-li"..., 312) = 312 25802 fcntl(2, F_SETFL, O_RDWR|O_LARGEFILE) = 0 25802 fcntl(2, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) 25802 fcntl(2, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0 25802 write(2, "\n", 1) = 1 25802 fcntl(2, F_SETFL, O_RDWR|O_LARGEFILE) = 0 25802 fcntl(1, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) 25802 fcntl(1, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0 25802 write(1, "Fatal Error: package build faile"..., 34) = 34 25802 fcntl(1, F_SETFL, O_RDWR|O_LARGEFILE) = 0 25802 unlink("m3make.args") = 0 .M3SHIP command in question is: make_dir("/usr/local/cm3/bin/../lib64") Looks like path normalization function are a bit... confused? -- Dragi?a Duri? From jay.krell at cornell.edu Sat Jan 31 20:05:36 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 31 Jan 2009 19:05:36 +0000 Subject: [M3devel] make_dir failure In-Reply-To: <1233423099.16504.4.camel@faramir.m3w.org> References: <1233423099.16504.4.camel@faramir.m3w.org> Message-ID: It looks ok to me. What happens if you create /usr/local/cm3/bin and /tmp/cm3/usr/local/cm3/bin? Unix is imho bogusly finicky and doesn't like foo/../bar unless foo exists. Windows parses out the .. without checking if foo exists, leaving this sort of construct more useful. The Modula-3/Quake code I think never smushes out the ".." here, but making it do so is very reasonable. This is part of how I avoid cminstall and just having one cm3.cfg -- all the paths are computed from the path of cm3/cm3.cfg. Probably defaulting them in the Modula-3 code instead of requiring them be set by Quake would be good, as part of a larger goal of more Modula-3 and less Quake. Quake coudl still override them if necessary. - Jay ---------------------------------------- > From: dragisha at m3w.org > To: m3devel at elegosoft.com > Date: Sat, 31 Jan 2009 18:31:39 +0100 > Subject: [M3devel] make_dir failure > > I am trying to build rpm for AMD64_LINUX... I have this situation > (strace output fragment) > > 25802 utimes("/tmp/cm3/usr/local/cm3/pkg/m3core/AMD64_LINUX/libm3core.so", {{1233421816, 0}, {1233421693, 0}}) = 0 > 25802 stat("/tmp/cm3/usr/local/cm3/bin/../lib64", 0x7fff53109270) = -1 ENOENT (No such file or directory) > 25802 stat("/tmp/cm3/usr/local/cm3/bin/..", 0x7fff531090d0) = -1 ENOENT (No such file or directory) > 25802 stat("/tmp/cm3/usr/local/cm3/bin", 0x7fff53108f30) = -1 ENOENT (No such file or directory) > 25802 stat("/tmp/cm3/usr/local/cm3", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 > 25802 mkdir("/tmp/cm3/usr/local/cm3/bin", 0777) = 0 > 25802 mkdir("/tmp/cm3/usr/local/cm3/bin/..", 0777) = -1 EEXIST (File exists) > 25802 fcntl(2, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) > 25802 fcntl(2, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0 > 25802 write(2, "\"/usr/src/redhat/BUILD/cm3/m3-li"..., 312) = 312 > 25802 fcntl(2, F_SETFL, O_RDWR|O_LARGEFILE) = 0 > 25802 fcntl(2, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) > 25802 fcntl(2, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0 > 25802 write(2, "\n", 1) = 1 > 25802 fcntl(2, F_SETFL, O_RDWR|O_LARGEFILE) = 0 > 25802 fcntl(1, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) > 25802 fcntl(1, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0 > 25802 write(1, "Fatal Error: package build faile"..., 34) = 34 > 25802 fcntl(1, F_SETFL, O_RDWR|O_LARGEFILE) = 0 > 25802 unlink("m3make.args") = 0 > > .M3SHIP command in question is: > > make_dir("/usr/local/cm3/bin/../lib64") > > Looks like path normalization function are a bit... confused? > -- > Dragi?a Duri? > > From dragisha at m3w.org Sat Jan 31 21:26:19 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 31 Jan 2009 21:26:19 +0100 Subject: [M3devel] make_dir failure In-Reply-To: References: <1233423099.16504.4.camel@faramir.m3w.org> Message-ID: <1233433579.16504.7.camel@faramir.m3w.org> This can look good to you, but this breaks with errno 17 - file exists. Look at 7th row of strace. On Sat, 2009-01-31 at 19:05 +0000, Jay wrote: > It looks ok to me. > What happens if you create /usr/local/cm3/bin and /tmp/cm3/usr/local/cm3/bin? > Unix is imho bogusly finicky and doesn't like foo/../bar unless foo exists. > Windows parses out the .. without checking if foo exists, leaving this sort of construct more useful. > The Modula-3/Quake code I think never smushes out the ".." here, but making it do so is very reasonable. > > > This is part of how I avoid cminstall and just having one cm3.cfg -- all the paths are computed from the path of cm3/cm3.cfg. Probably defaulting them in the Modula-3 code instead of requiring them be set by Quake would be good, as part of a larger goal of more Modula-3 and less Quake. Quake coudl still override them if necessary. > > > - Jay > > ---------------------------------------- > > From: dragisha at m3w.org > > To: m3devel at elegosoft.com > > Date: Sat, 31 Jan 2009 18:31:39 +0100 > > Subject: [M3devel] make_dir failure > > > > I am trying to build rpm for AMD64_LINUX... I have this situation > > (strace output fragment) > > > > 25802 utimes("/tmp/cm3/usr/local/cm3/pkg/m3core/AMD64_LINUX/libm3core.so", {{1233421816, 0}, {1233421693, 0}}) = 0 > > 25802 stat("/tmp/cm3/usr/local/cm3/bin/../lib64", 0x7fff53109270) = -1 ENOENT (No such file or directory) > > 25802 stat("/tmp/cm3/usr/local/cm3/bin/..", 0x7fff531090d0) = -1 ENOENT (No such file or directory) > > 25802 stat("/tmp/cm3/usr/local/cm3/bin", 0x7fff53108f30) = -1 ENOENT (No such file or directory) > > 25802 stat("/tmp/cm3/usr/local/cm3", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 > > 25802 mkdir("/tmp/cm3/usr/local/cm3/bin", 0777) = 0 > > 25802 mkdir("/tmp/cm3/usr/local/cm3/bin/..", 0777) = -1 EEXIST (File exists) > > 25802 fcntl(2, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) > > 25802 fcntl(2, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0 > > 25802 write(2, "\"/usr/src/redhat/BUILD/cm3/m3-li"..., 312) = 312 > > 25802 fcntl(2, F_SETFL, O_RDWR|O_LARGEFILE) = 0 > > 25802 fcntl(2, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) > > 25802 fcntl(2, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0 > > 25802 write(2, "\n", 1) = 1 > > 25802 fcntl(2, F_SETFL, O_RDWR|O_LARGEFILE) = 0 > > 25802 fcntl(1, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) > > 25802 fcntl(1, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0 > > 25802 write(1, "Fatal Error: package build faile"..., 34) = 34 > > 25802 fcntl(1, F_SETFL, O_RDWR|O_LARGEFILE) = 0 > > 25802 unlink("m3make.args") = 0 > > > > .M3SHIP command in question is: > > > > make_dir("/usr/local/cm3/bin/../lib64") > > > > Looks like path normalization function are a bit... confused? > > -- > > Dragi?a Duri? > > > > -- Dragi?a Duri? From hendrik at topoi.pooq.com Thu Jan 1 11:25:35 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 1 Jan 2009 05:25:35 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <495B4846.1E75.00D7.1@scires.com> References: <20081231105208.9CF4710D5DDE@birch.elegosoft.com> <495B4846.1E75.00D7.1@scires.com> Message-ID: <20090101102535.GB20605@topoi.pooq.com> On Wed, Dec 31, 2008 at 10:28:37AM -0500, Randy Coleburn wrote: > > On another note, All this CYGWIN stuff may be a nice way for die-hard > Unix fans to run Modula-3 on Windows, and I have no objection to > providing it, as long as it does not compromise the native Windows > implementation. It is useful to have a way to take Modula 3 programs from Unix to Windows with minimal change. That said, Modula-3 is a system programming language, and it should be possible to program in a system-dependent way. Do we need two Windows platforms, one native and one to run on a Unix-compatibility layer? And while we're at it, do we need two Unix platforms, one native and one that runs via Wine? > My main concern is the native implementation of > Modula-3 on Windows. My preference would be to keep the NT386 > implementation's dependencies on other stuff to a bare minimum, i.e., > don't introduce anything that would require someone to have to acquire > something besides what comes in the standard Windows OS in order to > make Modula-3 run. As it is now, we already have to get a C compiler > and linker. Fortunately, Microsoft has made the Visual Studio Express > editions a free download, so this is not too bad. Except that the free download won't work on old versions of Windows. This is the main reason why I have been unable in the past to use Modula 3 on Windows. At the moment, though, an overriding reason is that I have no Windows machines available. > I don't want to have to install CYGWIN either in order to make the > native implementation work on Windows. I also still prefer the > CMINSTALL, CMD, or BAT files for install as opposed to having to get > Python or something else. Just my 2 cents. > > Finally, I would go a step further and suggest that the Modula-3 > implementation on every platform should strive to require minimal > dependencies on anything not provided standard with that platform's > operating system. > > Call me an idealist, but it just galls me that I have to have a C > compiler/linker to build Modula-3. Modula-3 is a systems programming > language. It should stand on its own. It is not hard to write a linker in Modula-3. > From a purely economical > viewpoint, why should I have to buy something I don't want (C language > development environment) in order to have the privilege of using what > I do want (Modula-3 language development environment). What's hard is making it compatible with existing proprietary linkers and loaders that are poorly documented and subject to change without notice. > > Regards, > Randy -- hendrik From hendrik at topoi.pooq.com Thu Jan 1 15:20:48 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 1 Jan 2009 09:20:48 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <495B6B87.1E75.00D7.1@scires.com> References: <20081231105208.9CF4710D5DDE@birch.elegosoft.com> <495B4846.1E75.00D7.1@scires.com> <20090101102535.GB20605@topoi.pooq.com> <495B6B87.1E75.00D7.1@scires.com> Message-ID: <20090101142047.GA21146@topoi.pooq.com> On Wed, Dec 31, 2008 at 12:59:03PM -0500, Randy Coleburn wrote: > Hendrik: > > I agree it is useful for those accustomed to Unix to be able to work > in the Cygwin environment on Windows. I have no issue with supporting > this. Yes. But it's not what's really needed for most users of Windows machines. I was using another Unix on Windows system, M-SYS. There's a conceptual gap between M-SYS and Windows (that's the whole point, isn't it?) that brings on headaches. Windows programming should be done in Windows. > I assert that it is also very useful for non-Unix, Windows folks to be > able to work with Modula-3 in Windows without needing to know anything > about Unix, or using any Unix tools to make Modula-3 work. (BTW, I > work in both the Unix and Windows worlds, but primarily in the Windows > world lately.) Yes. Exactly. > > So yes, I suppose we do need both the native Windows and > Unix-compatibility implementations for Modula-3 on Windows. However, > I think it important to support Modula-3 natively on all platforms > rather than *requiring* a compatibility-implementation. Yes. > Thus, I would > always vote for having a native implementation first, then add a > compatibility one later, if desired. So, from my vantage point (and > others may disagree), the native Windows implementation of Modula-3 is > the number one priority on the Windows platform. Cygwin is a > "nice-to-have" for the Unix crowd, but not essential. I was trying to use Modula-3 on Windows in the days that it required a nongratis Microsoft linker, and some nongratis Microsoft linkers were reported not to be compatible. No one could guarantee that any currently available commercial linker was compatible with Modula-3. I wasn't prepared to pay for a system that had significant risk of being useless. > I don't know much about Wine, so won't comment on it. It's the Windows API implemented according to spec. And hacked up so that it is actually somewhat compatible with Windows. It could be useful to test any Windows versions of Modula-3 to see if they run under Wine. In the past quite a few programmers have discovered it's easier to debug Windows programs under Wine than under Windows, because the underlying OS doesn't crash. I don't know whether this is still the case. > > As for taking your Modula-3 programs that run on one platform, and > building and running them on other platforms, I think this is one of > the best features of Modula-3. And this is what I really wanted. > I routinely do this. Indeed, I've > tried very hard to make it possible for all my programs to be both > buildable and runable on both Unix and Windows platforms without the > need for source code modification. I've also tried to make them > interoperable across platforms, e.g. clients on one platform type, > servers on another, etc. Network Objects and Pickles have been my > friends here. > > As for the free Visual Studio stuff not working on old versions of > Windows, well yes that is a problem for those old platforms, but then, > they are old and Microsoft has dropped support for them long ago and > continuing to support them both from a hardware and software > standpoint is going to get more problematic as time goes on. It's > like my 13-year old car--the last time I had it repaired the shop had > to put out a nationwide search for the parts. I too have a 13-year-old car. The dealer used to maintain it. I switched to my local general mechanic when the dealer could no longer find replacement parts. For some reason the local mechanic has no such problem. > At some point, I'll > have to give it up. Me, too. I've been wondering whether the effort of digging it out of the snow every week or so is worth it during the winter. > > I believe you can use some old versions of Microsoft Visual C (e.g., > v6) for these old platforms, but those were not free. I recall having > to buy Microsoft C v6 when I bought CMass Reactor v4.1 many years ago. > The v6 C was pretty common, so you can probably find it around > somewhere today on the used market. Indeed, I still have my v6 C > disks. > > If you or someone else wants to build a linker for Modula-3 on > Windows, that's fine with me. Until then, we are stuck with what we > have--a free download of Visual Studio. > > As for going forward, I believe we should strive to support current > and future platforms more than working to add support for old ones. > Of course, as we move forward, it would be nice to try to maintain > support for platforms as they age, but not at the expense of > supporting newer stuff. I agree, especially since we are talking now about providing a level of support for the old system that was never available in those old days. Anyone with a Windows 95 machine that ran Modula-3 can presumably still use the system he had back then, using the linker he had back then. > This reasoning is based on trying to keep the > language alive, useful, and attractive to new programmers. If we live > in the past, Modula-3 will wither away as the current crop of > enthusiasts age and pass on. I agree. I remember a long time ago tinkering with an OS/2 port of Modula 3. I had the source for the DOS version to start with. I didn't have the time or resources to do anything serious on it though, and someone else did. I wonder what we used for a linker back in those days? > All that said, let me ask this question: Would it be useful to anyone > if I tried to put together a binary distribution of Modula-3 for the > WindowsNT 4.0 (circa 1996) platform? Not for me. Not now. I no longer use Windows. The one machine I have that used to run Windows no longer runs Windows in anything but maintenance mode (though it runs Linux with no trouble at all). What might be useful to me is an ability to cross-compile a Windows executable from a Linux machine, so I could ship the result to a non-programmer Windows user. That would probably require a lot of infrastructure work, and may not be worth it. It may be easier to buy a new Windows machine if I need that. And download the free linker, which I hope still runs on XP as well as Vista. > > I still have one of those old beasts and it does still work. I think I have one in the basement, too. I got it at a garage sale, and have never had occasion to use it. It boots, but I have user or admin password for it it. I am aware of techniques to crack the password, but the machine is probably too slow to be of much use now. -- hendrik From hosking at cs.purdue.edu Thu Jan 1 02:34:09 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 1 Jan 2009 12:34:09 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20081231105208.9CF4710D5DDE@birch.elegosoft.com> <495B4846.1E75.00D7.1@scires.com> <495B901F.1E75.00D7.1@scires.com> Message-ID: <1A450527-2CB6-41CF-982F-DA49C20EA686@cs.purdue.edu> My bandwidth is limited right now so I am unable to follow the discussion closely. But, I am uneasy with some of what I am hearing and would like to have someone provide a succinct summary of the debates. I hope that Randy, Jay, and Mika can perhaps do this. From hosking at cs.purdue.edu Thu Jan 1 02:29:24 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 1 Jan 2009 12:29:24 +1100 Subject: [M3devel] variations of waitpid..? In-Reply-To: References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> Message-ID: If someone uses waitpid they get what they paid for. On 1 Jan 2009, at 06:24, Jay wrote: > > You mean, this function is easy to misuse? >> People who declare their own <*EXTERNAL*> > Like waitpid exposed from m3core? > > waitpid is already easy to misuse, on a userthread system, leading > to possible (though I think rare) deadlock. > It is easy to misuse on pthreads, lead "just" to bad performance, > and in fact I believe cm3 is doing this, via sysutils. > This at least guides you between two patterns of use, and fix the > perf of cm3/sysutils. > > On a userthread system, waitpid(pid, flags = 0) waits for the child > process, with all parent threads suspended. > Generally I doubt the child depends on parent threads progressing, > but, yeah, that could deadlock, like if a parent thread is waiting > to a file or stdin of the child, or reading a child's stdout. > > The various uses do waitpid(pid, flags = nohang) and then sleep and > try again. > > pthreads just uses waitpid(pid, flags = 0) and all threads keep > running From jay.krell at cornell.edu Thu Jan 1 02:49:28 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 1 Jan 2009 01:49:28 +0000 Subject: [M3devel] variations of waitpid..? In-Reply-To: References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> Message-ID: > If someone uses waitpid they get what they paid for. But someone is us -- m3core/libm3 (I think just m3core), sysutils, and then cm3 uses them. I guess there is a point that this "grand new interface" SchedulerPosix.DoesWaitPidYield has precious few users. (It isn't grand. It takes no parameters and just returns a boolean, hardcoded, depending on thread library.) m3core now (today) uses it internally -- no need for a public interface. Sysutils can't use it until the baseline m3core is newer, so arguably, not a user. Instead (today) sysutils uses m3core's m3makefiles to decide the value. Heck, waitpid is therefore only used internally by m3core, and sysutils. If sysutils could be (partly) merged into m3core, then m3core's waitpid need not be public. - Jay> CC: mika> From: hosking> To: jay> Subject: Re: [M3devel] variations of waitpid..?> Date: Thu, 1 Jan 2009 12:29:24 +1100> > If someone uses waitpid they get what they paid for. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 1 02:59:50 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 1 Jan 2009 01:59:50 +0000 Subject: [M3devel] FW: variations of waitpid..? In-Reply-To: References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> Message-ID: [truncated just slightly..and probably will be again given more rambling..] ps: the internal use in m3core could be easily removed, just by compiling one branch of the if or the other. I just wanted them in the same file to keep similar code closer together. So it comes down that m3core does expose Uwaitpid.waitpid and Uexec.waitpid, and as long as they are...or as long as user threads exist..imho there is some obligation of m3core to expose perhaps surprising characteristics of its thread library. You might say the entire interface is already and has always been fully exposed in Thread.i3, but I don't believe it. User threads and kernel threads have too divergent too visible artifacts, that I don't think are previously exposed in the public interface. I claim it is somewhat "surprising", or at least important to know the detail of, whether or not waitpid yields to other threads. You know, I mean..let's say I am some really clever waitpid user and I really must use it. And I am using Modula-3 threads. And my child process is reading the output of Modula-3 threads. Aren't I kind of stuck? Isn't there /some/ obligation of m3core to help just a teeny tiny bit? Or, would you argue, I am obligated, if I am using Modula-3, to use the higher level interfaces, that already know about this? Well, ok, m3core did already know about, I fixed it only a few months ago, but then even the likes of sysutils is stuck? Another example, that may or may not be well exposed, is willingness/ability to set thread stack size. Mika mentions creation thousands of threads. 32bit kernel threads are going to be more limited here. Whereas 32bit user threads might be willing to create much smaller stacks, and 64 bit anything has essentially infinite address space for infinite stacks (but still beware working set, physical memory is not infinite). (Personally I have seen precious little code that cares about stack size, just seems to somehow get along, combined with the fact that the current Modula-3 pthread code very likely leaks on some platforms attempting to deal with stack size, makes me inclined to just rip out the code..but yeah..just fix the leak...) - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: mika at async.caltech.edu; m3devel at elegosoft.comSubject: RE: [M3devel] variations of waitpid..?Date: Thu, 1 Jan 2009 01:49:28 +0000 > If someone uses waitpid they get what they paid for. But someone is us -- m3core/libm3 (I think just m3core), sysutils, and then cm3 uses them. I guess there is a point that this "grand new interface" SchedulerPosix.DoesWaitPidYield has precious few users. (It isn't grand. It takes no parameters and just returns a boolean, hardcoded, depending on thread library.) m3core now (today) uses it internally -- no need for a public interface.Sysutils can't use it until the baseline m3core is newer, so arguably, not a user. Instead (today) sysutils uses m3core's m3makefiles to decide the value. Heck, waitpid is therefore only used internally by m3core, and sysutils.If sysutils could be (partly) merged into m3core, then m3core's waitpid need not be public. - Jay> CC: mika> From: hosking> To: jay> Subject: Re: [M3devel] variations of waitpid..?> Date: Thu, 1 Jan 2009 12:29:24 +1100> > If someone uses waitpid they get what they paid for. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.illig at gmx.de Thu Jan 1 05:18:47 2009 From: roland.illig at gmx.de (Roland Illig) Date: Thu, 01 Jan 2009 05:18:47 +0100 Subject: [M3devel] Is Modula-3 available on x86_64-unknown-linux-gnu? In-Reply-To: References: <495B4A7B.6010505@gmx.de> Message-ID: <495C4427.4090106@gmx.de> Jay schrieb: > In your config file, make sure to put -m32 on the cm3cg invocation, and > perhaps -32 or --32 on the as/gas invocation. They may or may not help. Thanks for the suggestion. I tried it (SYSTEM_CC="gcc -m32", SYSTEM_ASM="as --32"), and the program builds fine now. When running it, I get the following: Program received signal SIGSEGV, Segmentation fault. 0xdc1ca000 in ?? () (gdb) where #0 0xdc1ca000 in ?? () #1 0xf75dee30 in RTThread__FlushStackCache () at RTThread.m3:65 #2 0xf75e49ce in ThreadPosix__DetermineContext (M3_AJWxb1_oldSP=0xffb59250) at ThreadPosix.m3:1101 #3 0xf75e4932 in ThreadPosix__InitTopContext (M3_A8sSUp_c=0xf73b203c, M3_AJWxb1_stackbase=0xffb5935c) at ThreadPosix.m3:1076 #4 0xf75e5fe5 in ThreadF__Init () at ThreadPosix.m3:1498 #5 0xf75cdfcd in RTLinker__InitRuntime (M3_AcxOUs_p_argc=1, M3_AJWxb1_p_argv=0xffb59424, M3_AJWxb1_p_envp=0xffb5942c, M3_AJWxb1_p_instance=0x0) at RTLinker.m3:59 #6 0x08048901 in main (argc=1, argv=0xffb59424, envp=0xffb5942c) at _m3main.mc:3 The address 0xdc1ca000 does not appear in /proc/self/maps, so I don't know where to look further. Roland From jay.krell at cornell.edu Thu Jan 1 09:51:00 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 1 Jan 2009 08:51:00 +0000 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: <20081230021646.GA8558@jack.stsp.name> References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> Message-ID: Stefan, Please try http://modula3.elegosoft.com/cm3/uploaded-archives/. There are std and min archives there now. I haven't yet run X or tests, but the system is self hosting -- it builds itself. Let us know how it goes. Thanks, - Jay > Date: Tue, 30 Dec 2008 03:16:46 +0100> From: stefan> To: jay> CC: m3devel> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > On Mon, Dec 29, 2008 at 09:33:44PM +0000, Jay Krell wrote:> > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 08/12/29 21:33:44> > Hey Jay,> > > Log message:> > enough I386_OPENBSD support to build a bootstrap package,> > that builds on the target, and results in a cm3 that> > runs and correct errors out for lack of cm3.cfg,> > Cool, I'd like to play with this, once you have a bootstrap binary.> > Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 1 09:57:45 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 1 Jan 2009 08:57:45 +0000 Subject: [M3devel] Is Modula-3 available on x86_64-unknown-linux-gnu? In-Reply-To: <495C4427.4090106@gmx.de> References: <495B4A7B.6010505@gmx.de> <495C4427.4090106@gmx.de> Message-ID: Roland, You are using user threads. I can tell from the functions on the stack. >From what I read on this list, I gather user threads are broken on Linux due to "jumpbuf scrambling". (besides the problem I reported, which isn't in very old builds) Can you please try a newer build? ie: one that uses pthreads? > SYSTEM_CC="gcc -m32", I forgot to mention that one but yeah. :) You are using a very old build, right? - Jay> Date: Thu, 1 Jan 2009 05:18:47 +0100> From: roland> To: m3devel> Subject: Re: [M3devel] Is Modula-3 available on x86_64-unknown-linux-gnu?> > Jay schrieb:> > In your config file, make sure to put -m32 on the cm3cg invocation, and> > perhaps -32 or --32 on the as/gas invocation. They may or may not help.> > Thanks for the suggestion. I tried it (SYSTEM_CC="gcc -m32",> SYSTEM_ASM="as --32"), and the program builds fine now. When running it,> I get the following:> > Program received signal SIGSEGV, Segmentation fault.> 0xdc1ca000 in ?? ()> (gdb) where> #0 0xdc1ca000 in ?? ()> #1 0xf75dee30 in RTThread__FlushStackCache () at RTThread.m3:65> #2 0xf75e49ce in ThreadPosix__DetermineContext> (M3_AJWxb1_oldSP=0xffb59250) at ThreadPosix.m3:1101> #3 0xf75e4932 in ThreadPosix__InitTopContext (M3_A8sSUp_c=0xf73b203c,> M3_AJWxb1_stackbase=0xffb5935c) at ThreadPosix.m3:1076> #4 0xf75e5fe5 in ThreadF__Init () at ThreadPosix.m3:1498> #5 0xf75cdfcd in RTLinker__InitRuntime (M3_AcxOUs_p_argc=1,> M3_AJWxb1_p_argv=0xffb59424, M3_AJWxb1_p_envp=0xffb5942c,> M3_AJWxb1_p_instance=0x0) at RTLinker.m3:59> #6 0x08048901 in main (argc=1, argv=0xffb59424, envp=0xffb5942c)> at _m3main.mc:3> > The address 0xdc1ca000 does not appear in /proc/self/maps, so I don't> know where to look further.> > Roland -------------- next part -------------- An HTML attachment was scrubbed... URL: From stsp at elego.de Thu Jan 1 12:41:39 2009 From: stsp at elego.de (Stefan Sperling) Date: Thu, 1 Jan 2009 12:41:39 +0100 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> Message-ID: <20090101114139.GC10003@jack.stsp.name> On Thu, Jan 01, 2009 at 08:51:00AM +0000, Jay wrote: > > Stefan, Please try > [1]http://modula3.elegosoft.com/cm3/uploaded-archives/. > There are std and min archives there now. > I haven't yet run X or tests, but the system is self hosting -- it > builds itself. > Let us know how it goes. Where are the bootstrap binaries? Stefan From roland.illig at gmx.de Thu Jan 1 13:19:36 2009 From: roland.illig at gmx.de (Roland Illig) Date: Thu, 01 Jan 2009 13:19:36 +0100 Subject: [M3devel] Is Modula-3 available on x86_64-unknown-linux-gnu? In-Reply-To: References: <495B4A7B.6010505@gmx.de> <495C4427.4090106@gmx.de> Message-ID: <495CB4D8.5050400@gmx.de> Jay schrieb: > Can you please try a newer build? > ie: one that uses pthreads? I first used cm3-5.4.0, which had the problems you mentioned with the user threads. Then I tried cm3-5.5.0, which always produces an internal compiler error (Segmentation Fault) in cm3cg, which unfortunately has all debugging symbols stripped: $ /home/roland/usr.local/packages/cm3-5.5.0/bin/cm3 --- building in LINUXLIBC6 --- new source -> compiling Hello.m3 Hello.m3: In function 'Hello_M3': Hello.m3:25: internal compiler error: Segmentation fault At last I tried today's daily snapshot (5.7.0-2009-01-01-03). I was confused about the installer, which isn't interactive anymore. And if I run "./cminstall --help" or "./cminstall -?", like probably every Unix user would do, I don't even get a useful error message. Most programs print a single line that looks like: usage: ./cminstall [-verbose] [-interactive] directory That message would have been very helpful. Finally I got around this usability issue, and managed to install it. Since the installation was completely non-interactive, I edited the cm3.cfg file manually. I set SYSTEM_CC="/usr/bin/gcc -m32" and SYSTEM_AS="/usr/bin/as --32", and changed all "-L/usr/lib" into "-L/usr/lib32". Then I tried to build the hello world program, and this is what I got: $ /home/roland/usr.local/packages/cm3-5.7.0.2009.01.01/bin/cm3 --- building in LINUXLIBC6 --- new source -> compiling Hello.m3 -> linking hello $ ./LINUXLIBC6/hello Hello World! Yippieeeeh. Roland From jay.krell at cornell.edu Thu Jan 1 20:45:44 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 1 Jan 2009 19:45:44 +0000 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: <20090101114139.GC10003@jack.stsp.name> References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> <20090101114139.GC10003@jack.stsp.name> Message-ID: What do you mean by "bootstrap binaries"? There are a variety of ways to get a usable system. There is http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-I386_OPENBSD-1.tar.gz extract it (tar zxf ...) cd into it (cd ...) add -lm and -lpthread to the link line make mkdir -p /usr/local/cm3/bin mv cm3 /usr/local/cm3/bin export PATH=$PATH:/usr/local/cm3/bin export CM3_ROOT=/usr/src/cm3 or whatever export CVSROOT=:ext:stefan at m3.elegosoft.com:/usr/cvs cvs -z3 checkout cm3 cd /usr/src/scripts/python ./do-cm3-front.py buildship OR get http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-I386_OPENBSD-d5.7.0.tar.lzma cd /usr/local rm -rf cm3 lzcat cm3-min-I386_OPENBSD-d5.7.0.tar.lzma | tar xf - mv cm3-min-I386_OPENBSD-d5.7.0 cm3 or get the much larger .tar.gz file and usr zcat instead of lzcat get the source cd /usr/src/scripts/python ./do-cm3-all.py realclean && ./upgrade.py && ./do-cm3-std.py buildshipd OR get http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-I386_OPENBSD-d5.7.0.tar.lzma and not much need to build anything, but a good test to see if it is working, can follow the same instructions as for "min", it will rebuild stuff you already have. OR go to some other system, and cd $CVSROOT/m3-sys/m3cc cm3 -DM3CC_TARGET=I386_OPENBSD cd $CVSROOT/scripts/python NOTE you'll either have loosen file system privileges or /slightly/ change the code. For easy of finding it, I put the output at the root of my drive/volume/namespace. I should probably change that to be in /tmp. ./boot1.py I386_OPENBSD This gives you /cm3-boot-I386_OPENBSD-1.tar.gz (and /cm3-boot-I386_OPENBSD-1, but again, I should move these to "temp"), which you ftp or rcp or scp or whatever to the I386_OPENBSD machine and pick up at the first set of steps -- that's how I get new platforms working, though sometimes you can cheat on "biarch" systems, e.g. you can bring up AMD64_LINUX via LINUXLIBC6, just on one machine, no need to copy across machines and can skip the "boot" process and build more in one step, AMD64_FREEBSD via FreeBSD4, etc..)) - Jay> Date: Thu, 1 Jan 2009 12:41:39 +0100> From: stsp at elego.de> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: I386_OPENBSD uploaded-archives> > On Thu, Jan 01, 2009 at 08:51:00AM +0000, Jay wrote:> > > > Stefan, Please try> > [1]http://modula3.elegosoft.com/cm3/uploaded-archives/.> > There are std and min archives there now.> > I haven't yet run X or tests, but the system is self hosting -- it> > builds itself.> > Let us know how it goes.> > Where are the bootstrap binaries?> > Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 1 21:04:36 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 1 Jan 2009 20:04:36 +0000 Subject: [M3devel] Is Modula-3 available on x86_64-unknown-linux-gnu? In-Reply-To: <495CB4D8.5050400@gmx.de> References: <495B4A7B.6010505@gmx.de> <495C4427.4090106@gmx.de> <495CB4D8.5050400@gmx.de> Message-ID: /usr/lib32, good point, we can/should handle that automatically. If word size 32bits and /usr/lib32 exists, use it instead of /usr/lib. Similarly for /usr/lib64. etc. When I get back I'll fiddle with m3-sys/cminstall/src/config-no-install. I never use cminstall. I suggest http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-LINUXLIBC6-d5.7.0.tar.bz2 or http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-LINUXLIBC6-d5.7.0.tar.bz2 though I guess they need a readme. They would admittedly probably have the same problem but I can fix that easily. (-m32/--32 maybe not, but /usr/lib vs. /usr/lib32 probably.) You might also try the native: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-AMD64_LINUX-d5.7.0.tar.gz or http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-AMD64_LINUX-d5.7.0.tar.gz "min" contains only the compiler and m3core and libm3. "std" contains "everything" -- everything that currently builds successfully. - Jay> Date: Thu, 1 Jan 2009 13:19:36 +0100> From: roland.illig at gmx.de> To: m3devel at elegosoft.com> Subject: Re: [M3devel] Is Modula-3 available on x86_64-unknown-linux-gnu?> > Jay schrieb:> > Can you please try a newer build?> > ie: one that uses pthreads?> > I first used cm3-5.4.0, which had the problems you mentioned with the> user threads.> > Then I tried cm3-5.5.0, which always produces an internal compiler error> (Segmentation Fault) in cm3cg, which unfortunately has all debugging> symbols stripped:> > $ /home/roland/usr.local/packages/cm3-5.5.0/bin/cm3> --- building in LINUXLIBC6 ---> > new source -> compiling Hello.m3> Hello.m3: In function 'Hello_M3':> Hello.m3:25: internal compiler error: Segmentation fault> > At last I tried today's daily snapshot (5.7.0-2009-01-01-03). I was> confused about the installer, which isn't interactive anymore. And if I> run "./cminstall --help" or "./cminstall -?", like probably every Unix> user would do, I don't even get a useful error message. Most programs> print a single line that looks like:> > usage: ./cminstall [-verbose] [-interactive] directory> > That message would have been very helpful. Finally I got around this> usability issue, and managed to install it. Since the installation was> completely non-interactive, I edited the cm3.cfg file manually. I set> SYSTEM_CC="/usr/bin/gcc -m32" and SYSTEM_AS="/usr/bin/as --32", and> changed all "-L/usr/lib" into "-L/usr/lib32". Then I tried to build the> hello world program, and this is what I got:> > $ /home/roland/usr.local/packages/cm3-5.7.0.2009.01.01/bin/cm3> --- building in LINUXLIBC6 ---> > new source -> compiling Hello.m3> -> linking hello> $ ./LINUXLIBC6/hello> Hello World!> > Yippieeeeh.> > Roland -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.illig at gmx.de Thu Jan 1 21:10:09 2009 From: roland.illig at gmx.de (Roland Illig) Date: Thu, 01 Jan 2009 21:10:09 +0100 Subject: [M3devel] Is Modula-3 available on x86_64-unknown-linux-gnu? In-Reply-To: References: <495B4A7B.6010505@gmx.de> <495C4427.4090106@gmx.de> <495CB4D8.5050400@gmx.de> Message-ID: <495D2321.1040205@gmx.de> Jay schrieb: > http://modula3.elegosoft.com/cm3/uploaded-archives/ That's nice. I didn't know about this directory before. Roland From rodney.bates at wichita.edu Thu Jan 1 20:02:17 2009 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 01 Jan 2009 13:02:17 -0600 Subject: [M3devel] TEXT & etc. In-Reply-To: <200812310822.mBV8Mf2j027994@camembert.async.caltech.edu> References: <200812310822.mBV8Mf2j027994@camembert.async.caltech.edu> Message-ID: <495D1339.2070703@wichita.edu> I started working on a more elaborate package of performance improvements to TEXT operations. They are algorithm-only (no changes to declarations or invariants of data structure), thus no effect on pickles, stubs, etc., as is your change. I am flattening concatenations only when the result has finite bounded length, keeping Text.Cat O(1), although with considerably larger constant factor. I am also doing two-level rebalancing of trees, also O(1). Without knowing depths (which would require either an O(log N) algorithm to compute then or caching them, requiring data structure changes), I am using lengths as a crude estimate of depth. Meanwhile I am recoding get_chars/get_wide_chars to recurse on only the shorter side and iterate on the other. This, in combination with better balance, should cut down greatly on stack depth and execution time. I am also avoiding cases where a number of other operations in the current implementation unnecessarily convert concatenations containing only 8-bit representations to 16, which requires a character-by-character loop to expand them. I also have found a couple of bugs. Hopefully, these will help. Mika Nystrom wrote: > Hello everyone, > > I mentioned a week or two ago that I had run into horrific performance > issues with CM3's TEXTs. It wasn't my intention to start a debate > about Unicode and Mahjong characters, just to point out that there's > a serious performance problem with CM3 in this area. I run into > performance problems with CM3 from time to time because I am trying > to maintain a fairly large amount of software written in Modula-3 > and it appears to me that the SRC/PM3 compilers often pay better > attention to performance issues than the newer CM3 compiler. > Generally speaking I think Modula-3 needs to avoid getting into the > Java situation: Java is squeezed between "fast enough" Python and > "much more efficient" C++... Modula-3 I see as the only hope for > getting the performance of C++ with the safety of Java. The problems > I have seen with CM3 are in the following areas: > > 1. Thread mutex acquisition involving kernel calls (pthreads > implementation) > > 2. ISTYPE and TYPECASE (appear much faster on PM3, don't know why, > could just be a profiling issue). In any case TYPECASE is very slow > because of having to search the type tree. This could be improved > but I can't work on it because I always run into some kind of fatal > problem trying to bootstrap the compiler. > > 3. The TEXT issue. I mentioned performance problems before. It turns > out that it was showing up in another area. I upgraded my PowerBook > a while back (to OS X 10.4) and of course everything stopped working, > including at least half my Modula-3 programs. I thought it was a > versioning problem with C libraries I was importing, but it turned out > that in at least one case I was running out of stack space because of > the calls to get_char on concatenated TEXTs. (Not very long ones, > at that.) > > To get to the point. What follows is my new version of TextCat.m3, > which I believe works, but I can't really say because I'm perennially > incapable of bootstrapping CM3. The basic idea is that you can > have *one* TextCat.T, at the "root" of your TEXT. It will flatten > anything else. > > I don't see a simple way of modifying the CM3 TEXT implementation to > do much better than this. Of course throwing out TextCat.T completely > is an option. > > An advantage of what I've done is that I haven't changed any interfaces > at all. So I don't get problems with version stamps, etc. > > Mika > > From martinbishop at bellsouth.net Fri Jan 2 04:53:29 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Thu, 01 Jan 2009 21:53:29 -0600 Subject: [M3devel] Modula-3 auto keyword upcase Message-ID: <495D8FB9.6030800@bellsouth.net> I use the Modula-3 elisp code for Emacs to edit Modula-3 source, but it's somewhat annoying having to hit TAB to complete keywords (otherwise I have to hold shift to type them out). I have used an Oberon mode for Emacs before, that would auto upcase the keywords. If you typed 'module' and then pressed space, it would become 'MODULE', etc. I tried to modify the code from the Oberon mode and add it to the Modula-3 mode, but I had no luck. Does anyone know of any Modula-3 elisp code that does this? Or is there another editor that is capable of this? I have NEdit and jEdit, both have Modula-3 highlighting support, but neither help in actually editing Modula-3 code. From jay.krell at cornell.edu Fri Jan 2 08:02:34 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 2 Jan 2009 07:02:34 +0000 Subject: [M3devel] meaning of unsafe? Message-ID: Recent quote, that I haven't further investigated, made me realize some of my ignorance. I know that "unsafe" includes: taking address of local explicit free dealing with any untraced ref? Not sure. Questions are: is unsafe well statically enforced? and/or is safe well statically enforced? That is, should I remove unsafe "everywhere", as long as it compiles ok, it must be safe, and better, so leave it that way? And if it fails, put it back? Or do I need to think about it myself? I think for modules it might be brainless as stated -- put it in only where the compiler makes, and nowhere extra, since extra is a loss not a bonus. But for interfaces.. I think, again, ideal to remove it where you can, but that the compiler can't enforce it? At least where there is "external"? Maybe I should just reread that quote, and thing about it. Safe can code call unsafe code, but should not be able to do so with parameters that, indirectly, make the safe code unsafe. For example, I cannot safe call "free" in unsafe code on behalf of safe code, unless I am darn sure the data isn't referenced -- unless I am the garbage collector. Any pointer give to unsafe code by safe code must not be stored "long term" -- ie: in the heap or globals, because it could be a stack pointer. Unless, well, duh..ok, any VAR parameter or UNTRACED REF passed to unsafe code, what I just said, but traced refs can be held onto -- they are by definition not stack pointers. I guess, you know..programming C code that interacts with Modula-3 code..you realize the incompleteness of the C type system. Modula-3 has, let's say, var, traced ref, and untraced ref. C just has pointers. The compiler doesn't know any better, the programmer has to. If you imagine a Modula-3 to C header compiler..which I would like..you know, it outputs C headers that map FROM Modula-3 interfaces (instead of the usual hand translations in either direction), it would likely lose a lot of information and only be for special purpose use, unless, unlikely, not likely valuable, this problem was solved. Which..oh, this is interesting..I can see, to solve this, you'd need an "API" for storing pointers perhaps. Something perhaps to make sure the pointer is allowed to be stored like such. Not sure. But I suspect this "API" is related to the "checks" that the Modula-3 compiler generates...I really need to understand those... Generally this is easy, because generally things are "synchronous" -- generally the C code doesn't hold on to its parameters beyond the lifetime of itself -- doesn't store it in the heap or globally for other threads to use, and generally the Modula-3 code isn't busy freeing the parameters on another thread, in fact VAR parameters cannot be freed, they are on the stack, and traced refs can only be freed..if the garbage collector can't find any references to them..and then untraced refs require "discipline" both in the Modula-3 code and the C code, but again generally, saved by "synchronicity" -- C code doesn't hold on to them, Modula-3 code doesn't free them on another thread. Those scenarios are certainly possible, just not all that common, and as soon as you "escape" to safe Modula-3 code, not a possibility..no untraced refs.. About right? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Fri Jan 2 08:27:24 2009 From: darko at darko.org (Darko) Date: Fri, 2 Jan 2009 16:27:24 +0900 Subject: [M3devel] meaning of unsafe? In-Reply-To: References: Message-ID: <12ACA122-57EC-4AA1-A250-9E22B71AC2DD@darko.org> Safety is a property of the language, not the procedures. A safe module is one that doesn't use unsafe features and means the language will guarantee that you will get no unchecked errors when you run the code. And that guarantee is dependent on the compiler and language definition being bug free. Outside that of that it is like asking if rocks feel guilty. External modules are not written in M3 so they have no possibility of safety in the M3 sense, unless they were written in a language with an equivalent definition to M3. They might be reliable or bug free, but that's not the same thing. On 02/01/2009, at 4:02 PM, Jay wrote: > Recent quote, that I haven't further investigated, made me realize > some of my ignorance. > > I know that "unsafe" includes: > taking address of local > explicit free > dealing with any untraced ref? Not sure. > > Questions are: > is unsafe well statically enforced? > and/or is safe well statically enforced? > > That is, should I remove unsafe "everywhere", as long as it compiles > ok, it must be safe, and better, so leave it that way? And if it > fails, put it back? > > Or do I need to think about it myself? > > I think for modules it might be brainless as stated -- put it in > only where the compiler makes, and nowhere extra, since extra is a > loss not a bonus. > > But for interfaces.. I think, again, ideal to remove it where you > can, but that the compiler can't enforce it? At least where there is > "external"? > Maybe I should just reread that quote, and thing about it. > > Safe can code call unsafe code, but should not be able to do so with > parameters that, indirectly, make the safe code unsafe. For example, > I cannot safe call "free" in unsafe code on behalf of safe code, > unless I am darn sure the data isn't referenced -- unless I am the > garbage collector. Any pointer give to unsafe code by safe code must > not be stored "long term" -- ie: in the heap or globals, because it > could be a stack pointer. Unless, well, duh..ok, any VAR parameter > or UNTRACED REF passed to unsafe code, what I just said, but traced > refs can be held onto -- they are by definition not stack pointers. > > I guess, you know..programming C code that interacts with Modula-3 > code..you realize the incompleteness of the C type system. Modula-3 > has, let's say, var, traced ref, and untraced ref. C just has > pointers. The compiler doesn't know any better, the programmer has to. > > If you imagine a Modula-3 to C header compiler..which I would > like..you know, it outputs C headers that map FROM Modula-3 > interfaces (instead of the usual hand translations in either > direction), it would likely lose a lot of information and only be > for special purpose use, unless, unlikely, not likely valuable, this > problem was solved. > Which..oh, this is interesting..I can see, to solve this, you'd need > an "API" for storing pointers perhaps. Something perhaps to make > sure the pointer is allowed to be stored like such. Not sure. But I > suspect this "API" is related to the "checks" that the Modula-3 > compiler generates...I really need to understand those... > > > Generally this is easy, because generally things are "synchronous" > -- generally the C code doesn't hold on to its parameters beyond the > lifetime of itself -- doesn't store it in the heap or globally for > other threads to use, and generally the Modula-3 code isn't busy > freeing the parameters on another thread, in fact VAR parameters > cannot be freed, they are on the stack, and traced refs can only be > freed..if the garbage collector can't find any references to > them..and then untraced refs require "discipline" both in the > Modula-3 code and the C code, but again generally, saved by > "synchronicity" -- C code doesn't hold on to them, Modula-3 code > doesn't free them on another thread. Those scenarios are certainly > possible, just not all that common, and as soon as you "escape" to > safe Modula-3 code, not a possibility..no untraced refs.. > > > About right? > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jan 2 09:16:18 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 2 Jan 2009 08:16:18 +0000 Subject: [M3devel] meaning of unsafe? In-Reply-To: <12ACA122-57EC-4AA1-A250-9E22B71AC2DD@darko.org> References: <12ACA122-57EC-4AA1-A250-9E22B71AC2DD@darko.org> Message-ID: The language offers optional safety, therefore safety has a meaning "among" modules and interfaces. (heck, it might be interesting to have safe/unsafe functions, or even blocks of code -- C# has safe/unsafe blocks of code, like unsafe { do stuff }) What is the meaning of an unsafe interface vs. a safe interface? I see one thing -- an unsafe module cannot import from a safe interface. I tried that. I think you or Mika summed it up -- safe code can call into unsafe code, but doing so must not violate "the usual safety" constraints". Therefore, unsafe code must be "careful", i.e. bug-free (well, not logically bug-free, but type-system bug-free -- no use of freed pointers (nor dangling stack pointers, nor invalid addresses in general), no double frees, no buffer overflows (or underflows), no integer overflows, etc., and don't call into any such code either). - Jay From: darko at darko.orgTo: jay.krell at cornell.eduDate: Fri, 2 Jan 2009 16:27:24 +0900CC: m3devel at elegosoft.comSubject: Re: [M3devel] meaning of unsafe? Safety is a property of the language, not the procedures. A safe module is one that doesn't use unsafe features and means the language will guarantee that you will get no unchecked errors when you run the code. And that guarantee is dependent on the compiler and language definition being bug free. Outside that of that it is like asking if rocks feel guilty. External modules are not written in M3 so they have no possibility of safety in the M3 sense, unless they were written in a language with an equivalent definition to M3. They might be reliable or bug free, but that's not the same thing. On 02/01/2009, at 4:02 PM, Jay wrote: Recent quote, that I haven't further investigated, made me realize some of my ignorance. I know that "unsafe" includes: taking address of local explicit free dealing with any untraced ref? Not sure. Questions are: is unsafe well statically enforced? and/or is safe well statically enforced? That is, should I remove unsafe "everywhere", as long as it compiles ok, it must be safe, and better, so leave it that way? And if it fails, put it back? Or do I need to think about it myself? I think for modules it might be brainless as stated -- put it in only where the compiler makes, and nowhere extra, since extra is a loss not a bonus. But for interfaces.. I think, again, ideal to remove it where you can, but that the compiler can't enforce it? At least where there is "external"?Maybe I should just reread that quote, and thing about it. Safe can code call unsafe code, but should not be able to do so with parameters that, indirectly, make the safe code unsafe. For example, I cannot safe call "free" in unsafe code on behalf of safe code, unless I am darn sure the data isn't referenced -- unless I am the garbage collector. Any pointer give to unsafe code by safe code must not be stored "long term" -- ie: in the heap or globals, because it could be a stack pointer. Unless, well, duh..ok, any VAR parameter or UNTRACED REF passed to unsafe code, what I just said, but traced refs can be held onto -- they are by definition not stack pointers. I guess, you know..programming C code that interacts with Modula-3 code..you realize the incompleteness of the C type system. Modula-3 has, let's say, var, traced ref, and untraced ref. C just has pointers. The compiler doesn't know any better, the programmer has to. If you imagine a Modula-3 to C header compiler..which I would like..you know, it outputs C headers that map FROM Modula-3 interfaces (instead of the usual hand translations in either direction), it would likely lose a lot of information and only be for special purpose use, unless, unlikely, not likely valuable, this problem was solved. Which..oh, this is interesting..I can see, to solve this, you'd need an "API" for storing pointers perhaps. Something perhaps to make sure the pointer is allowed to be stored like such. Not sure. But I suspect this "API" is related to the "checks" that the Modula-3 compiler generates...I really need to understand those... Generally this is easy, because generally things are "synchronous" -- generally the C code doesn't hold on to its parameters beyond the lifetime of itself -- doesn't store it in the heap or globally for other threads to use, and generally the Modula-3 code isn't busy freeing the parameters on another thread, in fact VAR parameters cannot be freed, they are on the stack, and traced refs can only be freed..if the garbage collector can't find any references to them..and then untraced refs require "discipline" both in the Modula-3 code and the C code, but again generally, saved by "synchronicity" -- C code doesn't hold on to them, Modula-3 code doesn't free them on another thread. Those scenarios are certainly possible, just not all that common, and as soon as you "escape" to safe Modula-3 code, not a possibility..no untraced refs.. About right? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Fri Jan 2 09:24:28 2009 From: darko at darko.org (Darko) Date: Fri, 2 Jan 2009 17:24:28 +0900 Subject: [M3devel] meaning of unsafe? In-Reply-To: References: <12ACA122-57EC-4AA1-A250-9E22B71AC2DD@darko.org> Message-ID: <408EB16D-82D8-47DF-A036-10AA25CC5C69@darko.org> The language def says: In unsafe interfaces and modules the definition of "assignable" for types is extended: two reference types T and U are assignable if T <: U or U <: T. The only effect of this change is to allow a value of type ADDRESS to be assigned to a variable of type UNTRACED REF T. It is an unchecked runtime error if the value does not address a variable of type T. In unsafe interfaces and modules the type constructor UNTRACED REF T is allowed for traced as well as untraced T, and the fields of untraced objects can be traced. If u is an untraced reference to a traced variable t, then the validity of the traced references in t is implementation-dependent, since the garbage collector probably will not trace them through u. On 02/01/2009, at 5:16 PM, Jay wrote: > The language offers optional safety, therefore safety has a meaning > "among" modules and interfaces. > (heck, it might be interesting to have safe/unsafe functions, or > even blocks of code -- C# has safe/unsafe blocks of code, like > unsafe { do stuff }) > > What is the meaning of an unsafe interface vs. a safe interface? > > I see one thing -- an unsafe module cannot import from a safe > interface. > I tried that. > > I think you or Mika summed it up -- safe code can call into unsafe > code, but doing so must not violate "the usual safety" constraints". > Therefore, unsafe code must be "careful", i.e. bug-free (well, not > logically bug-free, but type-system bug-free -- no use of freed > pointers (nor dangling stack pointers, nor invalid addresses in > general), no double frees, no buffer overflows (or underflows), no > integer overflows, etc., and don't call into any such code either). > > - Jay > > > > From: darko at darko.org > To: jay.krell at cornell.edu > Date: Fri, 2 Jan 2009 16:27:24 +0900 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] meaning of unsafe? > > > Safety is a property of the language, not the procedures. A safe > module is one that doesn't use unsafe features and means the > language will guarantee that you will get no unchecked errors when > you run the code. And that guarantee is dependent on the compiler > and language definition being bug free. > > Outside that of that it is like asking if rocks feel guilty. > External modules are not written in M3 so they have no possibility > of safety in the M3 sense, unless they were written in a language > with an equivalent definition to M3. They might be reliable or bug > free, but that's not the same thing. > > > On 02/01/2009, at 4:02 PM, Jay wrote: > > Recent quote, that I haven't further investigated, made me realize > some of my ignorance. > > I know that "unsafe" includes: > taking address of local > explicit free > dealing with any untraced ref? Not sure. > > Questions are: > is unsafe well statically enforced? > and/or is safe well statically enforced? > > That is, should I remove unsafe "everywhere", as long as it compiles > ok, it must be safe, and better, so leave it that way? And if it > fails, put it back? > > Or do I need to think about it myself? > > I think for modules it might be brainless as stated -- put it in > only where the compiler makes, and nowhere extra, since extra is a > loss not a bonus. > > But for interfaces.. I think, again, ideal to remove it where you > can, but that the compiler can't enforce it? At least where there is > "external"? > Maybe I should just reread that quote, and thing about it. > > Safe can code call unsafe code, but should not be able to do so with > parameters that, indirectly, make the safe code unsafe. For example, > I cannot safe call "free" in unsafe code on behalf of safe code, > unless I am darn sure the data isn't referenced -- unless I am the > garbage collector. Any pointer give to unsafe code by safe code must > not be stored "long term" -- ie: in the heap or globals, because it > could be a stack pointer. Unless, well, duh..ok, any VAR parameter > or UNTRACED REF passed to unsafe code, what I just said, but traced > refs can be held onto -- they are by definition not stack pointers. > > I guess, you know..programming C code that interacts with Modula-3 > code..you realize the incompleteness of the C type system. Modula-3 > has, let's say, var, traced ref, and untraced ref. C just has > pointers. The compiler doesn't know any better, the programmer has to. > > If you imagine a Modula-3 to C header compiler..which I would > like..you know, it outputs C headers that map FROM Modula-3 > interfaces (instead of the usual hand translations in either > direction), it would likely lose a lot of information and only be > for special purpose use, unless, unlikely, not likely valuable, this > problem was solved. > Which..oh, this is interesting..I can see, to solve this, you'd need > an "API" for storing pointers perhaps. Something perhaps to make > sure the pointer is allowed to be stored like such. Not sure. But I > suspect this "API" is related to the "checks" that the Modula-3 > compiler generates...I really need to understand those... > > > Generally this is easy, because generally things are "synchronous" > -- generally the C code doesn't hold on to its parameters beyond the > lifetime of itself -- doesn't store it in the heap or globally for > other threads to use, and generally the Modula-3 code isn't busy > freeing the parameters on another thread, in fact VAR parameters > cannot be freed, they are on the stack, and traced refs can only be > freed..if the garbage collector can't find any references to > them..and then untraced refs require "discipline" both in the > Modula-3 code and the C code, but again generally, saved by > "synchronicity" -- C code doesn't hold on to them, Modula-3 code > doesn't free them on another thread. Those scenarios are certainly > possible, just not all that common, and as soon as you "escape" to > safe Modula-3 code, not a possibility..no untraced refs.. > > > About right? > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Jan 2 11:15:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 02 Jan 2009 11:15:25 +0100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <495B901F.1E75.00D7.1@scires.com> References: <20081231105208.9CF4710D5DDE@birch.elegosoft.com> <495B4846.1E75.00D7.1@scires.com> <495B901F.1E75.00D7.1@scires.com> Message-ID: <20090102111525.16anbdkwg8ocg44k@mail.elegosoft.com> See below (still trying to catch up on M3 mails ;-) Quoting Randy Coleburn : > Jay: > > First, I do want to say thanks for all you are doing for the cause > of Modula-3. I don't think we say thanks enough for what others do > for us. THANK YOU! > > I don't want to be perceived as "complaining", rather I am trying to > voice my opinion in the hopes of influencing future direction. Of > course, since I'm not doing the work, I can only make suggestions. > > In reading your post, you state that you deoptimized the native > implementation to make it match Cygwin. Now, I'm not sure how much > effect this deoptimization has (maybe little), but it is clear that > in this case your implementation choice has favored the non-native > implementation over the native one. IMO, tradeoffs of this type are > not good. If one is trying to convince someone to use Modula-3, > why would you want to give them a "deoptimized" version just to > make it easier to support a non-native environment---indeed, one > that they may not even want/use? If we have to make a trade-off, I > say favor the native implementation always over the non-native one. > > What I'm trying to say here is that my experience as a software, > systems, and program engineer is that I've always been forced to > justify the cost/benefit of development tools for any project. Many > times I've had to go head to head with folks higher up in my own > organization or in the customer's organization whose preconceived > opinions were based on rumor and what they've heard rather than > actual factual hands-on experience. I want to pick the best tool > for the job instead of being forced to pick an inferior tool because > someone higher in the food chain demanded it based on faulty > preconceived opinion. I like Modula-3. I've found that I am more > productive using it. But, if the compiler doesn't produce efficient > code, I lose ground in arguing with the higher-ups. > > As for Python, I've never ventured to learn it, so for me, it is > something of a mystery. But you miss the point. I'm not arguing > the merits of Python, I'm just saying that anything Modula-3 > requires on top of what is provided by the standard host platform > represents a potential obstacle or barrier to ease of > use/implementation. It also sends the message that somehow Modula-3 > is not complete on its own, we have get Python just to install and > oh yes we need a C compiler and a linker and a ...? IMO, > ultimately we need a turn-key download and install routine for > Modula-3 that just works, out-of-the-box. If you give me an EXE, a > CMD, or a BAT, for the install, I can run it on Windows, but if you > give me an install routine that requires I first install something > else, e.g. Python, then that becomes a barrier to the folks who > don't know Python or already have it installed. > > Am I alone in this line of thought? If so, I'll just be quiet. No, you're not alone here. Ultimately, I think we should have something that installs very easily without any preconditions, too. But it is difficult to achieve and maintain this quality in an open source project with so few volunteers. So I am afraid that there will have to be some tradeoffs, but we should try to keep them reasonably small. Thus said, I think it is great that you are speaking up here, as great as it is that Jay is doing this great amount of work for M3. It is important that changes are reviewed and reasons are questioned for the overall quality of the project. And as long as we are polite and argue reasonably and not personally, this is only good for the project, too. Thanks to all who are contributing to the M3 delevopment, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Jan 2 11:27:24 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 02 Jan 2009 11:27:24 +0100 Subject: [M3devel] variations of waitpid..? In-Reply-To: References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> Message-ID: <20090102112724.5sr7fnp000cokcco@mail.elegosoft.com> Quoting Tony Hosking : > If someone uses waitpid they get what they paid for. It is so long ago that we wrote those sysutils routines... They have only ever be used in simple command line utilities (like cm3) without much concurrency, I think. If there is potential for deadlocks and bad performance, we should at least document that in the interfaces. I am not up-to-date wrt. the M3 system interfaces and threads implementation: is there a way for a thread to wait for the exit code of another process without blocking other threads? If so, I'll adapt the sysutils code... If not, can we introduce such an interface in m3core/libm3? Olaf > On 1 Jan 2009, at 06:24, Jay wrote: > >> >> You mean, this function is easy to misuse? >>> People who declare their own <*EXTERNAL*> >> Like waitpid exposed from m3core? >> >> waitpid is already easy to misuse, on a userthread system, leading >> to possible (though I think rare) deadlock. >> It is easy to misuse on pthreads, lead "just" to bad performance, >> and in fact I believe cm3 is doing this, via sysutils. >> This at least guides you between two patterns of use, and fix the >> perf of cm3/sysutils. >> >> On a userthread system, waitpid(pid, flags = 0) waits for the child >> process, with all parent threads suspended. >> Generally I doubt the child depends on parent threads progressing, >> but, yeah, that could deadlock, like if a parent thread is waiting >> to a file or stdin of the child, or reading a child's stdout. >> >> The various uses do waitpid(pid, flags = nohang) and then sleep and >> try again. >> >> pthreads just uses waitpid(pid, flags = 0) and all threads keep running -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Jan 2 11:32:57 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 02 Jan 2009 11:32:57 +0100 Subject: [M3devel] FW: variations of waitpid..? In-Reply-To: References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> Message-ID: <20090102113257.me6vseyaskggssoc@mail.elegosoft.com> Quoting Jay : > (Personally I have seen precious little code that cares about stack > size, just seems to somehow get along, combined with the fact that > the current Modula-3 pthread code very likely leaks on some > platforms attempting to deal with stack size, makes me inclined to > just rip out the code..but yeah..just fix the leak...) Please don't do that (remove the ability to set stack sizes). I know that for most of the programs I wrote years ago we had to adapt stack sizes for threads carefully. That was with user threads though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Jan 2 11:42:48 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 02 Jan 2009 11:42:48 +0100 Subject: [M3devel] TEXT & etc. In-Reply-To: <495D1339.2070703@wichita.edu> References: <200812310822.mBV8Mf2j027994@camembert.async.caltech.edu> <495D1339.2070703@wichita.edu> Message-ID: <20090102114248.lcnartw3eowcs4gg@mail.elegosoft.com> Quoting "Rodney M. Bates" : > I started working on a more elaborate package of performance improvements > to TEXT operations. They are algorithm-only (no changes to declarations or > invariants of data structure), thus no effect on pickles, stubs, etc., as > is your change. > > I am flattening concatenations only when the result has finite bounded > length, keeping Text.Cat O(1), although with considerably larger constant > factor. I am also doing two-level rebalancing of trees, also O(1). > Without knowing depths (which would require either an O(log N) algorithm > to compute then or caching them, requiring data structure changes), I am > using lengths as a crude estimate of depth. > > Meanwhile I am recoding get_chars/get_wide_chars to recurse on only > the shorter side and iterate on the other. This, in combination with > better balance, should cut down greatly on stack depth and execution > time. > > I am also avoiding cases where a number of other operations in the current > implementation unnecessarily convert concatenations containing only 8-bit > representations to 16, which requires a character-by-character loop > to expand them. > > I also have found a couple of bugs. All this sounds good. Have you already committed some of your work? (I'm not following m3commit closely these days.) Have you also some test cases that will validate the TEXT behaviour for concatenations etc.? Olaf > Hopefully, these will help. > > Mika Nystrom wrote: >> Hello everyone, >> >> I mentioned a week or two ago that I had run into horrific performance >> issues with CM3's TEXTs. It wasn't my intention to start a debate >> about Unicode and Mahjong characters, just to point out that there's >> a serious performance problem with CM3 in this area. I run into >> performance problems with CM3 from time to time because I am trying >> to maintain a fairly large amount of software written in Modula-3 >> and it appears to me that the SRC/PM3 compilers often pay better >> attention to performance issues than the newer CM3 compiler. >> Generally speaking I think Modula-3 needs to avoid getting into the >> Java situation: Java is squeezed between "fast enough" Python and >> "much more efficient" C++... Modula-3 I see as the only hope for >> getting the performance of C++ with the safety of Java. The problems >> I have seen with CM3 are in the following areas: >> >> 1. Thread mutex acquisition involving kernel calls (pthreads >> implementation) >> >> 2. ISTYPE and TYPECASE (appear much faster on PM3, don't know why, >> could just be a profiling issue). In any case TYPECASE is very slow >> because of having to search the type tree. This could be improved >> but I can't work on it because I always run into some kind of fatal >> problem trying to bootstrap the compiler. >> >> 3. The TEXT issue. I mentioned performance problems before. It >> turns out that it was showing up in another area. I upgraded my >> PowerBook >> a while back (to OS X 10.4) and of course everything stopped working, >> including at least half my Modula-3 programs. I thought it was a >> versioning problem with C libraries I was importing, but it >> turned out >> that in at least one case I was running out of stack space because of >> the calls to get_char on concatenated TEXTs. (Not very long ones, >> at that.) >> >> To get to the point. What follows is my new version of TextCat.m3, >> which I believe works, but I can't really say because I'm perennially >> incapable of bootstrapping CM3. The basic idea is that you can >> have *one* TextCat.T, at the "root" of your TEXT. It will flatten >> anything else. I don't see a simple way of modifying the CM3 TEXT >> implementation to do much better than this. Of course throwing out >> TextCat.T completely >> is an option. >> >> An advantage of what I've done is that I haven't changed any interfaces >> at all. So I don't get problems with version stamps, etc. >> >> Mika >> >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.bates at wichita.edu Fri Jan 2 18:29:26 2009 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 02 Jan 2009 11:29:26 -0600 Subject: [M3devel] TEXT & etc. In-Reply-To: <20090102114248.lcnartw3eowcs4gg@mail.elegosoft.com> References: <200812310822.mBV8Mf2j027994@camembert.async.caltech.edu> <495D1339.2070703@wichita.edu> <20090102114248.lcnartw3eowcs4gg@mail.elegosoft.com> Message-ID: <495E4EF6.6030406@wichita.edu> No, I have not committed anything yet. I have it temporarily coded so the the operations can be switched between the old and new versions by setting a (gasp!) global variable. I plan to write a test program that generates many (10s of thousands) of random operations on texts, does them using old and new algorithms, and compares results. I have used this testing approach on several projects in the past, with very good success. My preferred development style is to get a group of related changes complete and tested before committing anything. For one thing, that saves me from having to retest after every little change. Just since my previous post, I have already had to do some rethinking about how much and what kind of rebalancing to do. Olaf Wagner wrote: > Quoting "Rodney M. Bates" : > >> I started working on a more elaborate package of performance improvements >> to TEXT operations. They are algorithm-only (no changes to >> declarations or >> invariants of data structure), thus no effect on pickles, stubs, etc., as >> is your change. >> >> I am flattening concatenations only when the result has finite bounded >> length, keeping Text.Cat O(1), although with considerably larger constant >> factor. I am also doing two-level rebalancing of trees, also O(1). >> Without knowing depths (which would require either an O(log N) algorithm >> to compute then or caching them, requiring data structure changes), I am >> using lengths as a crude estimate of depth. >> >> Meanwhile I am recoding get_chars/get_wide_chars to recurse on only >> the shorter side and iterate on the other. This, in combination with >> better balance, should cut down greatly on stack depth and execution >> time. >> >> I am also avoiding cases where a number of other operations in the >> current >> implementation unnecessarily convert concatenations containing only 8-bit >> representations to 16, which requires a character-by-character loop >> to expand them. >> >> I also have found a couple of bugs. > > All this sounds good. Have you already committed some of your work? > (I'm not following m3commit closely these days.) > Have you also some test cases that will validate the TEXT behaviour > for concatenations etc.? > > Olaf > > From jay.krell at cornell.edu Fri Jan 2 19:18:20 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 2 Jan 2009 18:18:20 +0000 Subject: [M3devel] variations of waitpid..? In-Reply-To: <20090102112724.5sr7fnp000cokcco@mail.elegosoft.com> References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> <20090102112724.5sr7fnp000cokcco@mail.elegosoft.com> Message-ID: > is there a way for a thread to wait for the exit code> of another process without blocking other threads? If so, I'll adapt Yes, by using kernel threads (which is all that work currently, but I'll probably fix that..) If you know you are using kernel threads, you can optimize accordingly. I measured the difference when I fixed m3core/libm3 and it was significant, though I forgot the details (they should be in the m3commit or m3devel history). I didn't measure for sysutils. It seems to me that sysutils provides /roughly/ but not exactly identical abstractions as m3core/libm3. This is not "bad", it just means m3core/libm3 aren't necessarily providing the best, sufficiently general abstractions. That happens. (It is also common for folks to reimplement stuff due to not understanding what is available, or there being a real or perceived inability to change what is available.) For this reason, that I fixed m3core/libm3 months ago, does not help sysutils. That is, sysutils uses waitpid, and the waitpid uses in m3core/libm3 are "buried" in higher abstractions. m3core/waitpid itself, I think, is not where this fix belongs. But maybe. I think that would change its semantics too much, even if its semantics are problematic. Maybe. I hadn't considered this. At least the change would only be in the user threads implementation. Everyone could perhaps just pass 0, and a wrapper would change to nohang and poll/sleep loop. pthreads would not -- it'd just pass on directly through. A lower level interface is needed for sysutils, and I added one. I added SchedulerPosix.DoesWaitPidYield. It just returns true for pthreads and false for userthreads. However, I believe sysutils cannot take on new m3core/libm3 dependencies, unless the minimum version for bootstrapping is raised, to a version that includes those changes. Therefore I don't use the very abstraction provided to solve the problem, but something similar. The code is now prepared to trivially switch to it, when the time comes that the minimum m3core/libm3 is raised. Similar story as the portable waitpid C wrapper, which I think fixes errors on I386_DARWIN and AMD64_DARWIN, though that I think only matters if a process returns non-zero, was ok for returning 0. There the code is well shared, but via automated copy and rename. For waitpid, I changed the "copied abstraction" to just be an interace containing a constant, instead of a function call. Perhaps a constant in m3core would be appropriate too. However..I wonder if the user/kernel threads option should be chosable at runtime or the command line or the default changable when building executables, all using the same runtime that could support either, therefore a function call. I know, it isn't chosable as such currently, it is a feature of the m3core as-built, but maybe a nice idea. - Jay> Date: Fri, 2 Jan 2009 11:27:24 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] variations of waitpid..?> > Quoting Tony Hosking :> > > If someone uses waitpid they get what they paid for.> It is so long ago that we wrote those sysutils routines...> They have only ever be used in simple command line utilities (like cm3)> without much concurrency, I think. If there is potential for deadlocks> and bad performance, we should at least document that in the interfaces.> > I am not up-to-date wrt. the M3 system interfaces and threads> implementation: is there a way for a thread to wait for the exit code> of another process without blocking other threads? If so, I'll adapt> the sysutils code... If not, can we introduce such an interface in> m3core/libm3?> > Olaf> > > On 1 Jan 2009, at 06:24, Jay wrote:> >> >>> >> You mean, this function is easy to misuse?> >>> People who declare their own <*EXTERNAL*>> >> Like waitpid exposed from m3core?> >>> >> waitpid is already easy to misuse, on a userthread system, leading > >> to possible (though I think rare) deadlock.> >> It is easy to misuse on pthreads, lead "just" to bad performance, > >> and in fact I believe cm3 is doing this, via sysutils.> >> This at least guides you between two patterns of use, and fix the > >> perf of cm3/sysutils.> >>> >> On a userthread system, waitpid(pid, flags = 0) waits for the child > >> process, with all parent threads suspended.> >> Generally I doubt the child depends on parent threads progressing, > >> but, yeah, that could deadlock, like if a parent thread is waiting > >> to a file or stdin of the child, or reading a child's stdout.> >>> >> The various uses do waitpid(pid, flags = nohang) and then sleep and > >> try again.> >>> >> pthreads just uses waitpid(pid, flags = 0) and all threads keep running> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jan 2 19:36:33 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 2 Jan 2009 18:36:33 +0000 Subject: [M3devel] FW: variations of waitpid..? In-Reply-To: <20090102113257.me6vseyaskggssoc@mail.elegosoft.com> References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> <20090102113257.me6vseyaskggssoc@mail.elegosoft.com> Message-ID: The pthreads code appears to leak for every thread created, as a result of trying to set stack size.I'll just fix it, once confirmed. Setting stack size is basically impossible all around.Both by the user and by "the OS". By the user: If the user calls into any dynamically linked code he didn't write, he doesn'tknow what is needed, without a lot of testing, and it can change in time. If the user so much as compiles with different flags or a different compileror targeting a different platform, stack use will change. By the OS: Same thing -- the OS doesn't know how much stack any user will need. Personally I generally practise and recommend minimizing stack usageand using heap instead. However there are large tradeoffs inperf and medium tradeoffs in debuggability (debuggers do a betterjob of immediately showing the contents of character arrays, insteadof pointers, which they don't follow automatically, at least cdb/ntsd/windbg,not sure about the various gdb/dbx/visualstudio). A terrible pattern imho, is stuff like char FilePath[some large maximum like 200 or 1000]; They use up the stack fast, are usually wasteful over-allocations, and sometimes arbitrary capacity-limiting under-allocations. For paths in particular, Win32 advertises two maximums, one of which is wrong, the other of which is suspicous -- 260 and 32K. 32K isn't clearly correct due to the availability of relative opens. Even if 32K is considered correct, it is way too much to allocate "just in case". Better to determine the actual needed size and allocate that. (I think current Cygwin code does just this though -- blow up a bunch of buffers to 32K.) Imho. Oh, and the common Unix advertisement of 1024 is also perhaps wrong.You know, what happens if I am using SMB to NT, or to another system with a different max?Do paths beyond 1024 get truncated, or unavailable, or overflow buffers?They can certainly exist.I'll have to try it out sometime. In general on disk structures are all "relative" and have no limits for full paths,only usually for individual path elements. The stack is generally of relatively small capacity, and when it is exhausted,that is more difficult to detect and recover from, than heap or addressspaceexhaustion. True, even heap and addresspace can run out, by either being "only" 32bits, orvia fragmentation, and are difficult to recover from.I personally don't defend against fragmentation, and it worries me some.It's maybe not a concern in Modula-3 due to compaction, however compactionseems also bad in that it requires larger contiguous memory.Fragmentation is good. Fragmentation is bad.. - Jay> Date: Fri, 2 Jan 2009 11:32:57 +0100> From: wagner@> To: m3devel@> Subject: Re: [M3devel] FW: variations of waitpid..?> > Quoting Jay:> > > (Personally I have seen precious little code that cares about stack > > size, just seems to somehow get along, combined with the fact that > > the current Modula-3 pthread code very likely leaks on some > > platforms attempting to deal with stack size, makes me inclined to > > just rip out the code..but yeah..just fix the leak...)> > Please don't do that (remove the ability to set stack sizes). I know> that for most of the programs I wrote years ago we had to adapt stack> sizes for threads carefully. That was with user threads though.> > Olaf -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jan 2 19:44:48 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 2 Jan 2009 18:44:48 +0000 Subject: [M3devel] dynamic chose between user/kernel threads? Message-ID: Should the user/kernel thread chose be available: On the command line to a Modula-3 executable (or even an executable where main is in another language, but which static or dynamic Modula-3 libs are used)? Via a quake directive when building programs? You know, imagine you have a bunch of Modula-3 programs and some but not all use a very large number of threads and benefit from userthreads. Currently the chose is locked into m3core when it is built. I understand (and anyone who likes the idea should understand) this is not easy to achieve. Well, at the very least, it is a tedious transform of the code, not anything hard to understand, just not a small physical change. The choice also has to be communicated very early in "startup/initialization", since e.g. the garbage collector creates a thread for itself during "startup/initialization" -- letting Main's body call Scheduler.SetThreadImplementation(enum [UserThreads, KernelThreads]) would not likely work, and not be provided. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jan 2 20:15:48 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 2 Jan 2009 19:15:48 +0000 Subject: [M3devel] variations of waitpid..? In-Reply-To: <20090102112724.5sr7fnp000cokcco@mail.elegosoft.com> References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> <20090102112724.5sr7fnp000cokcco@mail.elegosoft.com> Message-ID: I didn't read that well -- the deadlock risk in sysutils is not there. The bad perf is probably. To be clear (esp. for folks that might not already know about this, I didn't know about until fairly recently), there are two options: waitpid(pid, flags = 0) move along or while (waitpid(pid, flags = nohang) != 0) sleep(some value) The second is what sysutils was doing, and works, doesn't deadlock, is deoptimized. m3core/libm3 did this for a long time as well. When I complained about perf, it was pointed out to me. The first has deadlock potential with userthreads, but is ok and faster with kernel threads. waitpid(flags = nohang = don't actually wait, just get the exit code, if there is one) is a way to quickly poll if a process has ended, and if so, get its exit code. In Win32 there are two seperate functions GetExitCodeProcess and WaitForSingleObject or WaitForMultipleObjects ("waiting" is generalized across files, processes, sockets, files, threads, semaphores, mutexes, events and more..but not critical sections..only kernel objects). These have a bug too. One particular exit code is reserved to mean "the process is still running", but that is easily avoided by using Wait first. I have seen code get confused by this though. Wait also accepts a timeout, 32bit unsigned milliseconds, including 0 and infinity, so also can be used to poll. Win32 also defines the exit code to be 32bits, whereas Posix only allows for 8 bits which can be an interop problem. Perl on Win32 truncates exit codes to 8 bits, very bad. Unhandled exceptions end up as "large" exit codes. Anyway... The problem with the polling approach, at least part of the problem, is that if the child process isn't done when waitpid is first called, but finishes before sleep(whatever value) ends, we will still sleep for the full "whatever value". You only really want to sleep until the child process is done, and no longer. Making just the first sleep shorter might be a good idea. You know, to handle processes that are short-lived, but not "zero" lived. ("zero" being the amount of time it takes for the code to proceed from fork/exec to waitpid, surely much smaller than a small sleep() but longer than no sleep). Calling just waitpid(flags = 0) could deadlock if, for example, a parent thread is writing to a child's stdin, and the child won't finish until the parent has written all that it needs to. The parent and child process, er, other threads in the parent process, need to be allowed to run concurrently, for the sake of at least some reasonable scenarios. With kernelthreads, the implementation of waitpid knows about threads and will itself, in a sense, do the poll/sleep, but not exactly that -- it won't sleep beyond the child process finishing. Hopefully this makes sense and lets more folks understand the problem. What you can do, of course, is like: if kernelthreads waitpid(flags = 0) else while (waitpid(flags = nohang) != 0) sleep and that is basically what the code looks like now. The part "if kernelthreads" I propose be "if SchedulerPosix.DoesWaitPidYield()" though a really direct "if Thread or Scheduler.KernelThreads" might be reasonable. Up to folks then to decide what that implies.. - Jay> Date: Fri, 2 Jan 2009 11:27:24 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] variations of waitpid..?> > Quoting Tony Hosking :> > > If someone uses waitpid they get what they paid for.> It is so long ago that we wrote those sysutils routines...> They have only ever be used in simple command line utilities (like cm3)> without much concurrency, I think. If there is potential for deadlocks> and bad performance, we should at least document that in the interfaces.> > I am not up-to-date wrt. the M3 system interfaces and threads> implementation: is there a way for a thread to wait for the exit code> of another process without blocking other threads? If so, I'll adapt> the sysutils code... If not, can we introduce such an interface in> m3core/libm3?> > Olaf> > > On 1 Jan 2009, at 06:24, Jay wrote:> >> >>> >> You mean, this function is easy to misuse?> >>> People who declare their own <*EXTERNAL*>> >> Like waitpid exposed from m3core?> >>> >> waitpid is already easy to misuse, on a userthread system, leading > >> to possible (though I think rare) deadlock.> >> It is easy to misuse on pthreads, lead "just" to bad performance, > >> and in fact I believe cm3 is doing this, via sysutils.> >> This at least guides you between two patterns of use, and fix the > >> perf of cm3/sysutils.> >>> >> On a userthread system, waitpid(pid, flags = 0) waits for the child > >> process, with all parent threads suspended.> >> Generally I doubt the child depends on parent threads progressing, > >> but, yeah, that could deadlock, like if a parent thread is waiting > >> to a file or stdin of the child, or reading a child's stdout.> >>> >> The various uses do waitpid(pid, flags = nohang) and then sleep and > >> try again.> >>> >> pthreads just uses waitpid(pid, flags = 0) and all threads keep running> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Fri Jan 2 21:22:45 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 2 Jan 2009 20:22:45 +0000 (GMT) Subject: [M3devel] Modula-3 auto keyword upcase In-Reply-To: <495D8FB9.6030800@bellsouth.net> Message-ID: <562083.11611.qm@web28610.mail.ukl.yahoo.com> Hi, I know there are two good options, but yo may want to try first and see what adjust better for your purposes: The m3clipse projects which currently has developed a parser that builds the AST tree and gives you highlighting capabilities of Eclipse Editors (also auto completes) You may want to try download the source and build as a Java Plugin Project, http://sourceforge.net/cvs/?group_id=183896 if doesn't work or have doubts on how to do it just write the m3clipse project list or me. The author told me that: "The simplest way is to start Eclipse (3.3), choose File->import and load the workset file" that is m3clipse.psf file The other possibility but is still more in development is the Cooledit Text Editor Modula-3 syntax work made by Pino Zollo (he agrees to put the files on elego cvs tree ): http://freshmeat.net/projects/cooledit/ You can put the two files which are attached (Syntax and modula3.syntax)? and you will get some completion features (I couldn't see if that works still as the author told me it does, but highlighting works),? and offers easy macro construction on the Editor and easy interaction with python scripts. I managed to compile the cooledit itself and then put the 2 files on the path ~/.cedit/? (or in the Unix installation path /usr/local/share/cooledit/syntax ) but I needed to add the following two lines in the Syntax file (no modula3.syntax) : file ..\*\\.(m3|i3|ig|mg)$ Modula3\sProgram include modula3.syntax Cooledit? should work in Win32 platforms as well. Also he commented me the mc program could use this two files as well. Hope this helps --- El jue, 1/1/09, Martin Bishop wrote: De: Martin Bishop Asunto: [M3devel] Modula-3 auto keyword upcase Para: m3devel at elegosoft.com Fecha: jueves, 1 enero, 2009 10:53 I use the Modula-3 elisp code for Emacs to edit Modula-3 source, but it's somewhat annoying having to hit TAB to complete keywords (otherwise I have to hold shift to type them out). I have used an Oberon mode for Emacs before, that would auto upcase the keywords. If you typed 'module' and then pressed space, it would become 'MODULE', etc. I tried to modify the code from the Oberon mode and add it to the Modula-3 mode, but I had no luck. Does anyone know of any Modula-3 elisp code that does this? Or is there another editor that is capable of this? I have NEdit and jEdit, both have Modula-3 highlighting support, but neither help in actually editing Modula-3 code. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Syntax Type: application/octet-stream Size: 4510 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: modula3.syntax Type: application/octet-stream Size: 5846 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: m3clipse.psf Type: application/octet-stream Size: 329 bytes Desc: not available URL: From rcoleburn at scires.com Fri Jan 2 22:18:40 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 02 Jan 2009 16:18:40 -0500 Subject: [M3devel] FW: variations of waitpid..? In-Reply-To: References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> Message-ID: <495E3E42.1E75.00D7.1@scires.com> Jay: Your comment about stack size rang a bell with me. I have had trouble in the past running out of stack space, most notably on HP-UX. Same program built on Windows usually did not suffer the same fate. I seem to recall the most stack space trouble was when a thread did anything with Trestle/FormsVBT etc. So, I added a command line switch to my program that let's you specify a multiplier for the stack size. During initialization, my programs read the command line switches and take appropriate action to increase the thread stack sizes before any threads are created. If you don't specify a stack size multiplier on the command line, I think I wound up using seven (7) as the default. Here is a code excerpt: IF stackMult > 1 THEN WITH default = Thread.GetDefaultStackSize(), desired = default * stackMult, increase = desired - default DO PutText("Increasing default stack size by a factor of " & Fmt.Int(stackMult) & " (" & Fmt.Int(default) & " >>> " & Fmt.Int(desired) & ").\n"); Thread.IncDefaultStackSize(increase); END; (* with *) WITH default = Thread.GetDefaultStackSize() DO PutText("Thread stacks are now " & Fmt.Int(default) & " bytes.\n"); END; (* with *) END; (* if *) Regards, Randy >>> Jay 12/31/2008 8:59 PM >>> [truncated just slightly..and probably will be again given more rambling..] ps: the internal use in m3core could be easily removed, just by compiling one branch of the if or the other. I just wanted them in the same file to keep similar code closer together. So it comes down that m3core does expose Uwaitpid.waitpid and Uexec.waitpid, and as long as they are...or as long as user threads exist..imho there is some obligation of m3core to expose perhaps surprising characteristics of its thread library. You might say the entire interface is already and has always been fully exposed in Thread.i3, but I don't believe it. User threads and kernel threads have too divergent too visible artifacts, that I don't think are previously exposed in the public interface. I claim it is somewhat "surprising", or at least important to know the detail of, whether or not waitpid yields to other threads. You know, I mean..let's say I am some really clever waitpid user and I really must use it. And I am using Modula-3 threads. And my child process is reading the output of Modula-3 threads. Aren't I kind of stuck? Isn't there /some/ obligation of m3core to help just a teeny tiny bit? Or, would you argue, I am obligated, if I am using Modula-3, to use the higher level interfaces, that already know about this? Well, ok, m3core did already know about, I fixed it only a few months ago, but then even the likes of sysutils is stuck? Another example, that may or may not be well exposed, is willingness/ability to set thread stack size. Mika mentions creation thousands of threads. 32bit kernel threads are going to be more limited here. Whereas 32bit user threads might be willing to create much smaller stacks, and 64 bit anything has essentially infinite address space for infinite stacks (but still beware working set, physical memory is not infinite). (Personally I have seen precious little code that cares about stack size, just seems to somehow get along, combined with the fact that the current Modula-3 pthread code very likely leaks on some platforms attempting to deal with stack size, makes me inclined to just rip out the code..but yeah..just fix the leak...) - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: mika at async.caltech.edu; m3devel at elegosoft.com Subject: RE: [M3devel] variations of waitpid..? Date: Thu, 1 Jan 2009 01:49:28 +0000 > If someone uses waitpid they get what they paid for. But someone is us -- m3core/libm3 (I think just m3core), sysutils, and then cm3 uses them. I guess there is a point that this "grand new interface" SchedulerPosix.DoesWaitPidYield has precious few users. (It isn't grand. It takes no parameters and just returns a boolean, hardcoded, depending on thread library.) m3core now (today) uses it internally -- no need for a public interface. Sysutils can't use it until the baseline m3core is newer, so arguably, not a user. Instead (today) sysutils uses m3core's m3makefiles to decide the value. Heck, waitpid is therefore only used internally by m3core, and sysutils. If sysutils could be (partly) merged into m3core, then m3core's waitpid need not be public. - Jay > CC: mika > From: hosking > To: jay > Subject: Re: [M3devel] variations of waitpid..? > Date: Thu, 1 Jan 2009 12:29:24 +1100 > > If someone uses waitpid they get what they paid for. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Jan 2 22:28:04 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 02 Jan 2009 16:28:04 -0500 Subject: [M3devel] Modula-3 auto keyword upcase In-Reply-To: <495D8FB9.6030800@bellsouth.net> References: <495D8FB9.6030800@bellsouth.net> Message-ID: <495E4076.1E75.00D7.1@scires.com> Martin: I use CRiSP. http://www.crisp.com/ If you want to try it, I can provide you with my Modula-3 keyword and template files. Regards, Randy >>> Martin Bishop 1/1/2009 10:53 PM >>> I use the Modula-3 elisp code for Emacs to edit Modula-3 source, but it's somewhat annoying having to hit TAB to complete keywords (otherwise I have to hold shift to type them out). I have used an Oberon mode for Emacs before, that would auto upcase the keywords. If you typed 'module' and then pressed space, it would become 'MODULE', etc. I tried to modify the code from the Oberon mode and add it to the Modula-3 mode, but I had no luck. Does anyone know of any Modula-3 elisp code that does this? Or is there another editor that is capable of this? I have NEdit and jEdit, both have Modula-3 highlighting support, but neither help in actually editing Modula-3 code. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Jan 2 22:41:37 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 02 Jan 2009 16:41:37 -0500 Subject: [M3devel] meaning of unsafe? In-Reply-To: References: Message-ID: <495E43A3.1E75.00D7.1@scires.com> Jay: Modula-3 has a very precise definition of what it means to have a safe or an UNSAFE module. See pages 59-61 (section 2.7 Unsafe Operations) of the "Green Book" (Systems Programming with Modula-3 edited by Greg Nelson). Bottom line is that if you don't use any features of the language that are deemed UNSAFE, your program can't cause unchecked runtime errors. Regards, Randy >>> Jay 1/2/2009 2:02 AM >>> Recent quote, that I haven't further investigated, made me realize some of my ignorance. I know that "unsafe" includes: taking address of local explicit free dealing with any untraced ref? Not sure. Questions are: is unsafe well statically enforced? and/or is safe well statically enforced? That is, should I remove unsafe "everywhere", as long as it compiles ok, it must be safe, and better, so leave it that way? And if it fails, put it back? Or do I need to think about it myself? I think for modules it might be brainless as stated -- put it in only where the compiler makes, and nowhere extra, since extra is a loss not a bonus. But for interfaces.. I think, again, ideal to remove it where you can, but that the compiler can't enforce it? At least where there is "external"? Maybe I should just reread that quote, and thing about it. Safe can code call unsafe code, but should not be able to do so with parameters that, indirectly, make the safe code unsafe. For example, I cannot safe call "free" in unsafe code on behalf of safe code, unless I am darn sure the data isn't referenced -- unless I am the garbage collector. Any pointer give to unsafe code by safe code must not be stored "long term" -- ie: in the heap or globals, because it could be a stack pointer. Unless, well, duh..ok, any VAR parameter or UNTRACED REF passed to unsafe code, what I just said, but traced refs can be held onto -- they are by definition not stack pointers. I guess, you know..programming C code that interacts with Modula-3 code..you realize the incompleteness of the C type system. Modula-3 has, let's say, var, traced ref, and untraced ref. C just has pointers. The compiler doesn't know any better, the programmer has to. If you imagine a Modula-3 to C header compiler..which I would like..you know, it outputs C headers that map FROM Modula-3 interfaces (instead of the usual hand translations in either direction), it would likely lose a lot of information and only be for special purpose use, unless, unlikely, not likely valuable, this problem was solved. Which..oh, this is interesting..I can see, to solve this, you'd need an "API" for storing pointers perhaps. Something perhaps to make sure the pointer is allowed to be stored like such. Not sure. But I suspect this "API" is related to the "checks" that the Modula-3 compiler generates...I really need to understand those... Generally this is easy, because generally things are "synchronous" -- generally the C code doesn't hold on to its parameters beyond the lifetime of itself -- doesn't store it in the heap or globally for other threads to use, and generally the Modula-3 code isn't busy freeing the parameters on another thread, in fact VAR parameters cannot be freed, they are on the stack, and traced refs can only be freed..if the garbage collector can't find any references to them..and then untraced refs require "discipline" both in the Modula-3 code and the C code, but again generally, saved by "synchronicity" -- C code doesn't hold on to them, Modula-3 code doesn't free them on another thread. Those scenarios are certainly possible, just not all that common, and as soon as you "escape" to safe Modula-3 code, not a possibility..no untraced refs.. About right? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jan 3 00:05:24 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 2 Jan 2009 23:05:24 +0000 Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer? Message-ID: I'd like to avoid using "long" and "ulong" anywhere. On Unix, they are always pointer sized. On Windows, they are always 32 bits. This divergence of meaning I think it renders it useless. I believe for pointer-sized integers, the right types are any of: unsigned: size_t, Word.T signed: INTEGER, ssize_t, ptrdiff_t For 32bit integers: int32_t and uint32_t, perhaps int. There is arguably some ambiguity if you consider 16bit platforms. Now, I noticed we have: INTERFACE Cstddef; size_t = Ctypes.unsigned_long; ssize_t = Ctypes.long; ptrdiff_t = Ctypes.long; I would like to change this, either to: 32bits: size_t = Ctypes.unsigned_int; ssize_t = Ctypes.int; ptrdiff_t = Ctypes.int; 64bits: size_t = Ctypes.unsigned_long_long; ssize_t = Ctypes.long_long; ptrdiff_t = Ctypes.long_long; or portable: size_t = Word.T; ssize_t = INTEGER; ptrdiff_t = INTEGER; but, my question then is, why isn't the portable version already in use? Especially for the signed types. I mean, you know, we have: 32bits/BasicCtypes: INTERFACE BasicCtypes; IMPORT Word, Long; TYPE (* the four signed integer types *) signed_char = [-16_7f-1 .. 16_7f]; short_int = [-16_7fff-1 .. 16_7fff]; int = [-16_7fffffff-1 .. 16_7fffffff]; long_int = [-16_7fffffff-1 .. 16_7fffffff]; question is, why aren't int and long_int INTEGER? 64bits/BasicCtypes: long_int = [-16_7fffffffffffffff -1 .. 16_7fffffffffffffff ]; long_long = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL]; why not INTEGER? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Jan 3 01:12:27 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 03 Jan 2009 01:12:27 +0100 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: References: Message-ID: <20090103011227.vgpfs347400088sg@mail.elegosoft.com> An option to cm3 or a quake directive to use in the m3makefiles would suffice in my opinion (and be a great improvement). Olaf Quoting Jay : > > Should the user/kernel thread chose be available: > > > On the command line to a Modula-3 executable (or even an executable > where main is in another language, but which static or dynamic > Modula-3 libs are used)? > > > Via a quake directive when building programs? > > > You know, imagine you have a bunch of Modula-3 programs and some but > not all use a very large number of threads and benefit from > userthreads. > > > Currently the chose is locked into m3core when it is built. > > > I understand (and anyone who likes the idea should understand) this > is not easy to achieve. > Well, at the very least, it is a tedious transform of the code, not > anything hard to understand, just not a small physical change. The > choice also has to be communicated very early in > "startup/initialization", since e.g. the garbage collector creates a > thread for itself during "startup/initialization" -- letting Main's > body call Scheduler.SetThreadImplementation(enum [UserThreads, > KernelThreads]) would not likely work, and not be provided. > > > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sat Jan 3 01:24:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 3 Jan 2009 11:24:34 +1100 Subject: [M3devel] FW: variations of waitpid..? In-Reply-To: References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> <20090102113257.me6vseyaskggssoc@mail.elegosoft.com> Message-ID: What OS is this leak on? I don't think it is anything in the Modula-3 wrappers to pthreads, but please confirm. On 3 Jan 2009, at 05:36, Jay wrote: > The pthreads code appears to leak for every thread created, as a > result of trying to set stack size. > I'll just fix it, once confirmed. > > Setting stack size is basically impossible all around. > Both by the user and by "the OS". > > By the user: > > If the user calls into any dynamically linked code he didn't write, > he doesn't > know what is needed, without a lot of testing, and it can change in > time. > > If the user so much as compiles with different flags or a different > compiler > or targeting a different platform, stack use will change. > > By the OS: > > Same thing -- the OS doesn't know how much stack any user will need. > > > Personally I generally practise and recommend minimizing stack usage > and using heap instead. However there are large tradeoffs in > perf and medium tradeoffs in debuggability (debuggers do a better > job of immediately showing the contents of character arrays, instead > of pointers, which they don't follow automatically, at least cdb/ > ntsd/windbg, > not sure about the various gdb/dbx/visualstudio). > > > A terrible pattern imho, is stuff like > char FilePath[some large maximum like 200 or 1000]; > > They use up the stack fast, are usually wasteful over-allocations, > and sometimes > arbitrary capacity-limiting under-allocations. For paths in > particular, > Win32 advertises two maximums, one of which is wrong, the other of > which is > suspicous -- 260 and 32K. 32K isn't clearly correct due to the > availability of > relative opens. > Even if 32K is considered correct, it is way too much to allocate > "just in case". > Better to determine the actual needed size and allocate that. > (I think current Cygwin code does just this though -- blow up a > bunch of buffers to 32K.) > Imho. > > Oh, and the common Unix advertisement of 1024 is also perhaps wrong. > You know, what happens if I am using SMB to NT, or to another system > with a different max? > Do paths beyond 1024 get truncated, or unavailable, or overflow > buffers? > They can certainly exist. > I'll have to try it out sometime. > > In general on disk structures are all "relative" and have no limits > for full paths, > only usually for individual path elements. > > The stack is generally of relatively small capacity, and when it is > exhausted, > that is more difficult to detect and recover from, than heap or > addressspace > exhaustion. > > True, even heap and addresspace can run out, by either being "only" > 32bits, or > via fragmentation, and are difficult to recover from. > I personally don't defend against fragmentation, and it worries me > some. > It's maybe not a concern in Modula-3 due to compaction, however > compaction > seems also bad in that it requires larger contiguous memory. > Fragmentation is good. Fragmentation is bad.. > > - Jay > > > > > > Date: Fri, 2 Jan 2009 11:32:57 +0100 > > From: wagner@ > > To: m3devel@ > > Subject: Re: [M3devel] FW: variations of waitpid..? > > > > Quoting Jay: > > > > > (Personally I have seen precious little code that cares about > stack > > > size, just seems to somehow get along, combined with the fact that > > > the current Modula-3 pthread code very likely leaks on some > > > platforms attempting to deal with stack size, makes me inclined to > > > just rip out the code..but yeah..just fix the leak...) > > > > Please don't do that (remove the ability to set stack sizes). I know > > that for most of the programs I wrote years ago we had to adapt > stack > > sizes for threads carefully. That was with user threads though. > > > > Olaf > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jan 3 05:44:01 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 3 Jan 2009 04:44:01 +0000 Subject: [M3devel] FW: variations of waitpid..? In-Reply-To: <495E3E42.1E75.00D7.1@scires.com> References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> <495E3E42.1E75.00D7.1@scires.com> Message-ID: Perhaps, tangentially, we should strive to reduce stack usage in Trestle? Not as an alternative, granted. - Jay Date: Fri, 2 Jan 2009 16:18:40 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] FW: variations of waitpid..? Jay: Your comment about stack size rang a bell with me. I have had trouble in the past running out of stack space, most notably on HP-UX. Same program built on Windows usually did not suffer the same fate. I seem to recall the most stack space trouble was when a thread did anything with Trestle/FormsVBT etc. So, I added a command line switch to my program that let's you specify a multiplier for the stack size. During initialization, my programs read the command line switches and take appropriate action to increase the thread stack sizes before any threads are created. If you don't specify a stack size multiplier on the command line, I think I wound up using seven (7) as the default. Here is a code excerpt: IF stackMult > 1 THEN WITH default = Thread.GetDefaultStackSize(), desired = default * stackMult, increase = desired - default DO PutText("Increasing default stack size by a factor of " & Fmt.Int(stackMult) & " (" & Fmt.Int(default) & " >>> " & Fmt.Int(desired) & ").\n"); Thread.IncDefaultStackSize(increase); END; (* with *) WITH default = Thread.GetDefaultStackSize() DO PutText("Thread stacks are now " & Fmt.Int(default) & " bytes.\n"); END; (* with *) END; (* if *) Regards, Randy >>> Jay 12/31/2008 8:59 PM >>>[truncated just slightly..and probably will be again given more rambling..] ps: the internal use in m3core could be easily removed, just by compiling one branch of the if or the other.I just wanted them in the same file to keep similar code closer together. So it comes down that m3core does expose Uwaitpid.waitpid and Uexec.waitpid, and as long as they are...or as long as user threads exist..imho there is some obligation of m3core to expose perhaps surprising characteristics of its thread library. You might say the entire interface is already and has always been fully exposed in Thread.i3, but I don't believe it. User threads and kernel threads have too divergent too visible artifacts, that I don't think are previously exposed in the public interface. I claim it is somewhat "surprising", or at least important to know the detail of, whether or not waitpid yields to other threads. You know, I mean..let's say I am some really clever waitpid user and I really must use it. And I am using Modula-3 threads. And my child process is reading the output of Modula-3 threads. Aren't I kind of stuck? Isn't there /some/ obligation of m3core to help just a teeny tiny bit? Or, would you argue, I am obligated, if I am using Modula-3, to use the higher level interfaces, that already know about this? Well, ok, m3core did already know about, I fixed it only a few months ago, but then even the likes of sysutils is stuck? Another example, that may or may not be well exposed, is willingness/ability to set thread stack size. Mika mentions creation thousands of threads. 32bit kernel threads are going to be more limited here. Whereas 32bit user threads might be willing to create much smaller stacks, and 64 bit anything has essentially infinite address space for infinite stacks (but still beware working set, physical memory is not infinite). (Personally I have seen precious little code that cares about stack size, just seems to somehow get along, combined with the fact that the current Modula-3 pthread code very likely leaks on some platforms attempting to deal with stack size, makes me inclined to just rip out the code..but yeah..just fix the leak...) - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: mika at async.caltech.edu; m3devel at elegosoft.comSubject: RE: [M3devel] variations of waitpid..?Date: Thu, 1 Jan 2009 01:49:28 +0000 > If someone uses waitpid they get what they paid for. But someone is us -- m3core/libm3 (I think just m3core), sysutils, and then cm3 uses them. I guess there is a point that this "grand new interface" SchedulerPosix.DoesWaitPidYield has precious few users. (It isn't grand. It takes no parameters and just returns a boolean, hardcoded, depending on thread library.) m3core now (today) uses it internally -- no need for a public interface.Sysutils can't use it until the baseline m3core is newer, so arguably, not a user. Instead (today) sysutils uses m3core's m3makefiles to decide the value. Heck, waitpid is therefore only used internally by m3core, and sysutils.If sysutils could be (partly) merged into m3core, then m3core's waitpid need not be public. - Jay> CC: mika> From: hosking> To: jay> Subject: Re: [M3devel] variations of waitpid..?> Date: Thu, 1 Jan 2009 12:29:24 +1100> > If someone uses waitpid they get what they paid for. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eiserlohpp at yahoo.com Sat Jan 3 07:52:26 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Fri, 2 Jan 2009 22:52:26 -0800 (PST) Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer? Message-ID: <443283.92057.qm@web56804.mail.re3.yahoo.com> Jay, Please don't make size_t 128 bits in size. In "C" a long is specified by the language spec to be an integral type big enough to hold a pointer. Longs in "C" may be bigger than a pointer, but they must be at least that size. NOTE: an int (integer) does not have that guarantee. In fact, I once programed on a platform (Amiga) that had two different compilers one used 16-bits and other 32 for their integers. You can imagine the difficulties. Windows machines, as you have been using, give an address space of 32 bits to user space. This is regardless of how much RAM it may actually have. I would expect that on a Win64 platform, pointers are 64 bits, and "long" is also 64 bits. On my AMD64_LINUX box, pointers are 64 bits, and therefore a long is 64, and a long long is 128. The system type size_t is 64 bits. If you attempt to map Cstddef.size_t to 128 bits it will not only break the syscall interfaces to the kernel, but also be a waste of space. >From that standpoint the type definitions size_t = Ctypes.unsigned_long; ..., etc. are correct. Please don't define size_t = Ctypes.unsigned_long_long; The "C" include files /usr/includes/bits/types.h /usr/includes/bits/typesizes.h play preprocessor games to ensure that the ssize_t are defined to use the "natural" word size. Other types get defined to fixed sizes (ie, _int32 must always be 32 bits) otherwise external interfaces (file formats, inodes, ..., etc) would be corrupted. For that reason explicitly sized types need to be defined. Actually, GNU/Modula-2 recently defined explictly sized types. Peter Eiserloh. Date: Fri, 2 Jan 2009 23:05:24 +0000 From: Jay Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer? To: m3devel , Tony Message-ID: Content-Type: text/plain; charset="iso-8859-1" I'd like to avoid using "long" and "ulong" anywhere. On Unix, they are always pointer sized. On Windows, they are always 32 bits. This divergence of meaning I think it renders it useless. I believe for pointer-sized integers, the right types are any of: unsigned: size_t, Word.T signed: INTEGER, ssize_t, ptrdiff_t For 32bit integers: int32_t and uint32_t, perhaps int. There is arguably some ambiguity if you consider 16bit platforms. Now, I noticed we have: INTERFACE Cstddef; size_t = Ctypes.unsigned_long; ssize_t = Ctypes.long; ptrdiff_t = Ctypes.long; I would like to change this, either to: 32bits: size_t = Ctypes.unsigned_int; ssize_t = Ctypes.int; ptrdiff_t = Ctypes.int; 64bits: size_t = Ctypes.unsigned_long_long; ssize_t = Ctypes.long_long; ptrdiff_t = Ctypes.long_long; or portable: size_t = Word.T; ssize_t = INTEGER; ptrdiff_t = INTEGER; but, my question then is, why isn't the portable version already in use? Especially for the signed types. I mean, you know, we have: 32bits/BasicCtypes: INTERFACE BasicCtypes; IMPORT Word, Long; TYPE (* the four signed integer types *) signed_char = [-16_7f-1 .. 16_7f]; short_int = [-16_7fff-1 .. 16_7fff]; int = [-16_7fffffff-1 .. 16_7fffffff]; long_int = [-16_7fffffff-1 .. 16_7fffffff]; question is, why aren't int and long_int INTEGER? 64bits/BasicCtypes: long_int = [-16_7fffffffffffffff -1 .. 16_7fffffffffffffff ]; long_long = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL]; why not INTEGER? +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Sat Jan 3 08:45:26 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 3 Jan 2009 07:45:26 +0000 Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer? In-Reply-To: <443283.92057.qm@web56804.mail.re3.yahoo.com> References: <443283.92057.qm@web56804.mail.re3.yahoo.com> Message-ID: Peter, Huh? Of course not. "long long" is always exactly 64 bits, except on systems where it doesn't exist at all. There isn't really any 128 bit integer type in widespread use, aside from multi precision arithmetic libraries and such. long on Windows is always 32bits, as I said. The pointer sized types are: size_t, ptrdiff_t, ssize_t, INTEGER, and any pointer Surely sizeof(long) == sizeof(void*) was considered for Win64, but rejected due to the wider spread source incompatibility it would have caused. Yes, I know, every other 64 bit system took a different route -- Alpha, AIX, Solaris, IRIX, Darwin -- but they all probably had far less code to deal with. I have also programmed with a 16bit int, but nobody seems to care about portability to that these days/decades/centuries. If folks here want to imagine Modula-3 is portable to such a system, with 16 bit INTEGER, I am willing to entertain discussion and maybe even code as to the ramifications..maybe.. - Jay> Date: Fri, 2 Jan 2009 22:52:26 -0800> From: eiserlohpp@> To: m3devel@> Subject: Re: [M3devel] long vs. INTEGER? ranges vs. word/integer?> > Jay,> > Please don't make size_t 128 bits in size. In "C" a> long is specified by the language spec to be an integral > type big enough to hold a pointer. Longs in "C" may be> bigger than a pointer, but they must be at least that size. > > NOTE: an int (integer) does not have that guarantee.> > In fact, I once programed on a platform (Amiga) that had> two different compilers one used 16-bits and other 32 for> their integers. You can imagine the difficulties.> > Windows machines, as you have been using, give an address> space of 32 bits to user space. This is regardless of how> much RAM it may actually have. I would expect that on a> Win64 platform, pointers are 64 bits, and "long" is also > 64 bits.> > On my AMD64_LINUX box, pointers are 64 bits, and therefore> a long is 64, and a long long is 128. The system type> size_t is 64 bits. If you attempt to map Cstddef.size_t> to 128 bits it will not only break the syscall interfaces> to the kernel, but also be a waste of space.> > From that standpoint the type definitions> size_t = Ctypes.unsigned_long;> ..., etc.> > are correct.> > Please don't define > size_t = Ctypes.unsigned_long_long;> > > The "C" include files> /usr/includes/bits/types.h> /usr/includes/bits/typesizes.h> > play preprocessor games to ensure that the ssize_t are> defined to use the "natural" word size. > > Other types get defined to fixed sizes (ie, _int32 must> always be 32 bits) otherwise external interfaces (file> formats, inodes, ..., etc) would be corrupted. For that> reason explicitly sized types need to be defined.> > Actually, GNU/Modula-2 recently defined explictly sized> types.> > > Peter Eiserloh.> > > > Date: Fri, 2 Jan 2009 23:05:24 +0000> From: Jay > Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer?> To: m3devel , Tony > Message-ID: > Content-Type: text/plain; charset="iso-8859-1"> > > I'd like to avoid using "long" and "ulong" anywhere.> On Unix, they are always pointer sized.> On Windows, they are always 32 bits.> > This divergence of meaning I think it renders it useless.> > I believe for pointer-sized integers, the right types are any of:> unsigned: size_t, Word.T> signed: INTEGER, ssize_t, ptrdiff_t> For 32bit integers: int32_t and uint32_t, perhaps int.> > There is arguably some ambiguity if you consider 16bit platforms.> > Now, I noticed we have:> INTERFACE Cstddef;> > size_t = Ctypes.unsigned_long; ssize_t = Ctypes.long; ptrdiff_t = Ctypes.long;> > I would like to change this, either to:> > 32bits:> size_t = Ctypes.unsigned_int; ssize_t = Ctypes.int; ptrdiff_t = Ctypes.int;> > 64bits:> size_t = Ctypes.unsigned_long_long; ssize_t = Ctypes.long_long; ptrdiff_t = Ctypes.long_long;> > or portable:> size_t = Word.T; ssize_t = INTEGER; ptrdiff_t = INTEGER;> but, my question then is, why isn't the portable version already in use?> Especially for the signed types.> > I mean, you know, we have:> > 32bits/BasicCtypes:> > INTERFACE BasicCtypes;> IMPORT Word, Long;> TYPE (* the four signed integer types *) signed_char = [-16_7f-1 .. 16_7f]; short_int = [-16_7fff-1 .. 16_7fff]; int = [-16_7fffffff-1 .. 16_7fffffff]; long_int = [-16_7fffffff-1 .. 16_7fffffff];> question is, why aren't int and long_int INTEGER?> > 64bits/BasicCtypes:> > long_int = [-16_7fffffffffffffff -1 .. 16_7fffffffffffffff ]; long_long = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];> > why not INTEGER?> > > > +--------------------------------------------------------+> | Peter P. Eiserloh |> +--------------------------------------------------------+> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jan 3 09:04:37 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 3 Jan 2009 08:04:37 +0000 Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer? In-Reply-To: <443283.92057.qm@web56804.mail.re3.yahoo.com> References: <443283.92057.qm@web56804.mail.re3.yahoo.com> Message-ID: Oh I should have read more closely to correct more.. > In "C" a> long is specified by the language spec to be an integral > type big enough to hold a pointer. Longs in "C" may be> bigger than a pointer, but they must be at least that size. No. This is very false.There is (are) the standards, and there is the practical reality, and neither agree with your assertion. In "C89", ANSI C prior to C9x, the integral types are: char -- of wierd/uncertain signedness unsigned char signed char short (aka short int aka signed short ? aka signed short int) unsigned short (aka unsigned short int) int (aka signed int) unsigned (aka unsigned int) long (aka long int aka signed long int) unsigned long (aka unsigned long int) limits.h #defines CHAR_BIT, the number of bits in a char (or signed char or unsigned char) CHAR_BIT must be at least 8. Practically speaking it is always exactly 8, but..perhaps not on a Cray. sizeof(char) == 1, by definition if char is more than 8 bits, then CHAR_BIT must be adjusted, not sizeof(char) sizeof(short) >= 2 sizeof(int) >= sizeof(short) sizeof(long) >= sizeof(int) sizeof(long) >= 4 There are some types size_t and ptrdiff_t that I'm not sure what the standard says. Something like, size_t can hold the index for any array. However, the standard doesn't like speak of address spaces and their sizes, so just what is the maximum index for an array, I don't know. Practically speaking, size_t and ptrdiff_t are the exact same size as a pointer. Practially speaking, all pointers are of the same size. Though that isn't clear in the standard as I understand. Practically speaking, all pointers roundtrip through any pointer type, as well as size_t or ptrdiff_t. There is no relationship between long and pointers, in the standard. Practically speaking: CHAR_BIT == 8 sizeof(short) == 2 sizeof(int) == 4 sizeof(long) == 4 in all 32bit and 64bit (and 16bit) Windows programming environments sizeof(long) == sizeof(void*) in most non-Windows programming environments C9x introduces several new types and typedefs. As I understand, many of the typedefs are in stdint.h, and many are optional. long long I presume is speced as: sizeof(long long) >= sizeof(long) sizeof(long long) >= 8 Practically speaking, sizeof(long long) == 8. stdint.h goes nuts with the obvious options. It defines things like: fast_intN_t -- signed type that is "fast" and at least N bits in size fast_uintN_t -- unsigned ditto least_intN_t -- smallest integer that is at leasrt N bits in size least_uintN_t -- unsigned ditto intN_t -- signed integer exactly N bits in size uintN_t -- usigned ditto intptr_t -- signed integer exactly the size of a pointer uintptr_t -- unsigned ditto Not every type is mandatory though, and "fast" is vague. Then, they go even further, they have #defines for the printf and scanf strings for each type..I think. At least they have a bunch of #defines to abstract printf/scanf, not sure they have every single one. Boom goes the combinatorial explosion. So, personally, I think this is overkill. I think you should have just the exact sized types, plus the pointer-sized types. Throw out the "least" and "fast" types. Printf/scanf is thornier. It does seem a real problem, with no pretty solution. When I am just printing for debugging purposes, I often just hardcode %u or %lu and cast my data. I usually don't care if I lose the upper 32 bits, if they are even there, when I am just debugging. Microsoft long ago introduced %I64u and %I64d, but everyone else use something else, I guess %llu and %lld for long long, or maybe %Lu and %Ld. "long long" and %ll and "least"/"fast" are all nice and abstract, but again, I think it is all overkill in terms of abstraction. As you said, persistance formats are a large concern. Persistance formats frequently guide in-memory representations. Furthermore, I theorize that the abstractions aren't all that useful for in-memory data either. If you want your capacity to grow as address space grows, use size_t. Otherwise, pick a "reasonable" type. uint32_t is almost always reasonably efficent and offers adequate capacity. If you aren't sure, well go with uint64_t, it is still /fairly/ efficient on current 32 bit systems, offers nearly infinite capacity, and is perfectly efficient on 64bit systems..and 32bit should be trending downward..maybe. 64bit is still memory-inefficient, so if you have large structs/arrays and certainly are comfy with fewer bits, use small. So..the decision isn't always trivial, but I still suspect using exactly sized types is plenty adequate, and that worrying about the other types is too much. gcc internally uses pairs of longs to portably represent 64 bits. And they also have "wide" integers -- the hosts widest integral type. I forget what they use them for, but I'm sure they are compatible with a 32 bit "wide" -- gcc is after all portable to a C compiler without long long, but probably not to a compiler with 16 bit int (unless maybe they use long everywhere in that situation? I don't know.) - Jay From: jay.krell at cornell.eduTo: eiserlohpp at yahoo.com; m3devel at elegosoft.comSubject: RE: [M3devel] long vs. INTEGER? ranges vs. word/integer?Date: Sat, 3 Jan 2009 07:45:26 +0000 Peter, Huh? Of course not. "long long" is always exactly 64 bits, except on systems where it doesn't exist at all. There isn't really any 128 bit integer type in widespread use, aside from multi precision arithmetic libraries and such. long on Windows is always 32bits, as I said. The pointer sized types are: size_t, ptrdiff_t, ssize_t, INTEGER, and any pointer Surely sizeof(long) == sizeof(void*) was considered for Win64, but rejected due to the wider spread source incompatibility it would have caused. Yes, I know, every other 64 bit system took a different route -- Alpha, AIX, Solaris, IRIX, Darwin -- but they all probably had far less code to deal with. I have also programmed with a 16bit int, but nobody seems to care about portability to that these days/decades/centuries. If folks here want to imagine Modula-3 is portable to such a system, with 16 bit INTEGER, I am willing to entertain discussion and maybe even code as to the ramifications..maybe.. - Jay> Date: Fri, 2 Jan 2009 22:52:26 -0800> From: eiserlohpp@> To: m3devel@> Subject: Re: [M3devel] long vs. INTEGER? ranges vs. word/integer?> > Jay,> > Please don't make size_t 128 bits in size. In "C" a> long is specified by the language spec to be an integral > type big enough to hold a pointer. Longs in "C" may be> bigger than a pointer, but they must be at least that size. > > NOTE: an int (integer) does not have that guarantee.> > In fact, I once programed on a platform (Amiga) that had> two different compilers one used 16-bits and other 32 for> their integers. You can imagine the difficulties.> > Windows machines, as you have been using, give an address> space of 32 bits to user space. This is regardless of how> much RAM it may actually have. I would expect that on a> Win64 platform, pointers are 64 bits, and "long" is also > 64 bits.> > On my AMD64_LINUX box, pointers are 64 bits, and therefore> a long is 64, and a long long is 128. The system type> size_t is 64 bits. If you attempt to map Cstddef.size_t> to 128 bits it will not only break the syscall interfaces> to the kernel, but also be a waste of space.> > From that standpoint the type definitions> size_t = Ctypes.unsigned_long;> ..., etc.> > are correct.> > Please don't define > size_t = Ctypes.unsigned_long_long;> > > The "C" include files> /usr/includes/bits/types.h> /usr/includes/bits/typesizes.h> > play preprocessor games to ensure that the ssize_t are> defined to use the "natural" word size. > > Other types get defined to fixed sizes (ie, _int32 must> always be 32 bits) otherwise external interfaces (file> formats, inodes, ..., etc) would be corrupted. For that> reason explicitly sized types need to be defined.> > Actually, GNU/Modula-2 recently defined explictly sized> types.> > > Peter Eiserloh.> > > > Date: Fri, 2 Jan 2009 23:05:24 +0000> From: Jay > Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer?> To: m3devel , Tony > Message-ID: > Content-Type: text/plain; charset="iso-8859-1"> > > I'd like to avoid using "long" and "ulong" anywhere.> On Unix, they are always pointer sized.> On Windows, they are always 32 bits.> > This divergence of meaning I think it renders it useless.> > I believe for pointer-sized integers, the right types are any of:> unsigned: size_t, Word.T> signed: INTEGER, ssize_t, ptrdiff_t> For 32bit integers: int32_t and uint32_t, perhaps int.> > There is arguably some ambiguity if you consider 16bit platforms.> > Now, I noticed we have:> INTERFACE Cstddef;> > size_t = Ctypes.unsigned_long; ssize_t = Ctypes.long; ptrdiff_t = Ctypes.long;> > I would like to change this, either to:> > 32bits:> size_t = Ctypes.unsigned_int; ssize_t = Ctypes.int; ptrdiff_t = Ctypes.int;> > 64bits:> size_t = Ctypes.unsigned_long_long; ssize_t = Ctypes.long_long; ptrdiff_t = Ctypes.long_long;> > or portable:> size_t = Word.T; ssize_t = INTEGER; ptrdiff_t = INTEGER;> but, my question then is, why isn't the portable version already in use?> Especially for the signed types.> > I mean, you know, we have:> > 32bits/BasicCtypes:> > INTERFACE BasicCtypes;> IMPORT Word, Long;> TYPE (* the four signed integer types *) signed_char = [-16_7f-1 .. 16_7f]; short_int = [-16_7fff-1 .. 16_7fff]; int = [-16_7fffffff-1 .. 16_7fffffff]; long_int = [-16_7fffffff-1 .. 16_7fffffff];> question is, why aren't int and long_int INTEGER?> > 64bits/BasicCtypes:> > long_int = [-16_7fffffffffffffff -1 .. 16_7fffffffffffffff ]; long_long = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];> > why not INTEGER?> > > > +--------------------------------------------------------+> | Peter P. Eiserloh |> +--------------------------------------------------------+> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.illig at gmx.de Sat Jan 3 10:05:58 2009 From: roland.illig at gmx.de (Roland Illig) Date: Sat, 03 Jan 2009 10:05:58 +0100 Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer? In-Reply-To: <443283.92057.qm@web56804.mail.re3.yahoo.com> References: <443283.92057.qm@web56804.mail.re3.yahoo.com> Message-ID: <495F2A76.7010508@gmx.de> Peter Eiserloh schrieb: > Jay, > > In "C" a > long is specified by the language spec to be an integral > type big enough to hold a pointer. Longs in "C" may be > bigger than a pointer, but they must be at least that size. That's wrong. There is nothing in the C99 standard that guarantees that. The only guarantee is that long is at least as large as int. If your assumption was true, there wouldn't have been the need to add intptr_t and uintptr_t to the language. Even size_t doesn't have to be as large as a pointer. It's perfectly ok to have a computer with a 64-bit address space, in which every object may be only 4 GB large. Then you would have sizeof(void *) == 8, and sizeof(size_t) == 4. Or take the old MS-DOS: sizeof(void *) == 4, sizeof(size_t) == 2. Roland From jay.krell at cornell.edu Sat Jan 3 13:02:23 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 3 Jan 2009 12:02:23 +0000 Subject: [M3devel] FW: variations of waitpid..? In-Reply-To: <495E3E42.1E75.00D7.1@scires.com> References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> <495E3E42.1E75.00D7.1@scires.com> Message-ID: Eek, it looks like Modula-3's default stack size is quite small, 3000 bytes on user threads, 4k on pthreads. Hm. - Jay From: jay.krell at cornell.eduTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] FW: variations of waitpid..?Date: Sat, 3 Jan 2009 04:44:01 +0000 Perhaps, tangentially, we should strive to reduce stack usage in Trestle?Not as an alternative, granted. - Jay Date: Fri, 2 Jan 2009 16:18:40 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] FW: variations of waitpid..? Jay: Your comment about stack size rang a bell with me. I have had trouble in the past running out of stack space, most notably on HP-UX. Same program built on Windows usually did not suffer the same fate. I seem to recall the most stack space trouble was when a thread did anything with Trestle/FormsVBT etc. So, I added a command line switch to my program that let's you specify a multiplier for the stack size. During initialization, my programs read the command line switches and take appropriate action to increase the thread stack sizes before any threads are created. If you don't specify a stack size multiplier on the command line, I think I wound up using seven (7) as the default. Here is a code excerpt: IF stackMult > 1 THEN WITH default = Thread.GetDefaultStackSize(), desired = default * stackMult, increase = desired - default DO PutText("Increasing default stack size by a factor of " & Fmt.Int(stackMult) & " (" & Fmt.Int(default) & " >>> " & Fmt.Int(desired) & ").\n"); Thread.IncDefaultStackSize(increase); END; (* with *) WITH default = Thread.GetDefaultStackSize() DO PutText("Thread stacks are now " & Fmt.Int(default) & " bytes.\n"); END; (* with *) END; (* if *) Regards, Randy >>> Jay 12/31/2008 8:59 PM >>>[truncated just slightly..and probably will be again given more rambling..] ps: the internal use in m3core could be easily removed, just by compiling one branch of the if or the other.I just wanted them in the same file to keep similar code closer together. So it comes down that m3core does expose Uwaitpid.waitpid and Uexec.waitpid, and as long as they are...or as long as user threads exist..imho there is some obligation of m3core to expose perhaps surprising characteristics of its thread library. You might say the entire interface is already and has always been fully exposed in Thread.i3, but I don't believe it. User threads and kernel threads have too divergent too visible artifacts, that I don't think are previously exposed in the public interface. I claim it is somewhat "surprising", or at least important to know the detail of, whether or not waitpid yields to other threads. You know, I mean..let's say I am some really clever waitpid user and I really must use it. And I am using Modula-3 threads. And my child process is reading the output of Modula-3 threads. Aren't I kind of stuck? Isn't there /some/ obligation of m3core to help just a teeny tiny bit? Or, would you argue, I am obligated, if I am using Modula-3, to use the higher level interfaces, that already know about this? Well, ok, m3core did already know about, I fixed it only a few months ago, but then even the likes of sysutils is stuck? Another example, that may or may not be well exposed, is willingness/ability to set thread stack size. Mika mentions creation thousands of threads. 32bit kernel threads are going to be more limited here. Whereas 32bit user threads might be willing to create much smaller stacks, and 64 bit anything has essentially infinite address space for infinite stacks (but still beware working set, physical memory is not infinite). (Personally I have seen precious little code that cares about stack size, just seems to somehow get along, combined with the fact that the current Modula-3 pthread code very likely leaks on some platforms attempting to deal with stack size, makes me inclined to just rip out the code..but yeah..just fix the leak...) - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: mika at async.caltech.edu; m3devel at elegosoft.comSubject: RE: [M3devel] variations of waitpid..?Date: Thu, 1 Jan 2009 01:49:28 +0000 > If someone uses waitpid they get what they paid for. But someone is us -- m3core/libm3 (I think just m3core), sysutils, and then cm3 uses them. I guess there is a point that this "grand new interface" SchedulerPosix.DoesWaitPidYield has precious few users. (It isn't grand. It takes no parameters and just returns a boolean, hardcoded, depending on thread library.) m3core now (today) uses it internally -- no need for a public interface.Sysutils can't use it until the baseline m3core is newer, so arguably, not a user. Instead (today) sysutils uses m3core's m3makefiles to decide the value. Heck, waitpid is therefore only used internally by m3core, and sysutils.If sysutils could be (partly) merged into m3core, then m3core's waitpid need not be public. - Jay> CC: mika> From: hosking> To: jay> Subject: Re: [M3devel] variations of waitpid..?> Date: Thu, 1 Jan 2009 12:29:24 +1100> > If someone uses waitpid they get what they paid for. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jan 3 13:14:02 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 3 Jan 2009 12:14:02 +0000 Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer? In-Reply-To: References: <443283.92057.qm@web56804.mail.re3.yahoo.com> Message-ID: Sorry, big mistakes, below: NOT sizeof(short) >= 2 NOT sizeof(long) >= 4 but rather sizeof(short) * CHAR_BIT >= 16sizeof(long) * CHAR_BIT >= 32 A conforming implementation, as I understand, could have: #define CHAR_BIT 32 sizeof(char) = sizeof(short) = sizeof(int) = sizeof(long) = 1 Though /practically/ speaking, CHAR_BIT is always 8 and what I said is true. You know..what is it..the Matlab model? Where everything is a 64 bit double with >= 32 bit mantissa, therefore everything could be a double? - Jay From: jay.krell at cornell.eduTo: eiserlohpp at yahoo.com; m3devel at elegosoft.comDate: Sat, 3 Jan 2009 08:04:37 +0000Subject: Re: [M3devel] long vs. INTEGER? ranges vs. word/integer? Oh I should have read more closely to correct more.. > In "C" a> long is specified by the language spec to be an integral > type big enough to hold a pointer. Longs in "C" may be> bigger than a pointer, but they must be at least that size. No. This is very false.There is (are) the standards, and there is the practical reality,and neither agree with your assertion. In "C89", ANSI C prior to C9x, the integral types are: char -- of wierd/uncertain signedness unsigned char signed char short (aka short int aka signed short ? aka signed short int) unsigned short (aka unsigned short int) int (aka signed int) unsigned (aka unsigned int) long (aka long int aka signed long int) unsigned long (aka unsigned long int) limits.h #defines CHAR_BIT, the number of bits in a char (or signed char or unsigned char) CHAR_BIT must be at least 8.Practically speaking it is always exactly 8, but..perhaps not on a Cray. sizeof(char) == 1, by definition if char is more than 8 bits, then CHAR_BIT must be adjusted, not sizeof(char) sizeof(short) >= 2 sizeof(int) >= sizeof(short)sizeof(long) >= sizeof(int)sizeof(long) >= 4 There are some types size_t and ptrdiff_t that I'm not sure what the standard says.Something like, size_t can hold the index for any array.However, the standard doesn't like speak of address spaces and their sizes, so just what is the maximum index for an array, I don't know. Practically speaking, size_t and ptrdiff_t are the exact same size as a pointer.Practially speaking, all pointers are of the same size. Though that isn't clear in the standard as I understand.Practically speaking, all pointers roundtrip through any pointer type, as well as size_t or ptrdiff_t. There is no relationship between long and pointers, in the standard. Practically speaking:CHAR_BIT == 8sizeof(short) == 2sizeof(int) == 4sizeof(long) == 4 in all 32bit and 64bit (and 16bit) Windows programming environmentssizeof(long) == sizeof(void*) in most non-Windows programming environments C9x introduces several new types and typedefs.As I understand, many of the typedefs are in stdint.h, and many are optional. long long I presume is speced as:sizeof(long long) >= sizeof(long)sizeof(long long) >= 8 Practically speaking, sizeof(long long) == 8. stdint.h goes nuts with the obvious options.It defines things like: fast_intN_t -- signed type that is "fast" and at least N bits in size fast_uintN_t -- unsigned ditto least_intN_t -- smallest integer that is at leasrt N bits in size least_uintN_t -- unsigned ditto intN_t -- signed integer exactly N bits in size uintN_t -- usigned ditto intptr_t -- signed integer exactly the size of a pointer uintptr_t -- unsigned ditto Not every type is mandatory though, and "fast" is vague. Then, they go even further, they have #defines for the printf and scanf strings for each type..I think. At least they have a bunch of #defines to abstract printf/scanf, not sure they have every single one.Boom goes the combinatorial explosion. So, personally, I think this is overkill. I think you should have just the exact sized types, plus the pointer-sized types.Throw out the "least" and "fast" types. Printf/scanf is thornier.It does seem a real problem, with no pretty solution. When I am just printing for debugging purposes, I often just hardcode %u or %lu and cast my data. I usually don't care if I lose the upper 32 bits, if they are even there, when I am just debugging. Microsoft long ago introduced %I64u and %I64d, but everyone else use something else, I guess %llu and %lld for long long, or maybe %Lu and %Ld. "long long" and %ll and "least"/"fast" are all nice and abstract, but again, I think it is all overkill in terms of abstraction. As you said, persistance formats are a large concern.Persistance formats frequently guide in-memory representations.Furthermore, I theorize that the abstractions aren't all that useful for in-memory data either.If you want your capacity to grow as address space grows, use size_t.Otherwise, pick a "reasonable" type.uint32_t is almost always reasonably efficent and offers adequate capacity.If you aren't sure, well go with uint64_t, it is still /fairly/ efficient on current 32 bit systems, offers nearly infinite capacity, and is perfectly efficient on 64bit systems..and 32bit should be trending downward..maybe.64bit is still memory-inefficient, so if you have large structs/arrays and certainly are comfy with fewer bits, use small. So..the decision isn't always trivial, but I still suspect using exactly sized types is plenty adequate, and that worrying about the other types is too much. gcc internally uses pairs of longs to portably represent 64 bits.And they also have "wide" integers -- the hosts widest integral type.I forget what they use them for, but I'm sure they are compatible with a 32 bit "wide" -- gcc is after all portable to a C compiler without long long, but probably not to a compiler with 16 bit int (unless maybe they use long everywhere in that situation? I don't know.) - Jay From: jay.krell at cornell.eduTo: eiserlohpp at yahoo.com; m3devel at elegosoft.comSubject: RE: [M3devel] long vs. INTEGER? ranges vs. word/integer?Date: Sat, 3 Jan 2009 07:45:26 +0000 Peter, Huh? Of course not. "long long" is always exactly 64 bits, except on systems where it doesn't exist at all. There isn't really any 128 bit integer type in widespread use, aside from multi precision arithmetic libraries and such. long on Windows is always 32bits, as I said. The pointer sized types are: size_t, ptrdiff_t, ssize_t, INTEGER, and any pointer Surely sizeof(long) == sizeof(void*) was considered for Win64, but rejected due to the wider spread source incompatibility it would have caused. Yes, I know, every other 64 bit system took a different route -- Alpha, AIX, Solaris, IRIX, Darwin -- but they all probably had far less code to deal with. I have also programmed with a 16bit int, but nobody seems to care about portability to that these days/decades/centuries. If folks here want to imagine Modula-3 is portable to such a system, with 16 bit INTEGER, I am willing to entertain discussion and maybe even code as to the ramifications..maybe.. - Jay> Date: Fri, 2 Jan 2009 22:52:26 -0800> From: eiserlohpp@> To: m3devel@> Subject: Re: [M3devel] long vs. INTEGER? ranges vs. word/integer?> > Jay,> > Please don't make size_t 128 bits in size. In "C" a> long is specified by the language spec to be an integral > type big enough to hold a pointer. Longs in "C" may be> bigger than a pointer, but they must be at least that size. > > NOTE: an int (integer) does not have that guarantee.> > In fact, I once programed on a platform (Amiga) that had> two different compilers one used 16-bits and other 32 for> their integers. You can imagine the difficulties.> > Windows machines, as you have been using, give an address> space of 32 bits to user space. This is regardless of how> much RAM it may actually have. I would expect that on a> Win64 platform, pointers are 64 bits, and "long" is also > 64 bits.> > On my AMD64_LINUX box, pointers are 64 bits, and therefore> a long is 64, and a long long is 128. The system type> size_t is 64 bits. If you attempt to map Cstddef.size_t> to 128 bits it will not only break the syscall interfaces> to the kernel, but also be a waste of space.> > From that standpoint the type definitions> size_t = Ctypes.unsigned_long;> ..., etc.> > are correct.> > Please don't define > size_t = Ctypes.unsigned_long_long;> > > The "C" include files> /usr/includes/bits/types.h> /usr/includes/bits/typesizes.h> > play preprocessor games to ensure that the ssize_t are> defined to use the "natural" word size. > > Other types get defined to fixed sizes (ie, _int32 must> always be 32 bits) otherwise external interfaces (file> formats, inodes, ..., etc) would be corrupted. For that> reason explicitly sized types need to be defined.> > Actually, GNU/Modula-2 recently defined explictly sized> types.> > > Peter Eiserloh.> > > > Date: Fri, 2 Jan 2009 23:05:24 +0000> From: Jay > Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer?> To: m3devel , Tony > Message-ID: > Content-Type: text/plain; charset="iso-8859-1"> > > I'd like to avoid using "long" and "ulong" anywhere.> On Unix, they are always pointer sized.> On Windows, they are always 32 bits.> > This divergence of meaning I think it renders it useless.> > I believe for pointer-sized integers, the right types are any of:> unsigned: size_t, Word.T> signed: INTEGER, ssize_t, ptrdiff_t> For 32bit integers: int32_t and uint32_t, perhaps int.> > There is arguably some ambiguity if you consider 16bit platforms.> > Now, I noticed we have:> INTERFACE Cstddef;> > size_t = Ctypes.unsigned_long; ssize_t = Ctypes.long; ptrdiff_t = Ctypes.long;> > I would like to change this, either to:> > 32bits:> size_t = Ctypes.unsigned_int; ssize_t = Ctypes.int; ptrdiff_t = Ctypes.int;> > 64bits:> size_t = Ctypes.unsigned_long_long; ssize_t = Ctypes.long_long; ptrdiff_t = Ctypes.long_long;> > or portable:> size_t = Word.T; ssize_t = INTEGER; ptrdiff_t = INTEGER;> but, my question then is, why isn't the portable version already in use?> Especially for the signed types.> > I mean, you know, we have:> > 32bits/BasicCtypes:> > INTERFACE BasicCtypes;> IMPORT Word, Long;> TYPE (* the four signed integer types *) signed_char = [-16_7f-1 .. 16_7f]; short_int = [-16_7fff-1 .. 16_7fff]; int = [-16_7fffffff-1 .. 16_7fffffff]; long_int = [-16_7fffffff-1 .. 16_7fffffff];> question is, why aren't int and long_int INTEGER?> > 64bits/BasicCtypes:> > long_int = [-16_7fffffffffffffff -1 .. 16_7fffffffffffffff ]; long_long = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];> > why not INTEGER?> > > > +--------------------------------------------------------+> | Peter P. Eiserloh |> +--------------------------------------------------------+> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stsp at elego.de Sat Jan 3 13:41:52 2009 From: stsp at elego.de (Stefan Sperling) Date: Sat, 3 Jan 2009 13:41:52 +0100 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> <20090101114139.GC10003@jack.stsp.name> Message-ID: <20090103124152.GA25002@jack.stsp.name> On Thu, Jan 01, 2009 at 07:45:44PM +0000, Jay wrote: > > What do you mean by "bootstrap binaries"? > > There are a variety of ways to get a usable system. > > > There is > [1]http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-I386_OP > ENBSD-1.tar.gz > extract it (tar zxf ...) > cd into it (cd ...) > add -lm and -lpthread to the link line > make > mkdir -p /usr/local/cm3/bin > mv cm3 /usr/local/cm3/bin > export PATH=$PATH:/usr/local/cm3/bin > export CM3_ROOT=/usr/src/cm3 or whatever > export CVSROOT=:ext:stefan at m3.elegosoft.com:/usr/cvs > cvs -z3 checkout cm3 > cd /usr/src/scripts/python > ./do-cm3-front.py buildship Thanks. I've tried that, and the ./do-cm3-front.py buildship step fails with: cd . && cd gcc && gmake CC="gcc" CFLAGS="-g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a _m3.log cd . && cd gcc && gmake CC="gcc" CFLAGS="-g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a _m3.log TARGET_CPU_DEFAULT="" \ HEADERS="auto-host.h ansidecl.h" DEFINES="" \ /bin/sh ../../gcc/gcc/mkconfig.sh bconfig.h gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc/gcc -I../../gcc/gcc/build -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I/home/stsp/src/cm3/m3-sys/m3cc/I386_OPENBSD/./gmp -I/home/stsp/src/cm3/m3-sys/m3cc/gcc/gmp -I/home/stsp/src/cm3/m3-sys/m3cc/I386_OPENBSD/./mpfr -I/home/stsp/src/cm3/m3-sys/m3cc/gcc/mpfr -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/local/include -o build/errors.o ../../gcc/gcc/errors.c build/genmodes > tmp-modes.c /bin/sh: build/genmodes: not found gmake: *** [s-modes] Error 127 "/home/stsp/src/cm3/m3-sys/m3cc/src/m3makefile", line 378: quake runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2 --procedure-- -line- -file--- cp_if -- postcp 378 /home/stsp/src/cm3/m3-sys/m3cc/src/m3makefile include_dir 444 /home/stsp/src/cm3/m3-sys/m3cc/src/m3makefile 8 /home/stsp/src/cm3/m3-sys/m3cc/I386_OPENBSD/m3make.args Fatal Error: package build failed *** execution of [, ] failed *** Stefan From eiserlohpp at yahoo.com Sat Jan 3 13:50:53 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sat, 3 Jan 2009 04:50:53 -0800 (PST) Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer? Message-ID: <83996.89296.qm@web56807.mail.re3.yahoo.com> Hi Jay, Sorry, for not speaking up earlier, I have been lurking for the last ten years. The last thing that got me really interested was the discussion about NEW() returning either NULL, or a checked runtime exception on failure to allocate memory. Okay, I wrote a test program. You are right sizeof(long) == sizeof(long long) equals 8 bytes (64 bits). So, I looked it up in the "C A Reference Manual" (CARM) 4th edition. It has been over ten years since I last looked at it. I have been corrected and educated. Sorry about discussing a foreign language, but ... To quote from page 120 (5.3): The size of a pointer is implementation dependent and in some cases varies depending on the type of the object pointed to. For example, data pointers may be shorter or longer than function pointers (section 6.1.5). There is not necessarily any relationship between pointer sizes and the size of any integer type, although it is common to assume that type _long_ is at least as large as any pointer type. Page 123 (5.3.3): 1 - Pointers are often not the same size as _int_, and sometimes not the same size as _long_. Sometimes their size is a compiler option. 2 - Character and void * pointers can be larger that other kinds of pointers, or may use a representation that is incompatible with other kinds of pointers. 3 - Function pointers and data pointer may have significantly different representations, including different sizes. Page 292 (11.1) Type _size_t_ is the unsigned integral type of the result of the sizeof operator -- probably _unsigned long_; pre-ISO implementations often use the (unsigned) type _int_ for this purpose. To paraphrase both Nelson (SPWM3) and Harbison (Modula-3). When doing a LOOPHOLE(e,T), ensure that BITSIZE(e) equals BITSIZE(T). In addition, -(x,y : ADDRESS) : INTEGER The SPWM3 does not have a LONGINT, but we now do as of a few months ago. The above operation on addresses implies that the difference between ANY two addresses can be represented in an INTEGER, with the further implication that an ADDRESS can be represented in an INTEGER (i.e., a size_t is an INTEGER). [Roland] So MS-DOS used a size_t of 2, but void* was 4, wow, that sure sounds broken. 64 KB is the maximum size of an object in memory. Thank god, we don't use MS-DOS anymore. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Sat Jan 3 16:21:23 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 3 Jan 2009 15:21:23 +0000 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: <20090103124152.GA25002@jack.stsp.name> References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> <20090101114139.GC10003@jack.stsp.name> <20090103124152.GA25002@jack.stsp.name> Message-ID: Please try export OMIT_GCC=yes. - Jay> Date: Sat, 3 Jan 2009 13:41:52 +0100> From: stsp at elego.de> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] I386_OPENBSD uploaded-archives> > On Thu, Jan 01, 2009 at 07:45:44PM +0000, Jay wrote:> > > > What do you mean by "bootstrap binaries"?> > > > There are a variety of ways to get a usable system.> > > > > > There is> > [1]http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-I386_OP> > ENBSD-1.tar.gz> > extract it (tar zxf ...)> > cd into it (cd ...)> > add -lm and -lpthread to the link line> > make> > mkdir -p /usr/local/cm3/bin> > mv cm3 /usr/local/cm3/bin> > export PATH=$PATH:/usr/local/cm3/bin> > export CM3_ROOT=/usr/src/cm3 or whatever> > export CVSROOT=:ext:stefan at m3.elegosoft.com:/usr/cvs> > cvs -z3 checkout cm3> > cd /usr/src/scripts/python> > ./do-cm3-front.py buildship> > Thanks. I've tried that, and the ./do-cm3-front.py buildship step fails with:> > cd . && cd gcc && gmake CC="gcc" CFLAGS="-g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a _m3.log> cd . && cd gcc && gmake CC="gcc" CFLAGS="-g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a _m3.log> TARGET_CPU_DEFAULT="" \> HEADERS="auto-host.h ansidecl.h" DEFINES="" \> /bin/sh ../../gcc/gcc/mkconfig.sh bconfig.h> gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc/gcc -I../../gcc/gcc/build -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I/home/stsp/src/cm3/m3-sys/m3cc/I386_OPENBSD/./gmp -I/home/stsp/src/cm3/m3-sys/m3cc/gcc/gmp -I/home/stsp/src/cm3/m3-sys/m3cc/I386_OPENBSD/./mpfr -I/home/stsp/src/cm3/m3-sys/m3cc/gcc/mpfr -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/local/include -o build/errors.o ../../gcc/gcc/errors.c> build/genmodes > tmp-modes.c> /bin/sh: build/genmodes: not found> gmake: *** [s-modes] Error 127> "/home/stsp/src/cm3/m3-sys/m3cc/src/m3makefile", line 378: quake runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2> > --procedure-- -line- -file---> cp_if -- > postcp 378 /home/stsp/src/cm3/m3-sys/m3cc/src/m3makefile> include_dir 444 /home/stsp/src/cm3/m3-sys/m3cc/src/m3makefile> 8 /home/stsp/src/cm3/m3-sys/m3cc/I386_OPENBSD/m3make.args> > Fatal Error: package build failed> *** execution of [, ] failed ***> > > Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From stsp at elego.de Sat Jan 3 16:27:24 2009 From: stsp at elego.de (Stefan Sperling) Date: Sat, 3 Jan 2009 16:27:24 +0100 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> <20090101114139.GC10003@jack.stsp.name> <20090103124152.GA25002@jack.stsp.name> Message-ID: <20090103152724.GC25002@jack.stsp.name> On Sat, Jan 03, 2009 at 03:21:23PM +0000, Jay wrote: > > Please try export OMIT_GCC=yes. No dice: new exporters -> recompiling SchedulerPosix.i3 /bin/sh: m3cg: not found m3_backend => 127 m3cc (aka cm3cg) failed compiling: SchedulerPosix.ic new exporters -> recompiling ThreadF.i3 /bin/sh: m3cg: not found m3_backend => 127 m3cc (aka cm3cg) failed compiling: ThreadF.ic new exporters -> recompiling ThreadInternal.i3 /bin/sh: m3cg: not found m3_backend => 127 m3cc (aka cm3cg) failed compiling: ThreadInternal.ic new exporters -> recompiling Time.i3 /bin/sh: m3cg: not found m3_backend => 127 m3cc (aka cm3cg) failed compiling: Time.ic new exporters -> recompiling Tick.i3 /bin/sh: m3cg: not found m3_backend => 127 m3cc (aka cm3cg) failed compiling: Tick.ic new exporters -> recompiling Date.i3 /bin/sh: m3cg: not found m3_backend => 127 m3cc (aka cm3cg) failed compiling: Date.ic new exporters -> recompiling Text.i3 /bin/sh: m3cg: not found m3_backend => 127 m3cc (aka cm3cg) failed compiling: Text.ic compilation failed => not building library "libm3core.a" Fatal Error: package build failed *** execution of [, ] failed *** Stefan From jay.krell at cornell.edu Sat Jan 3 16:30:38 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 3 Jan 2009 15:30:38 +0000 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: <20090103152724.GC25002@jack.stsp.name> References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> <20090101114139.GC10003@jack.stsp.name> <20090103124152.GA25002@jack.stsp.name> <20090103152724.GC25002@jack.stsp.name> Message-ID: Both the "min" and "std" archives should have cm3cg. Wherever you extracted the archive, did you put its bin directory in $PATH? ie: are you running cm3 by full path or via $PATH? - Jay> Date: Sat, 3 Jan 2009 16:27:24 +0100> From: stsp at elego.de> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] I386_OPENBSD uploaded-archives> > On Sat, Jan 03, 2009 at 03:21:23PM +0000, Jay wrote:> > > > Please try export OMIT_GCC=yes.> > No dice:> > new exporters -> recompiling SchedulerPosix.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: SchedulerPosix.ic> new exporters -> recompiling ThreadF.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: ThreadF.ic> new exporters -> recompiling ThreadInternal.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: ThreadInternal.ic> new exporters -> recompiling Time.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Time.ic> new exporters -> recompiling Tick.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Tick.ic> new exporters -> recompiling Date.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Date.ic> new exporters -> recompiling Text.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Text.ic> compilation failed => not building library "libm3core.a"> Fatal Error: package build failed> *** execution of [, ] failed ***> > > Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jan 3 16:59:42 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 3 Jan 2009 15:59:42 +0000 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: <20090103152724.GC25002@jack.stsp.name> References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> <20090101114139.GC10003@jack.stsp.name> <20090103124152.GA25002@jack.stsp.name> <20090103152724.GC25002@jack.stsp.name> Message-ID: > Both the "min" and "std" archives should have cm3cg. Confirmed at least for min: C:\net\modula3>lzma -d cm3-min-I386_OPENBSD-d5.7.0.tar.lzma C:\net\modula3>tar tf cm3-min-I386_OPENBSD-d5.7.0.tar | morecm3-min-I386_OPENBSD-d5.7.0cm3-min-I386_OPENBSD-d5.7.0/bincm3-min-I386_OPENBSD-d5.7.0/bin/cm3cm3-min-I386_OPENBSD-d5.7.0/bin/cm3cgcm3-min-I386_OPENBSD-d5.7.0/bin/mklibcm3-min-I386_OPENBSD-d5.7.0/bin/I386_OPENBSDcm3-min-I386_OPENBSD-d5.7.0/bin/Unix.commoncm3-min-I386_OPENBSD-d5.7.0/bin/cm3cfg.common I guess all that probing I put in (and that I use all the time, doing cross builds) MIGHT confuse things. You can look in cm3cfg.common for a big nested loop and remove it all and let it fall back to just running "cm3cg", whatever is first in $PATH. - Jay From: jay.krell at cornell.eduTo: stsp at elego.deCC: m3devel at elegosoft.comSubject: RE: [M3devel] I386_OPENBSD uploaded-archivesDate: Sat, 3 Jan 2009 15:30:38 +0000 Both the "min" and "std" archives should have cm3cg.Wherever you extracted the archive, did you put its bin directory in $PATH?ie: are you running cm3 by full path or via $PATH? - Jay> Date: Sat, 3 Jan 2009 16:27:24 +0100> From: stsp at elego.de> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] I386_OPENBSD uploaded-archives> > On Sat, Jan 03, 2009 at 03:21:23PM +0000, Jay wrote:> > > > Please try export OMIT_GCC=yes.> > No dice:> > new exporters -> recompiling SchedulerPosix.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: SchedulerPosix.ic> new exporters -> recompiling ThreadF.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: ThreadF.ic> new exporters -> recompiling ThreadInternal.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: ThreadInternal.ic> new exporters -> recompiling Time.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Time.ic> new exporters -> recompiling Tick.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Tick.ic> new exporters -> recompiling Date.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Date.ic> new exporters -> recompiling Text.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Text.ic> compilation failed => not building library "libm3core.a"> Fatal Error: package build failed> *** execution of [, ] failed ***> > > Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jan 3 17:07:05 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 3 Jan 2009 16:07:05 +0000 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: <20090103152724.GC25002@jack.stsp.name> References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> <20090101114139.GC10003@jack.stsp.name> <20090103124152.GA25002@jack.stsp.name> <20090103152724.GC25002@jack.stsp.name> Message-ID: I think I see the problem. In the file cm3cfg.common, find: % write("using m3cg in PATH (if there is one)\n") m3back = "@m3cg " & m3back_flags and change it to: % write("using cm3cg in PATH (if there is one)\n") m3back = "@cm3cg " & m3back_flags OR copy/rename/link the file to match, either way. You should be able to take the file I just commited to CVS, seconds ago. It works for me because the probing always finds my unshipped backends. This doesn't explain why you can't build in the m3cc directory. - Jay From: jay.krell at cornell.eduTo: stsp at elego.deCC: m3devel at elegosoft.comSubject: RE: [M3devel] I386_OPENBSD uploaded-archivesDate: Sat, 3 Jan 2009 15:59:42 +0000 > Both the "min" and "std" archives should have cm3cg.Confirmed at least for min: C:\net\modula3>lzma -d cm3-min-I386_OPENBSD-d5.7.0.tar.lzmaC:\net\modula3>tar tf cm3-min-I386_OPENBSD-d5.7.0.tar | morecm3-min-I386_OPENBSD-d5.7.0cm3-min-I386_OPENBSD-d5.7.0/bincm3-min-I386_OPENBSD-d5.7.0/bin/cm3cm3-min-I386_OPENBSD-d5.7.0/bin/cm3cgcm3-min-I386_OPENBSD-d5.7.0/bin/mklibcm3-min-I386_OPENBSD-d5.7.0/bin/I386_OPENBSDcm3-min-I386_OPENBSD-d5.7.0/bin/Unix.commoncm3-min-I386_OPENBSD-d5.7.0/bin/cm3cfg.commonI guess all that probing I put in (and that I use all the time, doing cross builds) MIGHT confuse things.You can look in cm3cfg.common for a big nested loop and remove it all and let it fall back to just running "cm3cg", whatever is first in $PATH. - Jay From: jay.krell at cornell.eduTo: stsp at elego.deCC: m3devel at elegosoft.comSubject: RE: [M3devel] I386_OPENBSD uploaded-archivesDate: Sat, 3 Jan 2009 15:30:38 +0000 Both the "min" and "std" archives should have cm3cg.Wherever you extracted the archive, did you put its bin directory in $PATH?ie: are you running cm3 by full path or via $PATH? - Jay> Date: Sat, 3 Jan 2009 16:27:24 +0100> From: stsp at elego.de> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] I386_OPENBSD uploaded-archives> > On Sat, Jan 03, 2009 at 03:21:23PM +0000, Jay wrote:> > > > Please try export OMIT_GCC=yes.> > No dice:> > new exporters -> recompiling SchedulerPosix.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: SchedulerPosix.ic> new exporters -> recompiling ThreadF.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: ThreadF.ic> new exporters -> recompiling ThreadInternal.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: ThreadInternal.ic> new exporters -> recompiling Time.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Time.ic> new exporters -> recompiling Tick.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Tick.ic> new exporters -> recompiling Date.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Date.ic> new exporters -> recompiling Text.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Text.ic> compilation failed => not building library "libm3core.a"> Fatal Error: package build failed> *** execution of [, ] failed ***> > > Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From stsp at elego.de Sat Jan 3 17:20:50 2009 From: stsp at elego.de (Stefan Sperling) Date: Sat, 3 Jan 2009 17:20:50 +0100 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> <20090101114139.GC10003@jack.stsp.name> <20090103124152.GA25002@jack.stsp.name> <20090103152724.GC25002@jack.stsp.name> Message-ID: <20090103162050.GD25002@jack.stsp.name> On Sat, Jan 03, 2009 at 03:30:38PM +0000, Jay wrote: > > Both the "min" and "std" archives should have cm3cg. I'm not using either of those. Your initial description of ho to build this mentioned those as alternatives, but it didn't sound like they were required. Maybe I didn't read carefully enough? I am using just these steps, as you outlined: fetch http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-I386_OPENBSD-1.tar.gz extract it (tar zxf ...) cd into it (cd ...) add -lm and -lpthread to the link line make mkdir -p /usr/local/cm3/bin mv cm3 /usr/local/cm3/bin export PATH=$PATH:/usr/local/cm3/bin export CM3_ROOT=/usr/src/cm3 or whatever export CVSROOT=:ext:stefan at m3.elegosoft.com:/usr/cvs cvs -z3 checkout cm3 cd /usr/src/scripts/python ./do-cm3-front.py buildship The very last step results in the error. The other steps succeed. > Wherever you extracted the archive, Which archive? > did you put its bin directory in $PATH? Following the steps above, I now have this: $ find /usr/local/cm3 /usr/local/cm3 /usr/local/cm3/bin /usr/local/cm3/bin/cm3 $ /usr/local/cm3/bin/cm3 -help Fatal Error: unable to locate configuration file, "cm3.cfg" $ Prior to running do-cm3-front.py, I run: export PATH=$PATH:/usr/local/cm3/bin > ie: are you running cm3 by full path or via $PATH? No idea. Whatever ./doc-m3-front.py buildship does, I guess. Stefan From jay.krell at cornell.edu Sat Jan 3 18:21:21 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 3 Jan 2009 17:21:21 +0000 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: <20090103162050.GD25002@jack.stsp.name> References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> <20090101114139.GC10003@jack.stsp.name> <20090103124152.GA25002@jack.stsp.name> <20090103152724.GC25002@jack.stsp.name> <20090103162050.GD25002@jack.stsp.name> Message-ID: Ok, well, you have to change something somewhere. If you can't build in m3cc, which we have no idea why not, and which I have you skip with export OMIT_GCC=yes, then at least get the cm3cg from the "min" or "std" archives and put it in the directory you will put cm3. The failure buildng m3cg/cm3cg/m3cc I cannot tell at all from below. Personally the problem I ran into twice is not having "gmake", but it looks like you got well past that. It doesn't fail as early or clearly as you might hope, but again, I think you got past that. - Jay> Date: Sat, 3 Jan 2009 17:20:50 +0100> From: stsp at elego.de> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] I386_OPENBSD uploaded-archives> > On Sat, Jan 03, 2009 at 03:30:38PM +0000, Jay wrote:> > > > Both the "min" and "std" archives should have cm3cg.> > I'm not using either of those. Your initial description of ho> to build this mentioned those as alternatives, but it didn't> sound like they were required. Maybe I didn't read carefully> enough?> > I am using just these steps, as you outlined:> > fetch http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-I386_OPENBSD-1.tar.gz> extract it (tar zxf ...) > cd into it (cd ...) > add -lm and -lpthread to the link line > make > mkdir -p /usr/local/cm3/bin > mv cm3 /usr/local/cm3/bin > export PATH=$PATH:/usr/local/cm3/bin > export CM3_ROOT=/usr/src/cm3 or whatever > export CVSROOT=:ext:stefan at m3.elegosoft.com:/usr/cvs > cvs -z3 checkout cm3 > cd /usr/src/scripts/python > ./do-cm3-front.py buildship > > The very last step results in the error.> The other steps succeed.> > > Wherever you extracted the archive,> > Which archive?> > > did you put its bin directory in $PATH?> > Following the steps above, I now have this:> > $ find /usr/local/cm3> /usr/local/cm3> /usr/local/cm3/bin> /usr/local/cm3/bin/cm3> $ /usr/local/cm3/bin/cm3 -help> > Fatal Error: unable to locate configuration file, "cm3.cfg"> > $> > Prior to running do-cm3-front.py, I run:> export PATH=$PATH:/usr/local/cm3/bin> > > ie: are you running cm3 by full path or via $PATH?> > No idea. Whatever ./doc-m3-front.py buildship does, I guess.> > Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 4 23:57:09 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 4 Jan 2009 22:57:09 +0000 Subject: [M3devel] determing current processor as string In-Reply-To: <20090102202255.9177E10D5D00@birch.elegosoft.com> References: <20090102202255.9177E10D5D00@birch.elegosoft.com> Message-ID: Thoughts here? Does the processor need to be "friendly" and "precise" including stuff not knowable at compile time (386 vs. 486 vs. 586, etc.), or would just "PowerPC" or "PPC" suffice? This question affects the Posix code. The Posix code tries to fetch some data at runtime from uname, and if that fails it falls back to built in data. Besides that the data is used in an unlikely error path, we bother carrying the data for all systems, which afaik is completely unnecessary. Once I confirm, I'll have Quake generate just what is needed. Similarly, I think cm3 should have -print-host or somesuch. Then the platform probing in sysinfo.sh could probably all go away. (Except for my idea of /cm3/bin/cm3.sh that calls /cm3/bin/target/cm3.) There is more here than just the processor. So some runtime code would remain, even if the processor became hard coded at compile time. You know, there are a few models here: Use data at runtime asis. e.g. GetEnv("PROCESSOR_ARCHITECTURE") and be done. Does that work on CE? Build-in the data at compile time and be done. This requires possibly a revisit for every port, but simple. It goes obsolete in time, but not quietly, it'd be an error in the Quake code when a new platform is introduced. Or, if the string is just then automatically ports, no revisit. This doesn't have the concern "does it work on CE?" or of Posix vs. Win32 portability. Use data at runtime to pick among compile time data. This is the current approach and it goes obsolete quietly in time. As well, these functions are never even used that I can see. Remove them? Or assume they might be used outside the cm3 tree? (That's quite a "line" in decision makiing. It's so much nicer to assume/know you have all the relevant code visible and therefore can make any change, provided you fix the client code, vs. having to assume there is "anything" out there.) - Jay> Date: Fri, 2 Jan 2009 21:22:55 +0000> To: m3commit@> From: jkrell@> Subject: [M3commit] CVS Update: cm3> > 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> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 5 02:12:56 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jan 2009 12:12:56 +1100 Subject: [M3devel] determing current processor as string In-Reply-To: References: <20090102202255.9177E10D5D00@birch.elegosoft.com> Message-ID: <3C9A9351-C543-44CE-A76F-B2490C423641@cs.purdue.edu> As far as I am concerned I think PPC or PowerPC is sufficient, since the gcc-based backend figures out what it needs. Why would the front- ends need to know? Perhaps I am missing your point... On 5 Jan 2009, at 09:57, Jay wrote: > Thoughts here? > > > Does the processor need to be "friendly" and "precise" including stuff > not knowable at compile time (386 vs. 486 vs. 586, etc.), > or would just "PowerPC" or "PPC" suffice? > > > This question affects the Posix code. > > > The Posix code tries to fetch some data at runtime from uname, and > if that fails > it falls back to built in data. Besides that the data is used in an > unlikely > error path, we bother carrying the data for all systems, which afaik > is completely unnecessary. Once I confirm, I'll have Quake generate > just what is needed. > > > Similarly, I think cm3 should have -print-host or somesuch. > Then the platform probing in sysinfo.sh could probably all go away. > (Except for my idea of /cm3/bin/cm3.sh that calls /cm3/bin/target/ > cm3.) > > > There is more here than just the processor. > So some runtime code would remain, even if the processor > became hard coded at compile time. > > You know, there are a few models here: > > Use data at runtime asis. > e.g. GetEnv("PROCESSOR_ARCHITECTURE") and be done. > Does that work on CE? > > Build-in the data at compile time and be done. > This requires possibly a revisit for every port, but simple. > It goes obsolete in time, but not quietly, it'd be an error in > the Quake code > when a new platform is introduced. > Or, if the string is just then automatically ports, no > revisit. > This doesn't have the concern "does it work on CE?" or > of Posix vs. Win32 portability. > > Use data at runtime to pick among compile time data. > This is the current approach and it goes obsolete quietly in > time. > > > As well, these functions are never even used that I can see. > Remove them? > Or assume they might be used outside the cm3 tree? > > (That's quite a "line" in decision makiing. It's so much nicer > to assume/know you have all the relevant code visible and therefore > can make any change, provided you fix the client code, vs. having to > assume there is "anything" out there.) > > - Jay > > > > Date: Fri, 2 Jan 2009 21:22:55 +0000 > > To: m3commit@ > > From: jkrell@ > > Subject: [M3commit] CVS Update: cm3 > > > > 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 5 02:23:45 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 5 Jan 2009 01:23:45 +0000 Subject: [M3devel] determing current processor as string In-Reply-To: <3C9A9351-C543-44CE-A76F-B2490C423641@cs.purdue.edu> References: <20090102202255.9177E10D5D00@birch.elegosoft.com> <3C9A9351-C543-44CE-A76F-B2490C423641@cs.purdue.edu> Message-ID: Sorry, I had a tangent there. The main question was regiarding a library feature, not a compiler issue. libm3/src/os/POSIX/OSConfigPosix.m3 libm3/src/os/POSIX/OSConfig.i3 libm3/src/os/WIN32/OSConfigWin32.m3 libm3/src/os/WIN32/OSConfig.i3 The bulk of this code is never used in the cm3 tree anyway. The tangent was regarding "cm3 -dump-host" or such, though it's more complicated maybe. Some hosts are "biarch" or "multiarch". - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] determing current processor as stringDate: Mon, 5 Jan 2009 12:12:56 +1100 As far as I am concerned I think PPC or PowerPC is sufficient, since the gcc-based backend figures out what it needs. Why would the front-ends need to know? Perhaps I am missing your point... On 5 Jan 2009, at 09:57, Jay wrote: Thoughts here? Does the processor need to be "friendly" and "precise" including stuffnot knowable at compile time (386 vs. 486 vs. 586, etc.),or would just "PowerPC" or "PPC" suffice? This question affects the Posix code. The Posix code tries to fetch some data at runtime from uname, and if that failsit falls back to built in data. Besides that the data is used in an unlikelyerror path, we bother carrying the data for all systems, which afaikis completely unnecessary. Once I confirm, I'll have Quake generatejust what is needed. Similarly, I think cm3 should have -print-host or somesuch.Then the platform probing in sysinfo.sh could probably all go away.(Except for my idea of /cm3/bin/cm3.sh that calls /cm3/bin/target/cm3.) There is more here than just the processor.So some runtime code would remain, even if the processorbecame hard coded at compile time. You know, there are a few models here: Use data at runtime asis. e.g. GetEnv("PROCESSOR_ARCHITECTURE") and be done. Does that work on CE? Build-in the data at compile time and be done. This requires possibly a revisit for every port, but simple. It goes obsolete in time, but not quietly, it'd be an error in the Quake code when a new platform is introduced. Or, if the string is just then automatically ports, no revisit. This doesn't have the concern "does it work on CE?" or of Posix vs. Win32 portability. Use data at runtime to pick among compile time data. This is the current approach and it goes obsolete quietly in time. As well, these functions are never even used that I can see.Remove them?Or assume they might be used outside the cm3 tree? (That's quite a "line" in decision makiing. It's so much nicerto assume/know you have all the relevant code visible and thereforecan make any change, provided you fix the client code, vs. having toassume there is "anything" out there.) - Jay> Date: Fri, 2 Jan 2009 21:22:55 +0000> To: m3commit@> From: jkrell@> Subject: [M3commit] CVS Update: cm3> > 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> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 5 03:17:47 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jan 2009 13:17:47 +1100 Subject: [M3devel] determing current processor as string In-Reply-To: References: <20090102202255.9177E10D5D00@birch.elegosoft.com> <3C9A9351-C543-44CE-A76F-B2490C423641@cs.purdue.edu> Message-ID: <02B4C407-A359-4358-A77E-F8C93EF07380@cs.purdue.edu> Hmm. I'm not sure I know what all the implications are to have an opinion. On 5 Jan 2009, at 12:23, Jay wrote: > Sorry, I had a tangent there. > The main question was regiarding a library feature, not a compiler > issue. > > > libm3/src/os/POSIX/OSConfigPosix.m3 > libm3/src/os/POSIX/OSConfig.i3 > libm3/src/os/WIN32/OSConfigWin32.m3 > libm3/src/os/WIN32/OSConfig.i3 > > The bulk of this code is never used in the cm3 tree anyway. > > The tangent was regarding "cm3 -dump-host" or such, though it's more > complicated maybe. Some hosts are "biarch" or "multiarch". > > - Jay > > > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] determing current processor as string > Date: Mon, 5 Jan 2009 12:12:56 +1100 > > > As far as I am concerned I think PPC or PowerPC is sufficient, since > the gcc-based backend figures out what it needs. Why would the > front-ends need to know? Perhaps I am missing your point... > > On 5 Jan 2009, at 09:57, Jay wrote: > > Thoughts here? > > > Does the processor need to be "friendly" and "precise" including stuff > not knowable at compile time (386 vs. 486 vs. 586, etc.), > or would just "PowerPC" or "PPC" suffice? > > > This question affects the Posix code. > > > The Posix code tries to fetch some data at runtime from uname, and > if that fails > it falls back to built in data. Besides that the data is used in an > unlikely > error path, we bother carrying the data for all systems, which afaik > is completely unnecessary. Once I confirm, I'll have Quake generate > just what is needed. > > > Similarly, I think cm3 should have -print-host or somesuch. > Then the platform probing in sysinfo.sh could probably all go away. > (Except for my idea of /cm3/bin/cm3.sh that calls /cm3/bin/target/ > cm3.) > > > There is more here than just the processor. > So some runtime code would remain, even if the processor > became hard coded at compile time. > > You know, there are a few models here: > > Use data at runtime asis. > e.g. GetEnv("PROCESSOR_ARCHITECTURE") and be done. > Does that work on CE? > > Build-in the data at compile time and be done. > This requires possibly a revisit for every port, but simple. > It goes obsolete in time, but not quietly, it'd be an error in > the Quake code > when a new platform is introduced. > Or, if the string is just then automatically ports, no > revisit. > This doesn't have the concern "does it work on CE?" or > of Posix vs. Win32 portability. > > Use data at runtime to pick among compile time data. > This is the current approach and it goes obsolete quietly in > time. > > > As well, these functions are never even used that I can see. > Remove them? > Or assume they might be used outside the cm3 tree? > > (That's quite a "line" in decision makiing. It's so much nicer > to assume/know you have all the relevant code visible and therefore > can make any change, provided you fix the client code, vs. having to > assume there is "anything" out there.) > > - Jay > > > > Date: Fri, 2 Jan 2009 21:22:55 +0000 > > To: m3commit@ > > From: jkrell@ > > Subject: [M3commit] CVS Update: cm3 > > > > 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 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 5 06:01:49 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 5 Jan 2009 05:01:49 +0000 Subject: [M3devel] race conditions under loose memory models/ compiler/processor reordering In-Reply-To: <20090105043713.783AD10D5E5B@birch.elegosoft.com> References: <20090105043713.783AD10D5E5B@birch.elegosoft.com> Message-ID: This code is very likely buggy, due to compiler or processor reordering, in a multithread environment, which we have. Prior to my change, it only required multiple threads to have a race condition. We need some sort of "barriers", as they are called. The writes to null_done must "divide" the code before it and the code after it. While they appear to, in the source, this is not likely guaranteed by the compiler or processor. It doesn't matter in a single threaded environment, but they don't generally exist. Or maybe an ability to mark variables as "volatile". In C, a fairly portable overkill fix is to sprinkle around volatile, but that generally makes the code more deoptimized than necessary. Volatile inhibits any reads or writes of the variable from being optimized away, and generally any reordering. However not all reads/writes need such treatment. Imagine a function that initialized a global on-demand, and then return that global plus itself -- the addition need only fetch the value once. What to do? VAR null_done := FALSE; null_stat: Ustat.struct_stat; null_fd: INTEGER; PROCEDURE IsDevNull(READONLY statbuf: Ustat.struct_stat): BOOLEAN RAISES {} = VAR result: INTEGER; BEGIN IF NOT null_done THEN null_fd := Unix.open(M3toC.FlatTtoS("/dev/null"), Unix.O_RDONLY, Unix.Mrwrwrw); IF null_fd < 0 THEN; null_done := TRUE; RETURN FALSE ELSE result := Ustat.fstat(null_fd, ADR(null_stat)); EVAL Unix.close(null_fd); IF result # 0 THEN null_fd := -1 END END; null_done := TRUE; END; RETURN null_fd >= 0 AND statbuf.st_rdev = null_stat.st_rdev END IsDevNull; - Jay> Date: Mon, 5 Jan 2009 05:37:13 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > 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..)> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Jan 5 11:49:15 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 05 Jan 2009 02:49:15 -0800 Subject: [M3devel] TEXT & etc. In-Reply-To: Your message of "Wed, 31 Dec 2008 15:52:06 CST." <495BE986.3030806@bellsouth.net> Message-ID: <200901051049.n05AnFrS077134@camembert.async.caltech.edu> Martin Bishop writes: .... >> > >This is somewhat off-topic, but is there a reason why you use CM3 as >opposed to PM3? I was under the impression that PM3 was "dead" and most >of it merged with CM3. I take it you got it backwards? You're asking why I use PM3? I use the following versions of Modula-3: -- on FreeBSD4 : PM3 (I also have CM3 for testing) -- PPC_DARWIN : CM3 (PM3 doesn't work) -- LINUXLIBC6 : CM3 (ditto) -- Windows (2000, XP, 2003 Server) : PM3 (Klagenfurt, very old) My main development and production platform is FreeBSD4, so I mainly use PM3. I used to use Windows 2003 for production as well, but hopefully that is now ended, and I can stick with FreeBSD (I'll run it in VMware on the win2003 system rather than deal with Windows). I have been trying to switch to CM3 for years, but for various reasons I have never managed to pull it off. At one time, CM3 didn't work on Cygwin (I don't care about that anymore, I hope, see above), and because I extensively use Pickles and Network Objects, I really do have to switch the production systems simultaneously from PM3 to CM3. Otherwise, there are the performance issues I raised in my previous email. Much of the code I have does run faster (sometimes a lot faster) under PM3; see some of my previous emails to m3devel on this issue. Most of the reasons I find switching from PM3 to CM3 difficult have, it turns out, something to do with the change in implementation of TEXT. That's why I had a modification to the text package attached to the email you responded to. Mika P.S. Let me add my voice to those calling for easy-to-install Modula-3 systems. I think it is just far too difficult to install the system, on many architecture/OS combinations. I think I am now unable to get one that works right on PPC_DARWIN... the bootstrap on the site is too old to compile the latest sources and it still has GC bugs in it... I know this is easy for people like Tony who do it all the time, but I come to it about once every six months and every time I think "oh no, not this again"... From hosking at cs.purdue.edu Mon Jan 5 11:47:15 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jan 2009 21:47:15 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20090105072548.AB46610D5D2A@birch.elegosoft.com> References: <20090105072548.AB46610D5D2A@birch.elegosoft.com> Message-ID: According to the language spec: The following operations are primarily used for address arithmetic: ADR (VAR x: Any) : ADDRESS infix + (x: ADDRESS, y:INTEGER) : ADDRESS infix - (x: ADDRESS, y:INTEGER) : ADDRESS infix - (x,y: ADDRESS) : INTEGER ADR(x) is the address of the variable x. The actual argument must be a designator but need not be writable. On 5 Jan 2009, at 08:25, Jay Krell wrote: > 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.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Jan 5 12:23:19 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 05 Jan 2009 03:23:19 -0800 Subject: [M3devel] variations of waitpid..? In-Reply-To: Your message of "Fri, 02 Jan 2009 19:15:48 GMT." Message-ID: <200901051123.n05BNJVB078904@camembert.async.caltech.edu> This is all really inside Process.Wait, right? On user threads: I can report (from having tried it) that changing the Wait to a small number doesn't really work. Once you have yielded, as far as the OS is concerned, you've already lost (at least on FreeBSD). The only thing that really works is busy waiting. The "correct" thing to do on unix is to catch SIGCHLD (SIGCLD?)... I started coding this up once, but I'm not sure I shared my code with anyone? I think it was Tony that pointed out that it was unnecessary with pthreads... Mika P.S. Happy New Year, everyone. Jay writes: >--_e7fe8011-c1fe-42de-b7fb-8ae54fa172fc_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >I didn't read that well -- the deadlock risk in sysutils is not there. >The bad perf is probably. >=20 >=20 >To be clear (esp. for folks that might not already know about this=2C >I didn't know about until fairly recently)=2C there are two options: >=20 >=20 >waitpid(pid=2C flags =3D 0) >move along >=20 >=20 >or >while (waitpid(pid=2C flags =3D nohang) !=3D 0) > sleep(some value) >=20 >=20 >The second is what sysutils was doing=2C and works=2C doesn't deadlock=2C i= >s deoptimized. > m3core/libm3 did this for a long time as well. When I complained about per= >f=2C it was pointed out to me. >=20 >The first has deadlock potential with userthreads=2C but is ok and faster w= >ith kernel threads. >=20 >=20 >waitpid(flags =3D nohang =3D don't actually wait=2C just get the exit code= >=2C if there is one) is a way to quickly poll if a process has ended=2C and= > if so=2C get its exit code. In Win32 there are two seperate functions GetE= >xitCodeProcess and WaitForSingleObject or WaitForMultipleObjects ("waiting"= > is generalized across files=2C processes=2C sockets=2C files=2C threads=2C= > semaphores=2C mutexes=2C events and more..but not critical sections..only = >kernel objects). These have a bug too. One particular exit code is reserved= > to mean "the process is still running"=2C but that is easily avoided by us= >ing Wait first. I have seen code get confused by this though. Wait also acc= >epts a timeout=2C 32bit unsigned milliseconds=2C including 0 and infinity= >=2C so also can be used to poll. Win32 also defines the exit code to be 32b= >its=2C whereas Posix only allows for 8 bits which can be an interop problem= >. Perl on Win32 truncates exit codes to 8 bits=2C very bad. Unhandled excep= >tions end up as "large" exit codes. >=20 >Anyway... >=20 >The problem with the polling approach=2C at least part of the problem=2C is= > that if the child process isn't done when waitpid is first called=2C but f= >inishes before sleep(whatever value) ends=2C we will still sleep for the fu= >ll "whatever value". You only really want to sleep until the child process = >is done=2C and no longer. >=20 >=20 >Making just the first sleep shorter might be a good idea. >You know=2C to handle processes that are short-lived=2C but not "zero" live= >d. >("zero" being the amount of time it takes for the code to proceed from fork= >/exec to waitpid=2C surely much smaller than a small sleep() but longer tha= >n no sleep). >=20 >=20 >Calling just waitpid(flags =3D 0) could deadlock if=2C for example=2C a par= >ent thread is writing to a child's stdin=2C and the child won't finish unti= >l the parent has written all that it needs to. The parent and child process= >=2C er=2C other threads in the parent process=2C need to be allowed to run = >concurrently=2C for the sake of at least some reasonable scenarios. >=20 >With kernelthreads=2C the implementation of waitpid knows about threads and= > will itself=2C in a sense=2C do the poll/sleep=2C but not exactly that -- = >it won't sleep beyond the child process finishing. >=20 >=20 >Hopefully this makes sense and lets more folks understand the problem. >=20 >=20 >What you can do=2C of course=2C is like: >=20 >=20 >if kernelthreads > waitpid(flags =3D 0) >else > while (waitpid(flags =3D nohang) !=3D 0) > sleep >=20 >=20 >and that is basically what the code looks like now. >=20 >The part "if kernelthreads" I propose be "if SchedulerPosix.DoesWaitPidYiel= >d()" >though a really direct "if Thread or Scheduler.KernelThreads" might be reas= >onable. >Up to folks then to decide what that implies.. >=20 > - Jay> Date: Fri=2C 2 Jan 2009 11:27:24 +0100> From: wagner at elegosoft.com>= > To: m3devel at elegosoft.com> Subject: Re: [M3devel] variations of waitpid..?= >> > Quoting Tony Hosking :> > > If someone uses wait= >pid they get what they paid for.> It is so long ago that we wrote those sys= >utils routines...> They have only ever be used in simple command line utili= >ties (like cm3)> without much concurrency=2C I think. If there is potential= > for deadlocks> and bad performance=2C we should at least document that in = >the interfaces.> > I am not up-to-date wrt. the M3 system interfaces and th= >reads> implementation: is there a way for a thread to wait for the exit cod= >e> of another process without blocking other threads? If so=2C I'll adapt> = >the sysutils code... If not=2C can we introduce such an interface in> m3cor= >e/libm3?> > Olaf> > > On 1 Jan 2009=2C at 06:24=2C Jay wrote:> >> >>> >> Yo= >u mean=2C this function is easy to misuse?> >>> People who declare their ow= >n <*EXTERNAL*>> >> Like waitpid exposed from m3core?> >>> >> waitpid is alr= >eady easy to misuse=2C on a userthread system=2C leading > >> to possible (= >though I think rare) deadlock.> >> It is easy to misuse on pthreads=2C lead= > "just" to bad performance=2C > >> and in fact I believe cm3 is doing this= >=2C via sysutils.> >> This at least guides you between two patterns of use= >=2C and fix the > >> perf of cm3/sysutils.> >>> >> On a userthread system= >=2C waitpid(pid=2C flags =3D 0) waits for the child > >> process=2C with al= >l parent threads suspended.> >> Generally I doubt the child depends on pare= >nt threads progressing=2C > >> but=2C yeah=2C that could deadlock=2C like i= >f a parent thread is waiting > >> to a file or stdin of the child=2C or rea= >ding a child's stdout.> >>> >> The various uses do waitpid(pid=2C flags =3D= > nohang) and then sleep and > >> try again.> >>> >> pthreads just uses wait= >pid(pid=2C flags =3D 0) and all threads keep running> > > > -- > Olaf Wagne= >r -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C= > 13355 Berlin=2C Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 86= >9 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch=E4ftsf=FChrer: = >Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB = >77719 | USt-IdNr: DE163214194> = > >--_e7fe8011-c1fe-42de-b7fb-8ae54fa172fc_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >I didn't read that well -- the deadlock risk in sysutils is not there.
>The bad perf is probably.
> =3B
> =3B
>To be clear (esp. for folks that might not already know about this=2C
>I didn't know about until fairly recently)=2C there are two options:
> =3B
> =3B
>waitpid(pid=2C flags =3D 0)
>move along
> =3B
> =3B
>or
>while (waitpid(pid=2C flags =3D nohang) !=3D 0)
> =3B =3B sleep(some value)
> =3B
> =3B
>The second is what sysutils was doing=2C and works=2C doesn't deadlock=2C i= >s deoptimized.
> =3Bm3core/libm3 did this for a long time as well. When I complained ab= >out perf=2C it was pointed out to me.
> =3B
>The first has deadlock potential with userthreads=2C but is ok and faster w= >ith kernel threads.
> =3B
> =3B
>waitpid(flags =3D nohang =3D =3Bdon't actually wait=2C just get the exi= >t code=2C if there is one) is a way to quickly poll if a process has ended= >=2C and if so=2C get its exit code. In Win32 there are two seperate functio= >ns GetExitCodeProcess and WaitForSingleObject or WaitForMultipleObjects ("w= >aiting" is generalized across files=2C processes=2C sockets=2C files=2C thr= >eads=2C semaphores=2C mutexes=2C events and more..but not critical sections= >..only kernel objects). These have a bug too. One particular exit code is r= >eserved to mean "the process is still running"=2C but that is easily avoide= >d by using Wait first. I have seen code get confused by this though. Wait a= >lso accepts a timeout=2C 32bit unsigned milliseconds=2C including 0 and inf= >inity=2C so also can be used to poll. Win32 also defines the exit code to b= >e 32bits=2C whereas Posix only allows for 8 bits which can be an interop pr= >oblem. Perl on Win32 truncates exit codes to 8 bits=2C very bad. Unhandled = >exceptions end up as "large" exit codes.
> =3B
>Anyway...
> =3B
>The problem with the polling approach=2C at least part of the problem=2C is= > that if the child process isn't done when waitpid is first called=2C but f= >inishes before sleep(whatever value) ends=2C we will still sleep for the fu= >ll "whatever value". You only really want to sleep until the child process = >is done=2C and no longer.
> =3B
> =3B
>Making just the first sleep shorter might be a good idea.
>You know=2C to handle processes that are short-lived=2C but not "zero" live= >d.
>("zero" being the amount of time it takes for the code to proceed from fork= >/exec to waitpid=2C surely much smaller than a small sleep() but longer tha= >n no sleep).
> =3B
> =3B
>Calling just waitpid(flags =3D 0) could deadlock if=2C for example=2C a par= >ent thread is writing to a child's stdin=2C and the child won't finish unti= >l the parent has written all that it needs to. The parent and child process= >=2C er=2C other threads in the parent process=2C need to be allowed to run = >concurrently=2C for the sake of at least some reasonable scenarios.
> =3B
>With kernelthreads=2C the implementation of waitpid knows about threads and= > will itself=2C in a sense=2C do the poll/sleep=2C but not exactly that -- = >it won't sleep beyond the child process finishing.
> =3B
> =3B
>Hopefully this makes sense and lets more folks understand the problem.
> =3B
> =3B
>What you can do=2C of course=2C is like:
> =3B
> =3B
>if kernelthreads
> =3B waitpid(flags =3D 0)
>else
> =3B while (waitpid(flags =3D nohang) !=3D 0)
> =3B =3Bsleep
> =3B
> =3B
>and that is basically what the code looks like now.
> =3B
>The part "if kernelthreads" I propose be "if SchedulerPosix.DoesWaitPidYiel= >d()"
>though a really direct "if Thread or Scheduler.KernelThreads" might be reas= >onable.
>Up to folks then to decide what that implies..
> =3B
> =3B- Jay


>=3B Date: Fri=2C 2 Jan 2009 11:27:24 +0100
&= >gt=3B From: wagner at elegosoft.com
>=3B To: m3devel at elegosoft.com
>= >=3B Subject: Re: [M3devel] variations of waitpid..?
>=3B
>=3B Qu= >oting Tony Hosking <=3Bhosking at cs.purdue.edu>=3B:
>=3B
>=3B = >>=3B If someone uses waitpid they get what they paid for.
>=3B It is= > so long ago that we wrote those sysutils routines...
>=3B They have o= >nly ever be used in simple command line utilities (like cm3)
>=3B with= >out much concurrency=2C I think. If there is potential for deadlocks
>= >=3B and bad performance=2C we should at least document that in the interfac= >es.
>=3B
>=3B I am not up-to-date wrt. the M3 system interfaces = >and threads
>=3B implementation: is there a way for a thread to wait f= >or the exit code
>=3B of another process without blocking other thread= >s? If so=2C I'll adapt
>=3B the sysutils code... If not=2C can we intr= >oduce such an interface in
>=3B m3core/libm3?
>=3B
>=3B Ola= >f
>=3B
>=3B >=3B On 1 Jan 2009=2C at 06:24=2C Jay wrote:
&g= >t=3B >=3B
>=3B >=3B>=3B
>=3B >=3B>=3B You mean=2C this = >function is easy to misuse?
>=3B >=3B>=3B>=3B People who declare= > their own <=3B*EXTERNAL*>=3B
>=3B >=3B>=3B Like waitpid expos= >ed from m3core?
>=3B >=3B>=3B
>=3B >=3B>=3B waitpid is al= >ready easy to misuse=2C on a userthread system=2C leading
>=3B >=3B= >>=3B to possible (though I think rare) deadlock.
>=3B >=3B>=3B I= >t is easy to misuse on pthreads=2C lead "just" to bad performance=2C
&g= >t=3B >=3B>=3B and in fact I believe cm3 is doing this=2C via sysutils.<= >BR>>=3B >=3B>=3B This at least guides you between two patterns of use= >=2C and fix the
>=3B >=3B>=3B perf of cm3/sysutils.
>=3B >= >=3B>=3B
>=3B >=3B>=3B On a userthread system=2C waitpid(pid=2C f= >lags =3D 0) waits for the child
>=3B >=3B>=3B process=2C with all= > parent threads suspended.
>=3B >=3B>=3B Generally I doubt the chi= >ld depends on parent threads progressing=2C
>=3B >=3B>=3B but=2C = >yeah=2C that could deadlock=2C like if a parent thread is waiting
>= >=3B >=3B>=3B to a file or stdin of the child=2C or reading a child's st= >dout.
>=3B >=3B>=3B
>=3B >=3B>=3B The various uses do wai= >tpid(pid=2C flags =3D nohang) and then sleep and
>=3B >=3B>=3B tr= >y again.
>=3B >=3B>=3B
>=3B >=3B>=3B pthreads just uses w= >aitpid(pid=2C flags =3D 0) and all threads keep running
>=3B
>= >=3B
>=3B
>=3B --
>=3B Olaf Wagner -- elego Software Solut= >ions GmbH
>=3B Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C= > Germany
>=3B phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: = >+49 30 23 45 86 95
>=3B http://www.elegosoft.com | Gesch=E4ftsf=FChrer= >: Olaf Wagner | Sitz: Berlin
>=3B Handelregister: Amtsgericht Charlott= >enburg HRB 77719 | USt-IdNr: DE163214194
>=3B

>= > >--_e7fe8011-c1fe-42de-b7fb-8ae54fa172fc_-- From jay.krell at cornell.edu Mon Jan 5 19:00:43 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 5 Jan 2009 18:00:43 +0000 Subject: [M3devel] variations of waitpid..? In-Reply-To: <200901051123.n05BNJVB078904@camembert.async.caltech.edu> References: Your message of "Fri, 02 Jan 2009 19:15:48 GMT." <200901051123.n05BNJVB078904@camembert.async.caltech.edu> Message-ID: Yes, it is "all" inside Process.Wait, except that sysutils implements this stuff itself, so it is also in there. You can consider that there are two implementations of Process.Wait. Correct, no need on pthreads or NT -- the code has two different modes, "slow" and "fast". Or rather, "slow posix", "fast posix", and "fast NT". The problem was, the posix code didn't know how to chose, so was just always "slow". Imho this just one more reason to never use user threads but I seem to be the only one. > the Wait to a small number doesn't really work. Once you have> yielded, as far as the OS is concerned, you've already lost (at> least on FreeBSD). The only thing that really works is busy waiting. I don't understand. I mean, well, ignoring something for a sec, you must yield. My suggestion, in a commit comment, that maybe the first wait should be much shorter. You know, the sequence is like: fork/exec run through a /little/ bit of code label check if process done if not "sleep" (actual a call into the m3 scheduler which will run other threads goto label A point is that the first check is going to VERY soon after the process starts. The child would have to be VERY quick for the first check to find it is done. Perhaps it is merely "fairly quick", but not "VERY quick" we could win by making just the first wait smaller. You know, the inefficiency here I believe is the time the child takes to run modulo the sleep duration, and then divided by child duration. You want to find the child is done as soon as possible after it is actually done. You don't want to keep waiting. For long running children, the inefficiency is less. For short running children, the inefficiency is likely more. Shrinking the wait has a positive and negative affect on efficiency. You know, making it very small reduces the inefficiency here, but adds inefficiency because we'd spend more time merely checking the process status. Another idea is to "hang" (be fast) if the program is single threaded, however, "single threaded" is nearly impossible to practically discover, since there will always be worker threads, just that they are not dependent or depended-upon the child process. You know, there is the garbage collector thread, at least. Ok, what I was ignoring is your suggestion of handling sigchild. I'll try to look into that, sounds promising. But again, if you just use pthreads, no problem. Again, the previous code was even slow on pthreads, but should be better now. Again, if you just ignore user threads, no longer a problem. - Jay> To: jay.krell at cornell.edu> Date: Mon, 5 Jan 2009 03:23:19 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] variations of waitpid..?> > > This is all really inside Process.Wait, right?> > On user threads: I can report (from having tried it) that changing> the Wait to a small number doesn't really work. Once you have> yielded, as far as the OS is concerned, you've already lost (at> least on FreeBSD). The only thing that really works is busy waiting.> > The "correct" thing to do on unix is to catch SIGCHLD (SIGCLD?)...> > I started coding this up once, but I'm not sure I shared my code> with anyone? I think it was Tony that pointed out that it was> unnecessary with pthreads...> > Mika> > P.S. Happy New Year, everyone.> > > > Jay writes:> >--_e7fe8011-c1fe-42de-b7fb-8ae54fa172fc_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >I didn't read that well -- the deadlock risk in sysutils is not there.> >The bad perf is probably.> >=20> >=20> >To be clear (esp. for folks that might not already know about this=2C> >I didn't know about until fairly recently)=2C there are two options:> >=20> >=20> >waitpid(pid=2C flags =3D 0)> >move along> >=20> >=20> >or> >while (waitpid(pid=2C flags =3D nohang) !=3D 0)> > sleep(some value)> >=20> >=20> >The second is what sysutils was doing=2C and works=2C doesn't deadlock=2C i=> >s deoptimized.> > m3core/libm3 did this for a long time as well. When I complained about per=> >f=2C it was pointed out to me.> >=20> >The first has deadlock potential with userthreads=2C but is ok and faster w=> >ith kernel threads.> >=20> >=20> >waitpid(flags =3D nohang =3D don't actually wait=2C just get the exit code=> >=2C if there is one) is a way to quickly poll if a process has ended=2C and=> > if so=2C get its exit code. In Win32 there are two seperate functions GetE=> >xitCodeProcess and WaitForSingleObject or WaitForMultipleObjects ("waiting"=> > is generalized across files=2C processes=2C sockets=2C files=2C threads=2C=> > semaphores=2C mutexes=2C events and more..but not critical sections..only => >kernel objects). These have a bug too. One particular exit code is reserved=> > to mean "the process is still running"=2C but that is easily avoided by us=> >ing Wait first. I have seen code get confused by this though. Wait also acc=> >epts a timeout=2C 32bit unsigned milliseconds=2C including 0 and infinity=> >=2C so also can be used to poll. Win32 also defines the exit code to be 32b=> >its=2C whereas Posix only allows for 8 bits which can be an interop problem=> >. Perl on Win32 truncates exit codes to 8 bits=2C very bad. Unhandled excep=> >tions end up as "large" exit codes.> >=20> >Anyway...> >=20> >The problem with the polling approach=2C at least part of the problem=2C is=> > that if the child process isn't done when waitpid is first called=2C but f=> >inishes before sleep(whatever value) ends=2C we will still sleep for the fu=> >ll "whatever value". You only really want to sleep until the child process => >is done=2C and no longer.> >=20> >=20> >Making just the first sleep shorter might be a good idea.> >You know=2C to handle processes that are short-lived=2C but not "zero" live=> >d.> >("zero" being the amount of time it takes for the code to proceed from fork=> >/exec to waitpid=2C surely much smaller than a small sleep() but longer tha=> >n no sleep).> >=20> >=20> >Calling just waitpid(flags =3D 0) could deadlock if=2C for example=2C a par=> >ent thread is writing to a child's stdin=2C and the child won't finish unti=> >l the parent has written all that it needs to. The parent and child process=> >=2C er=2C other threads in the parent process=2C need to be allowed to run => >concurrently=2C for the sake of at least some reasonable scenarios.> >=20> >With kernelthreads=2C the implementation of waitpid knows about threads and=> > will itself=2C in a sense=2C do the poll/sleep=2C but not exactly that -- => >it won't sleep beyond the child process finishing.> >=20> >=20> >Hopefully this makes sense and lets more folks understand the problem.> >=20> >=20> >What you can do=2C of course=2C is like:> >=20> >=20> >if kernelthreads> > waitpid(flags =3D 0)> >else> > while (waitpid(flags =3D nohang) !=3D 0)> > sleep> >=20> >=20> >and that is basically what the code looks like now.> >=20> >The part "if kernelthreads" I propose be "if SchedulerPosix.DoesWaitPidYiel=> >d()"> >though a really direct "if Thread or Scheduler.KernelThreads" might be reas=> >onable.> >Up to folks then to decide what that implies..> >=20> > - Jay> Date: Fri=2C 2 Jan 2009 11:27:24 +0100> From: wagner at elegosoft.com>=> > To: m3devel at elegosoft.com> Subject: Re: [M3devel] variations of waitpid..?=> >> > Quoting Tony Hosking :> > > If someone uses wait=> >pid they get what they paid for.> It is so long ago that we wrote those sys=> >utils routines...> They have only ever be used in simple command line utili=> >ties (like cm3)> without much concurrency=2C I think. If there is potential=> > for deadlocks> and bad performance=2C we should at least document that in => >the interfaces.> > I am not up-to-date wrt. the M3 system interfaces and th=> >reads> implementation: is there a way for a thread to wait for the exit cod=> >e> of another process without blocking other threads? If so=2C I'll adapt> => >the sysutils code... If not=2C can we introduce such an interface in> m3cor=> >e/libm3?> > Olaf> > > On 1 Jan 2009=2C at 06:24=2C Jay wrote:> >> >>> >> Yo=> >u mean=2C this function is easy to misuse?> >>> People who declare their ow=> >n <*EXTERNAL*>> >> Like waitpid exposed from m3core?> >>> >> waitpid is alr=> >eady easy to misuse=2C on a userthread system=2C leading > >> to possible (=> >though I think rare) deadlock.> >> It is easy to misuse on pthreads=2C lead=> > "just" to bad performance=2C > >> and in fact I believe cm3 is doing this=> >=2C via sysutils.> >> This at least guides you between two patterns of use=> >=2C and fix the > >> perf of cm3/sysutils.> >>> >> On a userthread system=> >=2C waitpid(pid=2C flags =3D 0) waits for the child > >> process=2C with al=> >l parent threads suspended.> >> Generally I doubt the child depends on pare=> >nt threads progressing=2C > >> but=2C yeah=2C that could deadlock=2C like i=> >f a parent thread is waiting > >> to a file or stdin of the child=2C or rea=> >ding a child's stdout.> >>> >> The various uses do waitpid(pid=2C flags =3D=> > nohang) and then sleep and > >> try again.> >>> >> pthreads just uses wait=> >pid(pid=2C flags =3D 0) and all threads keep running> > > > -- > Olaf Wagne=> >r -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C=> > 13355 Berlin=2C Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 86=> >9 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch=E4ftsf=FChrer: => >Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB => >77719 | USt-IdNr: DE163214194> => >> >--_e7fe8011-c1fe-42de-b7fb-8ae54fa172fc_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >> >I didn't read that well -- the deadlock risk in sysutils is not there.
> >The bad perf is probably.
> > =3B
> > =3B
> >To be clear (esp. for folks that might not already know about this=2C
> >I didn't know about until fairly recently)=2C there are two options:
> > =3B
> > =3B
> >waitpid(pid=2C flags =3D 0)
> >move along
> > =3B
> > =3B
> >or
> >while (waitpid(pid=2C flags =3D nohang) !=3D 0)
> > =3B =3B sleep(some value)
> > =3B
> > =3B
> >The second is what sysutils was doing=2C and works=2C doesn't deadlock=2C i=> >s deoptimized.
> > =3Bm3core/libm3 did this for a long time as well. When I complained ab=> >out perf=2C it was pointed out to me.
> > =3B
> >The first has deadlock potential with userthreads=2C but is ok and faster w=> >ith kernel threads.
> > =3B
> > =3B
> >waitpid(flags =3D nohang =3D =3Bdon't actually wait=2C just get the exi=> >t code=2C if there is one) is a way to quickly poll if a process has ended=> >=2C and if so=2C get its exit code. In Win32 there are two seperate functio=> >ns GetExitCodeProcess and WaitForSingleObject or WaitForMultipleObjects ("w=> >aiting" is generalized across files=2C processes=2C sockets=2C files=2C thr=> >eads=2C semaphores=2C mutexes=2C events and more..but not critical sections=> >..only kernel objects). These have a bug too. One particular exit code is r=> >eserved to mean "the process is still running"=2C but that is easily avoide=> >d by using Wait first. I have seen code get confused by this though. Wait a=> >lso accepts a timeout=2C 32bit unsigned milliseconds=2C including 0 and inf=> >inity=2C so also can be used to poll. Win32 also defines the exit code to b=> >e 32bits=2C whereas Posix only allows for 8 bits which can be an interop pr=> >oblem. Perl on Win32 truncates exit codes to 8 bits=2C very bad. Unhandled => >exceptions end up as "large" exit codes.
> > =3B
> >Anyway...
> > =3B
> >The problem with the polling approach=2C at least part of the problem=2C is=> > that if the child process isn't done when waitpid is first called=2C but f=> >inishes before sleep(whatever value) ends=2C we will still sleep for the fu=> >ll "whatever value". You only really want to sleep until the child process => >is done=2C and no longer.
> > =3B
> > =3B
> >Making just the first sleep shorter might be a good idea.
> >You know=2C to handle processes that are short-lived=2C but not "zero" live=> >d.
> >("zero" being the amount of time it takes for the code to proceed from fork=> >/exec to waitpid=2C surely much smaller than a small sleep() but longer tha=> >n no sleep).
> > =3B
> > =3B
> >Calling just waitpid(flags =3D 0) could deadlock if=2C for example=2C a par=> >ent thread is writing to a child's stdin=2C and the child won't finish unti=> >l the parent has written all that it needs to. The parent and child process=> >=2C er=2C other threads in the parent process=2C need to be allowed to run => >concurrently=2C for the sake of at least some reasonable scenarios.
> > =3B
> >With kernelthreads=2C the implementation of waitpid knows about threads and=> > will itself=2C in a sense=2C do the poll/sleep=2C but not exactly that -- => >it won't sleep beyond the child process finishing.
> > =3B
> > =3B
> >Hopefully this makes sense and lets more folks understand the problem.
> > =3B
> > =3B
> >What you can do=2C of course=2C is like:
> > =3B
> > =3B
> >if kernelthreads
> > =3B waitpid(flags =3D 0)
> >else
> > =3B while (waitpid(flags =3D nohang) !=3D 0)
> > =3B =3Bsleep
> > =3B
> > =3B
> >and that is basically what the code looks like now.
> > =3B
> >The part "if kernelthreads" I propose be "if SchedulerPosix.DoesWaitPidYiel=> >d()"
> >though a really direct "if Thread or Scheduler.KernelThreads" might be reas=> >onable.
> >Up to folks then to decide what that implies..
> > =3B
> > =3B- Jay


>=3B Date: Fri=2C 2 Jan 2009 11:27:24 +0100
&=> >gt=3B From: wagner at elegosoft.com
>=3B To: m3devel at elegosoft.com
>=> >=3B Subject: Re: [M3devel] variations of waitpid..?
>=3B
>=3B Qu=> >oting Tony Hosking <=3Bhosking at cs.purdue.edu>=3B:
>=3B
>=3B => >>=3B If someone uses waitpid they get what they paid for.
>=3B It is=> > so long ago that we wrote those sysutils routines...
>=3B They have o=> >nly ever be used in simple command line utilities (like cm3)
>=3B with=> >out much concurrency=2C I think. If there is potential for deadlocks
>=> >=3B and bad performance=2C we should at least document that in the interfac=> >es.
>=3B
>=3B I am not up-to-date wrt. the M3 system interfaces => >and threads
>=3B implementation: is there a way for a thread to wait f=> >or the exit code
>=3B of another process without blocking other thread=> >s? If so=2C I'll adapt
>=3B the sysutils code... If not=2C can we intr=> >oduce such an interface in
>=3B m3core/libm3?
>=3B
>=3B Ola=> >f
>=3B
>=3B >=3B On 1 Jan 2009=2C at 06:24=2C Jay wrote:
&g=> >t=3B >=3B
>=3B >=3B>=3B
>=3B >=3B>=3B You mean=2C this => >function is easy to misuse?
>=3B >=3B>=3B>=3B People who declare=> > their own <=3B*EXTERNAL*>=3B
>=3B >=3B>=3B Like waitpid expos=> >ed from m3core?
>=3B >=3B>=3B
>=3B >=3B>=3B waitpid is al=> >ready easy to misuse=2C on a userthread system=2C leading
>=3B >=3B=> >>=3B to possible (though I think rare) deadlock.
>=3B >=3B>=3B I=> >t is easy to misuse on pthreads=2C lead "just" to bad performance=2C
&g=> >t=3B >=3B>=3B and in fact I believe cm3 is doing this=2C via sysutils.<=> >BR>>=3B >=3B>=3B This at least guides you between two patterns of use=> >=2C and fix the
>=3B >=3B>=3B perf of cm3/sysutils.
>=3B >=> >=3B>=3B
>=3B >=3B>=3B On a userthread system=2C waitpid(pid=2C f=> >lags =3D 0) waits for the child
>=3B >=3B>=3B process=2C with all=> > parent threads suspended.
>=3B >=3B>=3B Generally I doubt the chi=> >ld depends on parent threads progressing=2C
>=3B >=3B>=3B but=2C => >yeah=2C that could deadlock=2C like if a parent thread is waiting
>=> >=3B >=3B>=3B to a file or stdin of the child=2C or reading a child's st=> >dout.
>=3B >=3B>=3B
>=3B >=3B>=3B The various uses do wai=> >tpid(pid=2C flags =3D nohang) and then sleep and
>=3B >=3B>=3B tr=> >y again.
>=3B >=3B>=3B
>=3B >=3B>=3B pthreads just uses w=> >aitpid(pid=2C flags =3D 0) and all threads keep running
>=3B
>=> >=3B
>=3B
>=3B --
>=3B Olaf Wagner -- elego Software Solut=> >ions GmbH
>=3B Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C=> > Germany
>=3B phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: => >+49 30 23 45 86 95
>=3B http://www.elegosoft.com | Gesch=E4ftsf=FChrer=> >: Olaf Wagner | Sitz: Berlin
>=3B Handelregister: Amtsgericht Charlott=> >enburg HRB 77719 | USt-IdNr: DE163214194
>=3B

> >=> >> >--_e7fe8011-c1fe-42de-b7fb-8ae54fa172fc_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 5 19:04:22 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 5 Jan 2009 18:04:22 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090105072548.AB46610D5D2A@birch.elegosoft.com> Message-ID: Reading the code ...there is a command line option to the compiler to apparently make it: ADR (x: T) : UNTRACED REF T. Good?bad?better?different? Seems more type safe. I haven't tried it. - Jay From: hosking at cs.purdue.eduTo: jkrell at elego.deDate: Mon, 5 Jan 2009 21:47:15 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3According to the language spec: The following operations are primarily used for address arithmetic: ADR (VAR x: Any) : ADDRESS infix + (x: ADDRESS, y:INTEGER) : ADDRESS infix - (x: ADDRESS, y:INTEGER) : ADDRESS infix - (x,y: ADDRESS) : INTEGER ADR(x) is the address of the variable x. The actual argument must be a designator but need not be writable. On 5 Jan 2009, at 08:25, Jay Krell wrote: CVSROOT: /usr/cvsChanges by: jkrell at birch. 09/01/05 08:25:48Modified 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.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Jan 5 19:18:57 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 05 Jan 2009 10:18:57 -0800 Subject: [M3devel] variations of waitpid..? In-Reply-To: Your message of "Mon, 05 Jan 2009 18:00:43 GMT." Message-ID: <200901051818.n05IIviI093998@camembert.async.caltech.edu> Jay writes: >--_5fe387c0-3f5b-4882-b57b-b7299ded497e_ ... > much shorter. >You know=2C the sequence is like: > fork/exec=20 > run through a /little/ bit of code=20 > label=20 > check if process done=20 > if not > "sleep" (actual a call into the m3 scheduler which will run other thre= >ads=20 > goto label=20 >=20 ... You're right, but under user threads, here's what can (and does) happen, e.g., in the compiler itself: - Start child process - Call Process.Wait, which... - Calls Thread.Pause(somesmallnumber) There are no runnable threads, so the runtime yields the processor. I think it calls Unix's sleep? The OS scheduler then schedules the process at a very low priority. In most OSes, processes waiting for I/O have the highest priority, and processes sleeping have the lowest. So you've gone from waiting for a process to exit, at high priority, to sleeping, at very low priority. The OS then takes its time to get around to waking you up again. This is my theory of what happens on FreeBSD anyhow. It is the way I describe my experimental result that you can change that sleep to anything and it doesn't run noticeably faster than with 0.1d0. Getting rid of the Thread.Pause speeds things up substantially :-) Mika From jay.krell at cornell.edu Mon Jan 5 20:04:16 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 5 Jan 2009 19:04:16 +0000 Subject: [M3devel] variations of waitpid..? In-Reply-To: <200901051818.n05IIviI093998@camembert.async.caltech.edu> References: Your message of "Mon, 05 Jan 2009 18:00:43 GMT." <200901051818.n05IIviI093998@camembert.async.caltech.edu> Message-ID: > - Start child process > - Call Process.Wait, which... > - Calls Thread.Pause(somesmallnumber) There is a call to waitpid before the Thread.Pause. If the process finishes /very/ quickly, probably never happens, no pause/sleep. > There are no runnable threads, so the runtime yields the processor. > I think it calls Unix's sleep? Agreed probably no runnable threads typically and sleep(). Perhaps the scheduler knows that none of the threads will become runnable, but I doubt it. > The OS scheduler then schedules the process at a very low priority. > In most OSes, processes waiting for I/O have the highest priority, > and processes sleeping have the lowest. So you've gone from waiting > for a process to exit, at high priority, to sleeping, at very low > priority. The OS then takes its time to get around to waking you > up again. Hm. Why does sleep() imply anything about priority? Why doesn't it mean "don't run at all for a certain duration, and then when the duration elapses, resume running ASAP, with the same priority as it has before sleeping"? Surely "not running at all for a certain duration" does not mean "low priority"? There is a problem -- it will wait the entire duration, even if the process exists half way through. > Getting rid of the Thread.Pause speeds things up substantially :-) But it can also cause damage. If there is a dependency between the child process and other parent threads. Often there is not, sometimes there is. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 5 21:27:50 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 5 Jan 2009 20:27:50 +0000 Subject: [M3devel] SIG_DFL, SIG_IGN duplication (and RTSignal.m3 duplication) Message-ID: SIG_DFL and SIG_IGN are effectively duplicated twice for every platform. Once in Usignal.i3, once in RTSignal.m3. 1) The duplication in RTSignal.m3 I would think wouldn't be needed if module initialization occurs in a "correct" order. ? 2) The duplication in RTSignal.m3 could be eliminated if all platforms defined Usiginal.SIG_DFL, SIG_IGN, like Darwin and Solaris do -- a constant integer that you must LOOPHOLE instead of a correctly type variable that gets initialized (the variables have multiple correct types besides, due to signal handlers having at least three possible prototypes, ANSI C, BSD, and POSIX). Perhaps Usignal could provide both a constant integer for folks to LOOPHOLE, and a typed initialized variable. Since both sides are system-dependent, there isn't a "disconnect", porters just have to check both copies. Apparently the values are always the same across all platforms, but that might be a coincidence of sorts. I rather suspect in the old days, people copied C header content around a lot to other C code, leading to values like becoming impossible to change, including constants and types, not just the arguably "easier" function prototypes. Anyway, my inclination is rewrite the small number of clients in C, fixing both this, and reducing the cloned headers. -- As well stopping the duplication of RTSignal.m3, of which there are 37 nearly identical copies, or roughly 3 variants duplicated 37 times (again, ANSI, BSD, POSIX). Other clients I see are: C:\dev2\cm3.2\m3-libs\m3core\src\float\DS3100\FloatMode.m3(360): ELSIF (p = Usignal.SIG_DFL) THENC:\dev2\cm3.2\m3-libs\m3core\src\float\IRIX5\FloatMode.m3(361): ELSIF (p = Usignal.SIG_DFL) THENC:\dev2\cm3.2\m3-libs\m3core\src\float\DS3100\FloatMode.m3(358): IF (p = Usignal.SIG_IGN) THENC:\dev2\cm3.2\m3-libs\m3core\src\float\IRIX5\FloatMode.m3(359): IF (p = Usignal.SIG_IGN) THEN but these are dead for multiple reasons. The platforms are dead/dormant, and platform-specific FloatMode is dead in general, though perhaps should not be. (I do have a machine running Irix so hope to get that building/working before much longer...DS3100 no.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinbishop at bellsouth.net Tue Jan 6 21:50:56 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Tue, 06 Jan 2009 14:50:56 -0600 Subject: [M3devel] Widechars Message-ID: <4963C430.9020804@bellsouth.net> I'm playing around with WIDECHARS, and having some trouble. VAR wide := ARRAY OF WIDECHAR {'\x304A', '\x306F', '\x3088', '\x3046'}; s := Text.FromWideChars(wide); I get these errors from the compiler: "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: syntax error: missing '}' (4) "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal 9 errors encountered It seems like it's reading '\x304A' as '\x30' (which is why it says "syntax error: missing '}' (4)") Do I need some special literal letter or something? From roland.illig at gmx.de Tue Jan 6 22:31:28 2009 From: roland.illig at gmx.de (Roland Illig) Date: Tue, 06 Jan 2009 22:31:28 +0100 Subject: [M3devel] Widechars In-Reply-To: <4963C430.9020804@bellsouth.net> References: <4963C430.9020804@bellsouth.net> Message-ID: <4963CDB0.9020500@gmx.de> Martin Bishop schrieb: > I'm playing around with WIDECHARS, and having some trouble. > > VAR wide := ARRAY OF WIDECHAR {'\x304A', '\x306F', '\x3088', '\x3046'}; > s := Text.FromWideChars(wide); >From what I just read in the CM3 compiler's source code, it only understands simple octal character escape sequences, and even those return a CHAR, not a WIDECHAR. So the question that remains is: What is the most readable, shortest form of encoding a WIDECHAR literal, or a WIDETEXT? Roland From hendrik at topoi.pooq.com Wed Jan 7 16:33:56 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 7 Jan 2009 10:33:56 -0500 Subject: [M3devel] Widechars In-Reply-To: <4963CDB0.9020500@gmx.de> References: <4963C430.9020804@bellsouth.net> <4963CDB0.9020500@gmx.de> Message-ID: <20090107153356.GA608@topoi.pooq.com> On Tue, Jan 06, 2009 at 10:31:28PM +0100, Roland Illig wrote: > Martin Bishop schrieb: > > I'm playing around with WIDECHARS, and having some trouble. > > > > VAR wide := ARRAY OF WIDECHAR {'\x304A', '\x306F', '\x3088', '\x3046'}; > > s := Text.FromWideChars(wide); > > >From what I just read in the CM3 compiler's source code, it only > understands simple octal character escape sequences, and even those > return a CHAR, not a WIDECHAR. > > So the question that remains is: What is the most readable, shortest > form of encoding a WIDECHAR literal, or a WIDETEXT? Most readable, probably UTF-8. > > Roland From dabenavidesd at yahoo.es Wed Jan 7 06:08:34 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 7 Jan 2009 05:08:34 +0000 (GMT) Subject: [M3devel] Widechars Message-ID: <601806.14495.qm@web28604.mail.ukl.yahoo.com> Hi all, I believe you need to declare wide VAR? with fixed size or create it as a Reference type ? VAR wide := ARRAY [1..4] OF WIDECHAR {'\x304A', '\x306F', '\x3088', '\x3046'};or arrWideChar:= NEW (REF ARRAY OF WIDECHAR, 4); arrWideChar[0]:='\x304A'; .... I'm not sure if you can do this, would be interesting to know: arrWideChar:= NEW (REF ARRAY OF WIDECHAR{'\x304A', '\x306F', '\x3088', '\x3046'} ); See further explanations on:? http://opencm3.net/doc/tutorial/m3/m3_54.html#SEC54 Also the language definition, http://opencm3.net/doc/reference/arrays.html Hope that helps --- El mar, 6/1/09, Martin Bishop wrote: De: Martin Bishop Asunto: [M3devel] Widechars Para: m3devel at elegosoft.com Fecha: martes, 6 enero, 2009 3:50 I'm playing around with WIDECHARS, and having some trouble. VAR wide := ARRAY OF WIDECHAR {'\x304A', '\x306F', '\x3088', '\x3046'}; s := Text.FromWideChars(wide); I get these errors from the compiler: "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: syntax error: missing '}' (4) "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal 9 errors encountered It seems like it's reading '\x304A' as '\x30' (which is why it says "syntax error: missing '}' (4)") Do I need some special literal letter or something? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Wed Jan 7 04:25:08 2009 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Tue, 06 Jan 2009 21:25:08 -0600 Subject: [M3devel] Widechars In-Reply-To: <4963C430.9020804@bellsouth.net> References: <4963C430.9020804@bellsouth.net> Message-ID: <49642094.7040400@wichita.edu> Literals of type WIDECHAR are written, e.g. W'\x304A', note the 'W'. It makes them have type WIDECHAR and also enables the 16-bit escape sequences you are using. If it is a CHAR or plain TEXT literal (no 'W' or 'w'), octal escapes must have exactly 3 octal digits and hex escapes must have exactly 2 hex digits. In WIDECHAR and wide TEXT literals, octal escapes must have exactly 6 and hex escapes exactly 4. Note that character literals without/with the 'W' are of different types, CHAR and WIDECHAR, respectively. For Text literals, both forms have the same type TEXT, but the lexical formation rules are different without/with the 'W'. I'm not sure where or even whether this is documented. Rodney Bates Martin Bishop wrote: > I'm playing around with WIDECHARS, and having some trouble. > > VAR wide := ARRAY OF WIDECHAR {'\x304A', '\x306F', '\x3088', '\x3046'}; > s := Text.FromWideChars(wide); > > I get these errors from the compiler: > "../Length.m3", line 5: missing closing quote on character literal > "../Length.m3", line 5: syntax error: missing '}' (4) > "../Length.m3", line 5: missing closing quote on character literal > "../Length.m3", line 5: missing closing quote on character literal > "../Length.m3", line 5: missing closing quote on character literal > "../Length.m3", line 5: missing closing quote on character literal > "../Length.m3", line 5: missing closing quote on character literal > "../Length.m3", line 5: missing closing quote on character literal > "../Length.m3", line 5: missing closing quote on character literal > 9 errors encountered > > It seems like it's reading '\x304A' as '\x30' (which is why it says > "syntax error: missing '}' (4)") > > Do I need some special literal letter or something? > > From darko at darko.org Wed Jan 7 07:05:01 2009 From: darko at darko.org (Darko) Date: Wed, 7 Jan 2009 15:05:01 +0900 Subject: [M3devel] Widechars In-Reply-To: <49642094.7040400@wichita.edu> References: <4963C430.9020804@bellsouth.net> <49642094.7040400@wichita.edu> Message-ID: <1817F156-E305-4126-8AC0-B3070E31B330@darko.org> Yes it is documented, if you read the compiler source code. On 07/01/2009, at 12:25 PM, Rodney M. Bates wrote: > Literals of type WIDECHAR are written, e.g. W'\x304A', note the 'W'. > It makes them have type WIDECHAR and also enables the 16-bit escape > sequences you are using. If it is a CHAR or plain TEXT literal > (no 'W' or 'w'), octal escapes must have exactly 3 octal digits and > hex escapes must have exactly 2 hex digits. In WIDECHAR and wide > TEXT literals, octal escapes must have exactly 6 and hex escapes > exactly 4. > > Note that character literals without/with the 'W' are of different > types, CHAR and WIDECHAR, respectively. For Text literals, both > forms have the same type TEXT, but the lexical formation rules > are different without/with the 'W'. > > I'm not sure where or even whether this is documented. > > Rodney Bates > > > Martin Bishop wrote: >> I'm playing around with WIDECHARS, and having some trouble. >> VAR wide := ARRAY OF WIDECHAR {'\x304A', '\x306F', '\x3088', >> '\x3046'}; >> s := Text.FromWideChars(wide); >> I get these errors from the compiler: >> "../Length.m3", line 5: missing closing quote on character literal >> "../Length.m3", line 5: syntax error: missing '}' (4) >> "../Length.m3", line 5: missing closing quote on character literal >> "../Length.m3", line 5: missing closing quote on character literal >> "../Length.m3", line 5: missing closing quote on character literal >> "../Length.m3", line 5: missing closing quote on character literal >> "../Length.m3", line 5: missing closing quote on character literal >> "../Length.m3", line 5: missing closing quote on character literal >> "../Length.m3", line 5: missing closing quote on character literal >> 9 errors encountered >> It seems like it's reading '\x304A' as '\x30' (which is why it says >> "syntax error: missing '}' (4)") >> Do I need some special literal letter or something? > From hendrik at topoi.pooq.com Thu Jan 8 07:13:56 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 8 Jan 2009 01:13:56 -0500 Subject: [M3devel] Widechars In-Reply-To: <49642094.7040400@wichita.edu> References: <4963C430.9020804@bellsouth.net> <49642094.7040400@wichita.edu> Message-ID: <20090108061355.GA2554@topoi.pooq.com> On Tue, Jan 06, 2009 at 09:25:08PM -0600, Rodney M. Bates wrote: > Literals of type WIDECHAR are written, e.g. W'\x304A', note the 'W'. > It makes them have type WIDECHAR and also enables the 16-bit escape > sequences you are using. If it is a CHAR or plain TEXT literal > (no 'W' or 'w'), octal escapes must have exactly 3 octal digits and > hex escapes must have exactly 2 hex digits. In WIDECHAR and wide > TEXT literals, octal escapes must have exactly 6 and hex escapes > exactly 4. I've always thought that octal and hexadecimal escapes should be self-delimiting. In the process of moving from 8- to 16-bit characters, the length of the escapes has changed, and we're going to hit it again when we implement the larger-than-16-bit Unicode charaters. In C, for strings, you can force early termination of an escape by ending the string with a quote, then a space, then starting a new string with another quote (since consecutive strings are implicitly concatenated, so you can write a really long string that doesn't fit on a line). At least, that's what I seem to remember. I haven't actually hacked this stuff for a long time. > > Note that character literals without/with the 'W' are of different > types, CHAR and WIDECHAR, respectively. For Text literals, both > forms have the same type TEXT, but the lexical formation rules > are different without/with the 'W'. Are we going to have to implement 'WW' to avoid retrocompatibility problems? -- hendrik From jay.krell at cornell.edu Wed Jan 7 14:36:20 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 7 Jan 2009 13:36:20 +0000 Subject: [M3devel] duplication between compiler, m3makefile, and libraries; cross build easing Message-ID: duplication between compiler, m3makefile, and libraries. I propose that there should be reduced or no duplicationamong the compiler, m3makefile, and libraries. I propose that the compiler reveal (some) of what it knows. For example, m3makefile shall not specify WORD_SIZE.The compiler should.Granted, this buys very little. m3makefile shall not contain tables identifiying endianness.Compiler shall defined TARGET_ENDIAN to "BIG" or "LITTLE",or perhaps "big" or "little".Granted, this buys very little. Libraries shall not define jumpbuf, in a sense.Compile shall define, something like: TARGET_JUMPBUF_ELEMENT = "INTEGER" or "LONGINT". aka jmpbuf alignment. TARGET_JUMPBUF_SIZE = a decimal integer. Leaving library to say: TYPE jmpbuf = ARRAY [1..size] OF element which m3makefile shall produce. or perhaps even compiler shall inject the type itself,as it injects a few things like INTERFACE Word functions. or compiler shall define TARGET_JUMPBUF_ALIGN = 32 or 64,and TARGET_JUMPBUF_SIZE in bytesleaving m3makefile to map 32 to Ctypes.int and 64 to LONGINT itself. The jumpbuf size/align bothers me more than word size and endianness.Word size and endianness are more widely known to humans I think.Endianness and word size are usually fairly obvious, thoughnot 100%. I didn't know the endianness of e.g. 88k, vax, and the historicallyterse names don't make it obvious. However, let me not confuse "jumpbuf" with "Thread.State" or such.Assume user threads stops using setjmp/longjmp and modifyor generalize proposal accordingly. Wonder if exception handling should use set/get/make/swapcontext also??Assume jumpbuf might remain on some platforms? ? As well, one should be able to specify m3config on the command line.One should be able to specify target on the command line.Compiler shall take specified target and search /somehow/ for the right config file.Perhaps in path to cm3\..\config\target.Don't probe like crazy -- not like I have it coded in Quake currently.That really bites when there is more than one, and you edit the wrong one. Probably something like, probe for path to cm3\..\config\target. but if defined $CM3_CONFIG_DIRECTORY, search instead $CM3_CONFIG_DIRECTORY\target.however this is perhaps colon or semicolon delimited, so maybe CM3_CONFIG_PATH.(In particular, I have nearly all my config files in m3-sys/cminstall/src/config-no-install,except NT386, which I'd really like to move, but will probably break something anddoesn't seem important). Reasonable ideas? Personally what I do is my Python scripts accept a target name anywhere on thecommand line, and if present, they set $M3CONFIG.So I have what I want via python already.You know, kind of a successful (imho) prototype, that should perhaps be elevatedinto the "real" stuff? You know, make it easier and easier to contruct cross-capable installations,where switching targets is changing environment variables and/or command lines,and not editing/copying files. If there isn't already, there should be a mode that doesn't run cm3cg.And possibly can still ship.That way /any/ system can do a bunch of cross-build "checking".And the file system layout for creating a "boot" archive becomesabout the same as the layout of a "real" system. Not like what I use -- I use one flat directory, since Modula-3 requires that every..basically ever .i3, .m3, .o file have a unique name. (.i3 and .m3 can clash with each other, once each, that's it). - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jan 7 15:34:12 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 7 Jan 2009 14:34:12 +0000 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: <20090103011227.vgpfs347400088sg@mail.elegosoft.com> References: <20090103011227.vgpfs347400088sg@mail.elegosoft.com> Message-ID: I looked into this a bit..and I think it's actually pretty easy.It hardly churns the code even. I have other things I want to do first. In the meantime, specify the directive?There are actually a large number of subtle options. Can I ask for any of n libraries -- NT, pthreads, user threads? setjmp vs. context? Or is it just a boolean, user vs. kernel? Is the option to "favor" or "require" a certain library? Can I set it on libraries or only programs? What if the requests clash? Is it "Favor" or "Require"? Is it a function call or setting a global variable? I favor function call, but TARGET, WORD_SIZE, BUILD_DIR establish the other precedent, and either can work. Is it flags in the moduleinfo like incgc, gengc, or separate data that there is just one of in RTLinker? Probably separate data, unless it is allowed in libraries. What are the names of the libraries? "posix" and "pthreads" ? "user" and "kernel" ? "true" and "false" (or vice versa) ? Should NT implement user threads, using fibers? Presumably it works with both standalone and shared/dynamic programs. Presumably it is ok to always bloat up m3core.dll with both libraries. Presumably it is ok to have everyone pay a teeny tiny perf. That is, there is a microscopic dispatching layer, that everyone ends up going through, not chosing to link in one library or the other. And as part of this, whenever it happens, can we bump up the minimum bootstrap to a version that includes SchedulerPosix.DoesWaitPidYield()? Or does it become VAR Scheduler.UsingKerneThreads? (no, it should be a function; but naming matter remains). (ie. as I said, the decision currently is baked into m3core.dll, but now it is also baked into sysutils.dll, but these should change together; m3core.dll should manage the knowledge). - Jay> Date: Sat, 3 Jan 2009 01:12:27 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] dynamic chose between user/kernel threads?> > An option to cm3 or a quake directive to use in the m3makefiles> would suffice in my opinion (and be a great improvement).> > Olaf> > Quoting Jay :> > >> > Should the user/kernel thread chose be available:> >> >> > On the command line to a Modula-3 executable (or even an executable > > where main is in another language, but which static or dynamic > > Modula-3 libs are used)?> >> >> > Via a quake directive when building programs?> >> >> > You know, imagine you have a bunch of Modula-3 programs and some but > > not all use a very large number of threads and benefit from > > userthreads.> >> >> > Currently the chose is locked into m3core when it is built.> >> >> > - Jay> > > -- > Olaf -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Wed Jan 7 18:32:24 2009 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 07 Jan 2009 11:32:24 -0600 Subject: [M3devel] Widechars In-Reply-To: <20090108061355.GA2554@topoi.pooq.com> References: <4963C430.9020804@bellsouth.net> <49642094.7040400@wichita.edu> <20090108061355.GA2554@topoi.pooq.com> Message-ID: <4964E728.4050306@wichita.edu> hendrik at topoi.pooq.com wrote: > On Tue, Jan 06, 2009 at 09:25:08PM -0600, Rodney M. Bates wrote: >> Literals of type WIDECHAR are written, e.g. W'\x304A', note the 'W'. >> It makes them have type WIDECHAR and also enables the 16-bit escape >> sequences you are using. If it is a CHAR or plain TEXT literal >> (no 'W' or 'w'), octal escapes must have exactly 3 octal digits and >> hex escapes must have exactly 2 hex digits. In WIDECHAR and wide >> TEXT literals, octal escapes must have exactly 6 and hex escapes >> exactly 4. > > I've always thought that octal and hexadecimal escapes should be > self-delimiting. In the process of moving from 8- to 16-bit characters, > the length of the escapes has changed, and we're going to hit it again > when we implement the larger-than-16-bit Unicode charaters. > > In C, for strings, you can force early termination of an escape by > ending the string with a quote, then a space, then starting a new string > with another quote (since consecutive strings are implicitly > concatenated, so you can write a really long string that doesn't fit on > a line). At least, that's what I seem to remember. I haven't actually > hacked this stuff for a long time. This would be easy to implement, wouldn't break any existing code, and concatenating the fragments without an explicit '&' operator between would not suffer from ambiguity over whether the programmer expected runtime concatenation. I have liked this facility in C for long strings, just because I find wrapped long lines both very difficult to read and ugly. We could also easily make escapes prematurely terminated by a closing quote legal, again without breaking any existing code, which might be occasionally useful. However, if somebody wants to put a lot of escape-specified characters in a row in a TEXT literal, and not have to give every one all the most significant digits, terminating with a closing quote, then starting another literal would make things even more pedantic than they are. I have been thinking of a new set of escape letters (like the 'x', that immediately follow the backslash) that can be given independently of the 'W', and each one implies the base and number of digits. In theory, this could break existing code, if somebody had already redundantly escaped one of these new escape letters. This seems rather unlikely to have happened. > >> Note that character literals without/with the 'W' are of different >> types, CHAR and WIDECHAR, respectively. For Text literals, both >> forms have the same type TEXT, but the lexical formation rules >> are different without/with the 'W'. > > Are we going to have to implement 'WW' to avoid retrocompatibility > problems? > > -- hendrik Rodney Bates From hendrik at topoi.pooq.com Thu Jan 8 12:55:30 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 8 Jan 2009 06:55:30 -0500 Subject: [M3devel] Widechars In-Reply-To: <4964E728.4050306@wichita.edu> References: <4963C430.9020804@bellsouth.net> <49642094.7040400@wichita.edu> <20090108061355.GA2554@topoi.pooq.com> <4964E728.4050306@wichita.edu> Message-ID: <20090108115529.GA3157@topoi.pooq.com> On Wed, Jan 07, 2009 at 11:32:24AM -0600, Rodney M. Bates wrote: > hendrik at topoi.pooq.com wrote: > >On Tue, Jan 06, 2009 at 09:25:08PM -0600, Rodney M. Bates wrote: > >>Literals of type WIDECHAR are written, e.g. W'\x304A', note the 'W'. > >>It makes them have type WIDECHAR and also enables the 16-bit escape > >>sequences you are using. If it is a CHAR or plain TEXT literal > >>(no 'W' or 'w'), octal escapes must have exactly 3 octal digits and > >>hex escapes must have exactly 2 hex digits. In WIDECHAR and wide > >>TEXT literals, octal escapes must have exactly 6 and hex escapes > >>exactly 4. > > > >I've always thought that octal and hexadecimal escapes should be > >self-delimiting. In the process of moving from 8- to 16-bit characters, > >the length of the escapes has changed, and we're going to hit it again > >when we implement the larger-than-16-bit Unicode charaters. > > > >In C, for strings, you can force early termination of an escape by > >ending the string with a quote, then a space, then starting a new string > >with another quote (since consecutive strings are implicitly > >concatenated, so you can write a really long string that doesn't fit on > >a line). At least, that's what I seem to remember. I haven't actually > >hacked this stuff for a long time. > > This would be easy to implement, wouldn't break any existing code, and > concatenating the fragments without an explicit '&' operator between > would not suffer from ambiguity over whether the programmer expected > runtime concatenation. I have liked this facility in C for long strings, > just because I find wrapped long lines both very difficult to read and > ugly. In C you don't have a concatenation operator. I guess compile-time concatenation does really have different semantics from run-time, in the sense that compile-time gives you just one copy of the string, and run-time gives you a new one every time. > > We could also easily make escapes prematurely terminated by a closing > quote legal, again without breaking any existing code, which might be > occasionally useful. Of course, escapes could also be terminated by the backslash of the next escape. I don't like this as much as an explicit terminator. > > However, if somebody wants to put a lot of escape-specified characters > in a row in a TEXT literal, and not have to give every one all the > most significant digits, terminating with a closing quote, then > starting another literal would make things even more pedantic than > they are. Well, you could choose a character that does nothing but terminate an escape. Then you wouldn't have to start a new string. But it would break existing code that happens to have that character after a string. > > I have been thinking of a new set of escape letters (like the 'x', > that immediately follow the backslash) that can be given independently > of the 'W', and each one implies the base and number of digits. In > theory, this could break existing code, if somebody had already > redundantly escaped one of these new escape letters. This seems rather > unlikely to have happened. > > > > >>Note that character literals without/with the 'W' are of different > >>types, CHAR and WIDECHAR, respectively. For Text literals, both > >>forms have the same type TEXT, but the lexical formation rules > >>are different without/with the 'W'. > > > >Are we going to have to implement 'WW' to avoid retrocompatibility > >problems? > > > >-- hendrik > > Rodney Bates > > From hosking at cs.purdue.edu Thu Jan 8 03:46:58 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 8 Jan 2009 13:46:58 +1100 Subject: [M3devel] duplication between compiler, m3makefile, and libraries; cross build easing In-Reply-To: References: Message-ID: Why would the compiler know anything about jmpbuf in general? (Yes, I know it is used for exception handling). I would prefer that we had table-based exception handling as on SOLgnu for all targets, but that depends on support for stack unwinding for each target. I would hate for the compiler to inject a type for something like jmpbuf which is an *internal* detail of the exceptions implementation rather than a language-defined type. Also, there are advantages in the current approach, which decouples communication of information amongst the tool-chain components. Why would you use setcontext, getcontext, etc. for exception handling. setjmp/longjmp are perfectly adequate to the task. setcontext/getcontext are intended for user-thread switching, etc. I think you'll find there already is a compiler mode that does not invoke cm3cg. 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 8 Jan 2009, at 00:36, Jay wrote: > duplication between compiler, m3makefile, and libraries. > > > I propose that there should be reduced or no duplication > among the compiler, m3makefile, and libraries. > > > I propose that the compiler reveal (some) of what it knows. > > > For example, m3makefile shall not specify WORD_SIZE. > The compiler should. > Granted, this buys very little. > > > m3makefile shall not contain tables identifiying endianness. > Compiler shall defined TARGET_ENDIAN to "BIG" or "LITTLE", > or perhaps "big" or "little". > Granted, this buys very little. > > > Libraries shall not define jumpbuf, in a sense. > Compile shall define, something like: > TARGET_JUMPBUF_ELEMENT = "INTEGER" or "LONGINT". > aka jmpbuf alignment. > TARGET_JUMPBUF_SIZE = a decimal integer. > Leaving library to say: > TYPE jmpbuf = ARRAY [1..size] OF element > which m3makefile shall produce. > > > or perhaps even compiler shall inject the type itself, > as it injects a few things like INTERFACE Word functions. > > > or compiler shall define TARGET_JUMPBUF_ALIGN = 32 or 64, > and TARGET_JUMPBUF_SIZE in bytes > leaving m3makefile to map 32 to Ctypes.int and 64 to LONGINT itself. > > > The jumpbuf size/align bothers me more than word size and endianness. > Word size and endianness are more widely known to humans I think. > Endianness and word size are usually fairly obvious, though > not 100%. I didn't know the endianness of e.g. 88k, vax, and the > historically > terse names don't make it obvious. > > > However, let me not confuse "jumpbuf" with "Thread.State" or such. > Assume user threads stops using setjmp/longjmp and modify > or generalize proposal accordingly. > > Wonder if exception handling should use set/get/make/swapcontext > also?? > Assume jumpbuf might remain on some platforms? > > ? > > As well, one should be able to specify m3config on the command line. > One should be able to specify target on the command line. > Compiler shall take specified target and search /somehow/ for the > right config file. > Perhaps in path to cm3\..\config\target. > Don't probe like crazy -- not like I have it coded in Quake currently. > That really bites when there is more than one, and you edit the > wrong one. > > Probably something like, > probe for path to cm3\..\config\target. > > but if defined $CM3_CONFIG_DIRECTORY, search instead > $CM3_CONFIG_DIRECTORY\target. > however this is perhaps colon or semicolon delimited, so maybe > CM3_CONFIG_PATH. > (In particular, I have nearly all my config files in m3-sys/ > cminstall/src/config-no-install, > except NT386, which I'd really like to move, but will probably break > something and > doesn't seem important). > > Reasonable ideas? > > > Personally what I do is my Python scripts accept a target name > anywhere on the > command line, and if present, they set $M3CONFIG. > So I have what I want via python already. > You know, kind of a successful (imho) prototype, that should perhaps > be elevated > into the "real" stuff? > > > You know, make it easier and easier to contruct cross-capable > installations, > where switching targets is changing environment variables and/or > command lines, > and not editing/copying files. > > > If there isn't already, there should be a mode that doesn't run cm3cg. > And possibly can still ship. > That way /any/ system can do a bunch of cross-build "checking". > And the file system layout for creating a "boot" archive becomes > about the same as the layout of a "real" system. > Not like what I use -- I use one flat directory, since Modula-3 > requires that every..basically ever .i3, .m3, .o file have a unique > name. > (.i3 and .m3 can clash with each other, once each, that's it). > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jan 8 03:51:15 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 8 Jan 2009 13:51:15 +1100 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: References: <20090103011227.vgpfs347400088sg@mail.elegosoft.com> Message-ID: <44664E56-D816-4A94-AD2E-96A0DB383DDF@cs.purdue.edu> Jay, perhaps you can provide some context and motivation for your proposals. I am unable to evaluate your proposals in the form of a simple laundry-list. On 8 Jan 2009, at 01:34, Jay wrote: > I looked into this a bit..and I think it's actually pretty easy. > It hardly churns the code even. > > > I have other things I want to do first. > > > In the meantime, specify the directive? > There are actually a large number of subtle options. > > > Can I ask for any of n libraries -- NT, pthreads, user threads? > setjmp vs. context? Or is it just a boolean, user vs. kernel? > > > Is the option to "favor" or "require" a certain library? > > > Can I set it on libraries or only programs? > What if the requests clash? > > > Is it "Favor" or "Require"? > Is it a function call or setting a global variable? > I favor function call, but TARGET, WORD_SIZE, BUILD_DIR establish > the other precedent, > and either can work. > > Is it flags in the moduleinfo like incgc, gengc, or separate data that > there is just one of in RTLinker? Probably separate data, unless it > is allowed in libraries. > > > What are the names of the libraries? > "posix" and "pthreads" ? > "user" and "kernel" ? > "true" and "false" (or vice versa) ? > > > Should NT implement user threads, using fibers? > > > Presumably it works with both standalone and shared/dynamic programs. > Presumably it is ok to always bloat up m3core.dll with both libraries. > Presumably it is ok to have everyone pay a teeny tiny perf. > That is, there is a microscopic dispatching layer, that everyone > ends up going through, not chosing to link in one library or the > other. > > > And as part of this, whenever it happens, can we bump up the minimum > bootstrap to a version that includes > SchedulerPosix.DoesWaitPidYield()? > Or does it become VAR Scheduler.UsingKerneThreads? > (no, it should be a function; but naming matter remains). > > > (ie. as I said, the decision currently is baked into m3core.dll, but > now it is also baked into sysutils.dll, but these should change > together; > m3core.dll should manage the knowledge). > > > - Jay > > > > Date: Sat, 3 Jan 2009 01:12:27 +0100 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] dynamic chose between user/kernel threads? > > > > An option to cm3 or a quake directive to use in the m3makefiles > > would suffice in my opinion (and be a great improvement). > > > > Olaf > > > > Quoting Jay : > > > > > > > > Should the user/kernel thread chose be available: > > > > > > > > > On the command line to a Modula-3 executable (or even an > executable > > > where main is in another language, but which static or dynamic > > > Modula-3 libs are used)? > > > > > > > > > Via a quake directive when building programs? > > > > > > > > > You know, imagine you have a bunch of Modula-3 programs and some > but > > > not all use a very large number of threads and benefit from > > > userthreads. > > > > > > > > > Currently the chose is locked into m3core when it is built. > > > > > > > > > - Jay > > > > > > -- > > Olaf -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 8 04:10:49 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 8 Jan 2009 03:10:49 +0000 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: <44664E56-D816-4A94-AD2E-96A0DB383DDF@cs.purdue.edu> References: <20090103011227.vgpfs347400088sg@mail.elegosoft.com> <44664E56-D816-4A94-AD2E-96A0DB383DDF@cs.purdue.edu> Message-ID: Olaf understood the point (I think). :) Some programs, people say, and I believe, run "better" (faster, without running out of address space) with user threads instead of kernel threads. On systems that have both. A good example might be a program that needs lots of threads and therefore small stacks, and the kernel threads, due to code below the Modula-3 runtime, might force fairly large stacks. (Such a program might have to adjust thread size differently for different threads, and only call into the underlying system on threads with larger stacks.) It might be nice for such programs to be able to mandate or request (two slightly different things) that the user thread library be used by them, even if the platform's default is to use kernel threads. The only minor detail then is, how to express the request, and the precise meaning. It is a request or a mandate? As well, if the issue is address space, sholud there a "built in" way to only make the request on 32bit platforms, or should uses manually say if equal (WORD_SIZE, "32BITS")? Is it a boolean or an enum? Cygwin might conceivably get pthreads support (Cygwin has it, but Modula-3/Cygwin does not). Therefore, is the choice among "posix" threads, "pthreads" and "NT" threads? Or just user vs. kernel? I think the "important" part here is easy to implement. But again.. The easier straightforward implementation always links both pieces of code in and makes a choice early in startup as to which to use, either setting a boolean, or an enum, or a pointer to a record of function pointers. This means that people that don't care to ever use user threads pay a small price, in code bloat and probably in a few extra instructions per certain functions. This is probably ok. However if that was not ok, the choice could be made at link time and only be supported for standalone programs. - Jay CC: wagner at elegosoft.com; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] dynamic chose between user/kernel threads?Date: Thu, 8 Jan 2009 13:51:15 +1100 Jay, perhaps you can provide some context and motivation for your proposals. I am unable to evaluate your proposals in the form of a simple laundry-list. On 8 Jan 2009, at 01:34, Jay wrote: I looked into this a bit..and I think it's actually pretty easy.It hardly churns the code even. I have other things I want to do first. In the meantime, specify the directive?There are actually a large number of subtle options. Can I ask for any of n libraries -- NT, pthreads, user threads? setjmp vs. context? Or is it just a boolean, user vs. kernel? Is the option to "favor" or "require" a certain library? Can I set it on libraries or only programs? What if the requests clash? Is it "Favor" or "Require"?Is it a function call or setting a global variable?I favor function call, but TARGET, WORD_SIZE, BUILD_DIR establish the other precedent,and either can work. Is it flags in the moduleinfo like incgc, gengc, or separate data thatthere is just one of in RTLinker? Probably separate data, unless it is allowed in libraries. What are the names of the libraries? "posix" and "pthreads" ? "user" and "kernel" ? "true" and "false" (or vice versa) ? Should NT implement user threads, using fibers? Presumably it works with both standalone and shared/dynamic programs.Presumably it is ok to always bloat up m3core.dll with both libraries.Presumably it is ok to have everyone pay a teeny tiny perf. That is, there is a microscopic dispatching layer, that everyone ends up going through, not chosing to link in one library or the other. And as part of this, whenever it happens, can we bump up the minimumbootstrap to a version that includes SchedulerPosix.DoesWaitPidYield()?Or does it become VAR Scheduler.UsingKerneThreads?(no, it should be a function; but naming matter remains). (ie. as I said, the decision currently is baked into m3core.dll, butnow it is also baked into sysutils.dll, but these should change together;m3core.dll should manage the knowledge). - Jay> Date: Sat, 3 Jan 2009 01:12:27 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] dynamic chose between user/kernel threads?> > An option to cm3 or a quake directive to use in the m3makefiles> would suffice in my opinion (and be a great improvement).> > Olaf> > Quoting Jay :> > >> > Should the user/kernel thread chose be available:> >> >> > On the command line to a Modula-3 executable (or even an executable > > where main is in another language, but which static or dynamic > > Modula-3 libs are used)?> >> >> > Via a quake directive when building programs?> >> >> > You know, imagine you have a bunch of Modula-3 programs and some but > > not all use a very large number of threads and benefit from > > userthreads.> >> >> > Currently the chose is locked into m3core when it is built.> >> >> > - Jay> > > -- > Olaf -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 8 04:44:40 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 8 Jan 2009 03:44:40 +0000 Subject: [M3devel] duplication between compiler, m3makefile, and libraries; cross build easing In-Reply-To: References: Message-ID: Is table-based exception handling close to being feasible on many targets? I figured it was mostly a lost cause but wouldn't mind being wrong. Perhaps the evolution of gcc has made it much easier these days? You know, what with Ada and C++ exception handling support being whatever it is? Imho target-specific information should be kept to a minimum kept to a minimum number of places/files perhaps kept to a minimum distance from other target-specific information (places/files) and like other information, not duplicated If jumpbuf wasn't used by the compiler, then my position weakens. However currently the size and alignment of jumpbuf is duplicated. And endianness is duplicated. And wordsize is duplicated. I wouldn't mind if jumpbuf was only, say, Csetjmp.i3, and wordsize was only in the config file. But duplication bugs me. > why context for exception handling vs. setjmp/longjmp. Just my ignorant questioning. If setjmp/longjmp suffice, ok. They are just similar and perhaps if switch one, switch the other. I realize that longjmp can only officially be called once per setjmp, and that contexts are "reusable" (can be swapped an arbitrary number of times). - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Thu, 8 Jan 2009 13:46:58 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] duplication between compiler, m3makefile, and libraries; cross build easingWhy would the compiler know anything about jmpbuf in general? (Yes, I know it is used for exception handling). I would prefer that we had table-based exception handling as on SOLgnu for all targets, but that depends on support for stack unwinding for each target. I would hate for the compiler to inject a type for something like jmpbuf which is an *internal* detail of the exceptions implementation rather than a language-defined type. Also, there are advantages in the current approach, which decouples communication of information amongst the tool-chain components. Why would you use setcontext, getcontext, etc. for exception handling. setjmp/longjmp are perfectly adequate to the task. setcontext/getcontext are intended for user-thread switching, etc. I think you'll find there already is a compiler mode that does not invoke cm3cg. 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 8 Jan 2009, at 00:36, Jay wrote: duplication between compiler, m3makefile, and libraries. I propose that there should be reduced or no duplicationamong the compiler, m3makefile, and libraries. I propose that the compiler reveal (some) of what it knows. For example, m3makefile shall not specify WORD_SIZE.The compiler should.Granted, this buys very little. m3makefile shall not contain tables identifiying endianness.Compiler shall defined TARGET_ENDIAN to "BIG" or "LITTLE",or perhaps "big" or "little".Granted, this buys very little. Libraries shall not define jumpbuf, in a sense.Compile shall define, something like: TARGET_JUMPBUF_ELEMENT = "INTEGER" or "LONGINT". aka jmpbuf alignment. TARGET_JUMPBUF_SIZE = a decimal integer.Leaving library to say: TYPE jmpbuf = ARRAY [1..size] OF elementwhich m3makefile shall produce. or perhaps even compiler shall inject the type itself,as it injects a few things like INTERFACE Word functions. or compiler shall define TARGET_JUMPBUF_ALIGN = 32 or 64,and TARGET_JUMPBUF_SIZE in bytesleaving m3makefile to map 32 to Ctypes.int and 64 to LONGINT itself. The jumpbuf size/align bothers me more than word size and endianness.Word size and endianness are more widely known to humans I think.Endianness and word size are usually fairly obvious, thoughnot 100%. I didn't know the endianness of e.g. 88k, vax, and the historicallyterse names don't make it obvious. However, let me not confuse "jumpbuf" with "Thread.State" or such.Assume user threads stops using setjmp/longjmp and modifyor generalize proposal accordingly.Wonder if exception handling should use set/get/make/swapcontext also??Assume jumpbuf might remain on some platforms? ?As well, one should be able to specify m3config on the command line.One should be able to specify target on the command line.Compiler shall take specified target and search /somehow/ for the right config file.Perhaps in path to cm3\..\config\target.Don't probe like crazy -- not like I have it coded in Quake currently.That really bites when there is more than one, and you edit the wrong one.Probably something like, probe for path to cm3\..\config\target.but if defined $CM3_CONFIG_DIRECTORY, search instead $CM3_CONFIG_DIRECTORY\target.however this is perhaps colon or semicolon delimited, so maybe CM3_CONFIG_PATH.(In particular, I have nearly all my config files in m3-sys/cminstall/src/config-no-install,except NT386, which I'd really like to move, but will probably break something anddoesn't seem important).Reasonable ideas? Personally what I do is my Python scripts accept a target name anywhere on thecommand line, and if present, they set $M3CONFIG.So I have what I want via python already.You know, kind of a successful (imho) prototype, that should perhaps be elevatedinto the "real" stuff? You know, make it easier and easier to contruct cross-capable installations,where switching targets is changing environment variables and/or command lines,and not editing/copying files. If there isn't already, there should be a mode that doesn't run cm3cg.And possibly can still ship.That way /any/ system can do a bunch of cross-build "checking".And the file system layout for creating a "boot" archive becomesabout the same as the layout of a "real" system. Not like what I use -- I use one flat directory, since Modula-3 requires that every..basically ever .i3, .m3, .o file have a unique name. (.i3 and .m3 can clash with each other, once each, that's it). - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 8 04:50:54 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 8 Jan 2009 03:50:54 +0000 Subject: [M3devel] duplication between compiler, m3makefile, and libraries; cross build easing In-Reply-To: References: Message-ID: > I would hate for the compiler to inject a type for > something like jmpbuf which is an *internal* detail > of the exceptions implementation rather than a language-defined type The compiler and runtime are unavoidably somewhat interdependent on each other. You know, that the compiler generates calls to RTHooks.i3. If you want the ability to retarget the compiler to a slightly different runtime, then the runtime should inform the compiler, and not the other way around, but they remain interdepenent. There are similar issues here probably regarding RT0.i3 and RTBuiltin.c. I guess you don't want the compiler to clutter the global type/modulespace, as a communications channel, to share information. But I think language and library are somewhat murky. Is INTERFACE Word in the language or the library? Is LOCK language or library? These are both in-between. INTERFACE Word is in the "standard library", and I think it is only in the compiler as an implementation specific optimization. LOCK is necessarily in both. - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] duplication between compiler, m3makefile, and libraries; cross build easingDate: Thu, 8 Jan 2009 03:44:40 +0000 Is table-based exception handling close to being feasible on many targets?I figured it was mostly a lost cause but wouldn't mind being wrong.Perhaps the evolution of gcc has made it much easier these days?You know, what with Ada and C++ exception handling support being whatever it is? Imho target-specific information should be kept to a minimum kept to a minimum number of places/files perhaps kept to a minimum distance from other target-specific information (places/files) and like other information, not duplicated If jumpbuf wasn't used by the compiler, then my position weakens.However currently the size and alignment of jumpbuf is duplicated.And endianness is duplicated. And wordsize is duplicated.I wouldn't mind if jumpbuf was only, say, Csetjmp.i3, and wordsize was only in the config file.But duplication bugs me. > why context for exception handling vs. setjmp/longjmp. Just my ignorant questioning. If setjmp/longjmp suffice, ok.They are just similar and perhaps if switch one, switch the other.I realize that longjmp can only officially be called once per setjmp, and that contexts are "reusable" (can be swapped an arbitrary number of times). - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Thu, 8 Jan 2009 13:46:58 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] duplication between compiler, m3makefile, and libraries; cross build easingWhy would the compiler know anything about jmpbuf in general? (Yes, I know it is used for exception handling). I would prefer that we had table-based exception handling as on SOLgnu for all targets, but that depends on support for stack unwinding for each target. I would hate for the compiler to inject a type for something like jmpbuf which is an *internal* detail of the exceptions implementation rather than a language-defined type. Also, there are advantages in the current approach, which decouples communication of information amongst the tool-chain components. Why would you use setcontext, getcontext, etc. for exception handling. setjmp/longjmp are perfectly adequate to the task. setcontext/getcontext are intended for user-thread switching, etc. I think you'll find there already is a compiler mode that does not invoke cm3cg. 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 8 Jan 2009, at 00:36, Jay wrote: duplication between compiler, m3makefile, and libraries. I propose that there should be reduced or no duplicationamong the compiler, m3makefile, and libraries. I propose that the compiler reveal (some) of what it knows. For example, m3makefile shall not specify WORD_SIZE.The compiler should.Granted, this buys very little. m3makefile shall not contain tables identifiying endianness.Compiler shall defined TARGET_ENDIAN to "BIG" or "LITTLE",or perhaps "big" or "little".Granted, this buys very little. Libraries shall not define jumpbuf, in a sense.Compile shall define, something like: TARGET_JUMPBUF_ELEMENT = "INTEGER" or "LONGINT". aka jmpbuf alignment. TARGET_JUMPBUF_SIZE = a decimal integer.Leaving library to say: TYPE jmpbuf = ARRAY [1..size] OF elementwhich m3makefile shall produce. or perhaps even compiler shall inject the type itself,as it injects a few things like INTERFACE Word functions. or compiler shall define TARGET_JUMPBUF_ALIGN = 32 or 64,and TARGET_JUMPBUF_SIZE in bytesleaving m3makefile to map 32 to Ctypes.int and 64 to LONGINT itself. The jumpbuf size/align bothers me more than word size and endianness.Word size and endianness are more widely known to humans I think.Endianness and word size are usually fairly obvious, thoughnot 100%. I didn't know the endianness of e.g. 88k, vax, and the historicallyterse names don't make it obvious. However, let me not confuse "jumpbuf" with "Thread.State" or such.Assume user threads stops using setjmp/longjmp and modifyor generalize proposal accordingly.Wonder if exception handling should use set/get/make/swapcontext also??Assume jumpbuf might remain on some platforms? ?As well, one should be able to specify m3config on the command line.One should be able to specify target on the command line.Compiler shall take specified target and search /somehow/ for the right config file.Perhaps in path to cm3\..\config\target.Don't probe like crazy -- not like I have it coded in Quake currently.That really bites when there is more than one, and you edit the wrong one.Probably something like, probe for path to cm3\..\config\target.but if defined $CM3_CONFIG_DIRECTORY, search instead $CM3_CONFIG_DIRECTORY\target.however this is perhaps colon or semicolon delimited, so maybe CM3_CONFIG_PATH.(In particular, I have nearly all my config files in m3-sys/cminstall/src/config-no-install,except NT386, which I'd really like to move, but will probably break something anddoesn't seem important).Reasonable ideas? Personally what I do is my Python scripts accept a target name anywhere on thecommand line, and if present, they set $M3CONFIG.So I have what I want via python already.You know, kind of a successful (imho) prototype, that should perhaps be elevatedinto the "real" stuff? You know, make it easier and easier to contruct cross-capable installations,where switching targets is changing environment variables and/or command lines,and not editing/copying files. If there isn't already, there should be a mode that doesn't run cm3cg.And possibly can still ship.That way /any/ system can do a bunch of cross-build "checking".And the file system layout for creating a "boot" archive becomesabout the same as the layout of a "real" system. Not like what I use -- I use one flat directory, since Modula-3 requires that every..basically ever .i3, .m3, .o file have a unique name. (.i3 and .m3 can clash with each other, once each, that's it). - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jan 8 05:58:38 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 8 Jan 2009 15:58:38 +1100 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: References: <20090103011227.vgpfs347400088sg@mail.elegosoft.com> <44664E56-D816-4A94-AD2E-96A0DB383DDF@cs.purdue.edu> Message-ID: <234B3116-4C98-470B-9929-3E2AC72D67DC@cs.purdue.edu> On 8 Jan 2009, at 14:10, Jay wrote: > Olaf understood the point (I think). :) > > Some programs, people say, and I believe, run "better" (faster, > without running out of address space) with user threads instead of > kernel threads. Is this still true for modern kernel thread systems? > On systems that have both. > A good example might be a program that needs lots of threads and > therefore small stacks, and the kernel threads, due to code below > the Modula-3 runtime, might force fairly large stacks. (Such a > program might have to adjust thread size differently for different > threads, and only call into the underlying system on threads with > larger stacks.) In a systems programming language like Modula-3 shouldn't threads have a relationship to the system? > It might be nice for such programs to be able to mandate or request > (two slightly different things) that the user thread library be used > by them, even if the platform's default is to use kernel threads. This will need to be a link-time distinction. I would hate to have both kernel and user thread code live in the same compiled run-time system. > The only minor detail then is, how to express the request, and the > precise meaning. > It is a request or a mandate? I see no problem with factoring out the threads subsystem as a separate library and linking accordingly. > As well, if the issue is address space, sholud there a "built in" > way to only make the request on 32bit platforms, or should uses > manually say if equal (WORD_SIZE, "32BITS")? > > Is it a boolean or an enum? > Cygwin might conceivably get pthreads support (Cygwin has it, but > Modula-3/Cygwin does not). > Therefore, is the choice among "posix" threads, "pthreads" and "NT" > threads? > Or just user vs. kernel? I would argue for user vs. kernel. > I think the "important" part here is easy to implement. > But again.. And managing the state-space explosion that multiple choices might entail. I would like to avoid that. > The easier straightforward implementation always links both pieces > of code in and makes a choice early in startup as to which to use, > either setting a boolean, or an enum, or a pointer to a record of > function pointers. This means that people that don't care to ever > use user threads pay a small price, in code bloat and probably in a > few extra instructions per certain functions. This is probably ok. I am not so sure, since it would entail some fairly low-level and expensive decisions that would best instead be done at link-time. > However if that was not ok, the choice could be made at link time > and only be supported for standalone programs. Actually, for non-standalone (dynamically-linked) code we could make the choice at dynamic load time using the OS's support for dynamic library choice. I note that Solaris (but not Solaris Modula-3) currently lets dynamically linked C programs choose among 3 different threads implementations dynamically. > > > - Jay > > > > > CC: wagner at elegosoft.com; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] dynamic chose between user/kernel threads? > Date: Thu, 8 Jan 2009 13:51:15 +1100 > > > Jay, perhaps you can provide some context and motivation for your > proposals. I am unable to evaluate your proposals in the form of a > simple laundry-list. > > On 8 Jan 2009, at 01:34, Jay wrote: > > I looked into this a bit..and I think it's actually pretty easy. > It hardly churns the code even. > > > I have other things I want to do first. > > > In the meantime, specify the directive? > There are actually a large number of subtle options. > > > Can I ask for any of n libraries -- NT, pthreads, user threads? > setjmp vs. context? Or is it just a boolean, user vs. kernel? > > > Is the option to "favor" or "require" a certain library? > > > Can I set it on libraries or only programs? > What if the requests clash? > > > Is it "Favor" or "Require"? > Is it a function call or setting a global variable? > I favor function call, but TARGET, WORD_SIZE, BUILD_DIR establish > the other precedent, > and either can work. > > Is it flags in the moduleinfo like incgc, gengc, or separate data that > there is just one of in RTLinker? Probably separate data, unless it > is allowed in libraries. > > > What are the names of the libraries? > "posix" and "pthreads" ? > "user" and "kernel" ? > "true" and "false" (or vice versa) ? > > > Should NT implement user threads, using fibers? > > > Presumably it works with both standalone and shared/dynamic programs. > Presumably it is ok to always bloat up m3core.dll with both libraries. > Presumably it is ok to have everyone pay a teeny tiny perf. > That is, there is a microscopic dispatching layer, that everyone > ends up going through, not chosing to link in one library or the > other. > > > And as part of this, whenever it happens, can we bump up the minimum > bootstrap to a version that includes > SchedulerPosix.DoesWaitPidYield()? > Or does it become VAR Scheduler.UsingKerneThreads? > (no, it should be a function; but naming matter remains). > > > (ie. as I said, the decision currently is baked into m3core.dll, but > now it is also baked into sysutils.dll, but these should change > together; > m3core.dll should manage the knowledge). > > > - Jay > > > > Date: Sat, 3 Jan 2009 01:12:27 +0100 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] dynamic chose between user/kernel threads? > > > > An option to cm3 or a quake directive to use in the m3makefiles > > would suffice in my opinion (and be a great improvement). > > > > Olaf > > > > Quoting Jay : > > > > > > > > Should the user/kernel thread chose be available: > > > > > > > > > On the command line to a Modula-3 executable (or even an > executable > > > where main is in another language, but which static or dynamic > > > Modula-3 libs are used)? > > > > > > > > > Via a quake directive when building programs? > > > > > > > > > You know, imagine you have a bunch of Modula-3 programs and some > but > > > not all use a very large number of threads and benefit from > > > userthreads. > > > > > > > > > Currently the chose is locked into m3core when it is built. > > > > > > > > > - Jay > > > > > > -- > > Olaf > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jan 8 06:03:51 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 8 Jan 2009 16:03:51 +1100 Subject: [M3devel] duplication between compiler, m3makefile, and libraries; cross build easing In-Reply-To: References: Message-ID: <41260DC6-BBA1-4628-BAEE-8482D4531EFA@cs.purdue.edu> On 8 Jan 2009, at 14:44, Jay wrote: > Is table-based exception handling close to being feasible on many > targets? We could make use of libunwind (http://www.nongnu.org/libunwind/) to do the unwinding and use the table-based scheme. I note that gcc already comes with a version of libunwind for some targets. > I figured it was mostly a lost cause but wouldn't mind being wrong. I hope not, since setjmp/longjmp is needlessly expensive. > Perhaps the evolution of gcc has made it much easier these days? > You know, what with Ada and C++ exception handling support being > whatever it is? Indeed. > Imho target-specific information should be > kept to a minimum > kept to a minimum number of places/files > perhaps kept to a minimum distance from other target-specific > information (places/files) > and like other information, not duplicated Yes, a laudable goal. > If jumpbuf wasn't used by the compiler, then my position weakens. > However currently the size and alignment of jumpbuf is duplicated. > And endianness is duplicated. And wordsize is duplicated. > I wouldn't mind if jumpbuf was only, say, Csetjmp.i3, and wordsize > was only in the config file. > But duplication bugs me. Indeed. > > why context for exception handling vs. setjmp/longjmp. > > Just my ignorant questioning. If setjmp/longjmp suffice, ok. > They are just similar and perhaps if switch one, switch the other. > I realize that longjmp can only officially be called once per > setjmp, and that contexts are "reusable" (can be swapped an > arbitrary number of times). Yes, that is the distinction -- I expect that has some impact on the underlying implementation and efficiency. > > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Thu, 8 Jan 2009 13:46:58 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] duplication between compiler, m3makefile, and > libraries; cross build easing > > Why would the compiler know anything about jmpbuf in general? (Yes, > I know it is used for exception handling). I would prefer that we > had table-based exception handling as on SOLgnu for all targets, but > that depends on support for stack unwinding for each target. I > would hate for the compiler to inject a type for something like > jmpbuf which is an *internal* detail of the exceptions > implementation rather than a language-defined type. Also, there are > advantages in the current approach, which decouples communication of > information amongst the tool-chain components. > > Why would you use setcontext, getcontext, etc. for exception > handling. setjmp/longjmp are perfectly adequate to the task. > setcontext/getcontext are intended for user-thread switching, etc. > > I think you'll find there already is a compiler mode that does not > invoke cm3cg. > > 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 8 Jan 2009, at 00:36, Jay wrote: > > duplication between compiler, m3makefile, and libraries. > > > I propose that there should be reduced or no duplication > among the compiler, m3makefile, and libraries. > > > I propose that the compiler reveal (some) of what it knows. > > > For example, m3makefile shall not specify WORD_SIZE. > The compiler should. > Granted, this buys very little. > > > m3makefile shall not contain tables identifiying endianness. > Compiler shall defined TARGET_ENDIAN to "BIG" or "LITTLE", > or perhaps "big" or "little". > Granted, this buys very little. > > > Libraries shall not define jumpbuf, in a sense. > Compile shall define, something like: > TARGET_JUMPBUF_ELEMENT = "INTEGER" or "LONGINT". > aka jmpbuf alignment. > TARGET_JUMPBUF_SIZE = a decimal integer. > Leaving library to say: > TYPE jmpbuf = ARRAY [1..size] OF element > which m3makefile shall produce. > > > or perhaps even compiler shall inject the type itself, > as it injects a few things like INTERFACE Word functions. > > > or compiler shall define TARGET_JUMPBUF_ALIGN = 32 or 64, > and TARGET_JUMPBUF_SIZE in bytes > leaving m3makefile to map 32 to Ctypes.int and 64 to LONGINT itself. > > > The jumpbuf size/align bothers me more than word size and endianness. > Word size and endianness are more widely known to humans I think. > Endianness and word size are usually fairly obvious, though > not 100%. I didn't know the endianness of e.g. 88k, vax, and the > historically > terse names don't make it obvious. > > > However, let me not confuse "jumpbuf" with "Thread.State" or such. > Assume user threads stops using setjmp/longjmp and modify > or generalize proposal accordingly. > > Wonder if exception handling should use set/get/make/swapcontext > also?? > Assume jumpbuf might remain on some platforms? > > ? > > As well, one should be able to specify m3config on the command line. > One should be able to specify target on the command line. > Compiler shall take specified target and search /somehow/ for the > right config file. > Perhaps in path to cm3\..\config\target. > Don't probe like crazy -- not like I have it coded in Quake currently. > That really bites when there is more than one, and you edit the > wrong one. > > Probably something like, > probe for path to cm3\..\config\target. > > but if defined $CM3_CONFIG_DIRECTORY, search instead > $CM3_CONFIG_DIRECTORY\target. > however this is perhaps colon or semicolon delimited, so maybe > CM3_CONFIG_PATH. > (In particular, I have nearly all my config files in m3-sys/ > cminstall/src/config-no-install, > except NT386, which I'd really like to move, but will probably break > something and > doesn't seem important). > > Reasonable ideas? > > > Personally what I do is my Python scripts accept a target name > anywhere on the > command line, and if present, they set $M3CONFIG. > So I have what I want via python already. > You know, kind of a successful (imho) prototype, that should perhaps > be elevated > into the "real" stuff? > > > You know, make it easier and easier to contruct cross-capable > installations, > where switching targets is changing environment variables and/or > command lines, > and not editing/copying files. > > > If there isn't already, there should be a mode that doesn't run cm3cg. > And possibly can still ship. > That way /any/ system can do a bunch of cross-build "checking". > And the file system layout for creating a "boot" archive becomes > about the same as the layout of a "real" system. > Not like what I use -- I use one flat directory, since Modula-3 > requires that every..basically ever .i3, .m3, .o file have a unique > name. > (.i3 and .m3 can clash with each other, once each, that's it). > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jan 8 06:05:43 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 8 Jan 2009 16:05:43 +1100 Subject: [M3devel] duplication between compiler, m3makefile, and libraries; cross build easing In-Reply-To: References: Message-ID: On 8 Jan 2009, at 14:50, Jay wrote: > > I would hate for the compiler to inject a type for > > something like jmpbuf which is an *internal* detail > > of the exceptions implementation rather than a language-defined > type > > The compiler and runtime are unavoidably somewhat interdependent on > each other. > You know, that the compiler generates calls to RTHooks.i3. Yes, of course they are, but we want to keep the interface between them as narrow as possible. > If you want the ability to retarget the compiler to a slightly > different runtime, then the runtime should > inform the compiler, and not the other way around, but they remain > interdepenent. Not sure how you would achieve that. > There are similar issues here probably regarding RT0.i3 and > RTBuiltin.c. Here be dragons... > I guess you don't want the compiler to clutter the global type/ > modulespace, as a communications channel, to share information. Precisely. > But I think language and library are somewhat murky. True. Java has a simple core language, but lots of powerful libraries. > Is INTERFACE Word in the language or the library? > Is LOCK language or library? > These are both in-between. > INTERFACE Word is in the "standard library", and I think it is only > in the compiler as an implementation specific optimization. LOCK is > necessarily in both. > > - Jay > > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] duplication between compiler, m3makefile, and > libraries; cross build easing > Date: Thu, 8 Jan 2009 03:44:40 +0000 > > Is table-based exception handling close to being feasible on many > targets? > I figured it was mostly a lost cause but wouldn't mind being wrong. > Perhaps the evolution of gcc has made it much easier these days? > You know, what with Ada and C++ exception handling support being > whatever it is? > > Imho target-specific information should be > kept to a minimum > kept to a minimum number of places/files > perhaps kept to a minimum distance from other target-specific > information (places/files) > and like other information, not duplicated > > > If jumpbuf wasn't used by the compiler, then my position weakens. > However currently the size and alignment of jumpbuf is duplicated. > And endianness is duplicated. And wordsize is duplicated. > I wouldn't mind if jumpbuf was only, say, Csetjmp.i3, and wordsize > was only in the config file. > But duplication bugs me. > > > why context for exception handling vs. setjmp/longjmp. > > Just my ignorant questioning. If setjmp/longjmp suffice, ok. > They are just similar and perhaps if switch one, switch the other. > I realize that longjmp can only officially be called once per > setjmp, and that contexts are "reusable" (can be swapped an > arbitrary number of times). > > - Jay > > > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Thu, 8 Jan 2009 13:46:58 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] duplication between compiler, m3makefile, and > libraries; cross build easing > > Why would the compiler know anything about jmpbuf in general? (Yes, > I know it is used for exception handling). I would prefer that we > had table-based exception handling as on SOLgnu for all targets, but > that depends on support for stack unwinding for each target. I > would hate for the compiler to inject a type for something like > jmpbuf which is an *internal* detail of the exceptions > implementation rather than a language-defined type. Also, there are > advantages in the current approach, which decouples communication of > information amongst the tool-chain components. > > > Why would you use setcontext, getcontext, etc. for exception > handling. setjmp/longjmp are perfectly adequate to the task. > setcontext/getcontext are intended for user-thread switching, etc. > > I think you'll find there already is a compiler mode that does not > invoke cm3cg. > > 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 8 Jan 2009, at 00:36, Jay wrote: > > duplication between compiler, m3makefile, and libraries. > > > I propose that there should be reduced or no duplication > among the compiler, m3makefile, and libraries. > > > I propose that the compiler reveal (some) of what it knows. > > > For example, m3makefile shall not specify WORD_SIZE. > The compiler should. > Granted, this buys very little. > > > m3makefile shall not contain tables identifiying endianness. > Compiler shall defined TARGET_ENDIAN to "BIG" or "LITTLE", > or perhaps "big" or "little". > Granted, this buys very little. > > > Libraries shall not define jumpbuf, in a sense. > Compile shall define, something like: > TARGET_JUMPBUF_ELEMENT = "INTEGER" or "LONGINT". > aka jmpbuf alignment. > TARGET_JUMPBUF_SIZE = a decimal integer. > Leaving library to say: > TYPE jmpbuf = ARRAY [1..size] OF element > which m3makefile shall produce. > > > or perhaps even compiler shall inject the type itself, > as it injects a few things like INTERFACE Word functions. > > > or compiler shall define TARGET_JUMPBUF_ALIGN = 32 or 64, > and TARGET_JUMPBUF_SIZE in bytes > leaving m3makefile to map 32 to Ctypes.int and 64 to LONGINT itself. > > > The jumpbuf size/align bothers me more than word size and endianness. > Word size and endianness are more widely known to humans I think. > Endianness and word size are usually fairly obvious, though > not 100%. I didn't know the endianness of e.g. 88k, vax, and the > historically > terse names don't make it obvious. > > > However, let me not confuse "jumpbuf" with "Thread.State" or such. > Assume user threads stops using setjmp/longjmp and modify > or generalize proposal accordingly. > > Wonder if exception handling should use set/get/make/swapcontext > also?? > Assume jumpbuf might remain on some platforms? > > ? > > As well, one should be able to specify m3config on the command line. > One should be able to specify target on the command line. > Compiler shall take specified target and search /somehow/ for the > right config file. > Perhaps in path to cm3\..\config\target. > Don't probe like crazy -- not like I have it coded in Quake currently. > That really bites when there is more than one, and you edit the > wrong one. > > Probably something like, > probe for path to cm3\..\config\target. > > but if defined $CM3_CONFIG_DIRECTORY, search instead > $CM3_CONFIG_DIRECTORY\target. > however this is perhaps colon or semicolon delimited, so maybe > CM3_CONFIG_PATH. > (In particular, I have nearly all my config files in m3-sys/ > cminstall/src/config-no-install, > except NT386, which I'd really like to move, but will probably break > something and > doesn't seem important). > > Reasonable ideas? > > > Personally what I do is my Python scripts accept a target name > anywhere on the > command line, and if present, they set $M3CONFIG. > So I have what I want via python already. > You know, kind of a successful (imho) prototype, that should perhaps > be elevated > into the "real" stuff? > > > You know, make it easier and easier to contruct cross-capable > installations, > where switching targets is changing environment variables and/or > command lines, > and not editing/copying files. > > > If there isn't already, there should be a mode that doesn't run cm3cg. > And possibly can still ship. > That way /any/ system can do a bunch of cross-build "checking". > And the file system layout for creating a "boot" archive becomes > about the same as the layout of a "real" system. > Not like what I use -- I use one flat directory, since Modula-3 > requires that every..basically ever .i3, .m3, .o file have a unique > name. > (.i3 and .m3 can clash with each other, once each, that's it). > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 8 06:28:12 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 8 Jan 2009 05:28:12 +0000 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: <234B3116-4C98-470B-9929-3E2AC72D67DC@cs.purdue.edu> References: <20090103011227.vgpfs347400088sg@mail.elegosoft.com> <44664E56-D816-4A94-AD2E-96A0DB383DDF@cs.purdue.edu> <234B3116-4C98-470B-9929-3E2AC72D67DC@cs.purdue.edu> Message-ID: > [Jay] Some programs "better" with user threads > [Tony] Is this still true for modern kernel thread systems? I really don't know. Olaf /kind of/ indicated so (just in saying that it'd be a nice option to have). > [Jay] small stacks for many threads vs. larger stacks for calls to "the system" > [Tony] In a systems programming language like Modula-3 shouldn't threads have a relationship to the system? Some might just be doing computation? > This will need to be a link-time distinction. > I would hate to have both kernel and user thread code live in the same compiled run-time system. I understand the principle, and I don't have a working implementation to argue with, but I do find this surprising. In my mind, you take MODULE ThreadPThread EXPORTS Scheduler, Thread, etc. change it to MODULE ThreadPThread Exports SchedulerPThread, ThreadPThread, etc. and introduce MODULE Thread EXPORTS Scheduler, Thread, etc. PROCEDURE Fork()= BEGIN IF KernelThreads RETURN ThreadPThread.Fork(); ELSE RETURN ThreadPosix.Fork(); END; END Fork. And so on. The potential bloat would be, you get both copies of code, both copies of globals, possibly initialization (but this most likely be avoided) and if any of the types are transparent, such that caller can allocate them on the stack, you end up either with the larger of the two sizes, or using a heap allocation with a dynamically chosen size. It seems to be roughly one source file each of bloat. >[Tony]I see no problem with factoring out the threads subsystem as a separate library and linking accordingly. That would prevent the bloat, indeed. However, if you mean, like m3coreuserthreads.dll, m3corekernelthreads.dll, well, the vast bulk of each of those two files would be identical. You could maybe factor out m3kernelthreads.dll m3userthreads.dll out of m3core.dll and have m3core.dll dynamically chose one of them. That might be good. But personally..I'd like fewer .dlls, even if that means larger .dlls. >I would argue for user vs. kernel. I think you are right. Kind of like the NT386 platform argument. There are many real implementation choices, but they need not be all exposed to the user, esp. unless/until someone asks. If Cygwin pthreads made to work, and then if there are proponents of it over NT threads, and vice versa, add a switch, pick a default. In the meantime, I only made one of three options work. >And managing the state-space explosion that multiple choices might entail. I would like to avoid that. What do you mean? Growing types to the union? The globals and code bloat? Globals could all be pushed into a heap allocated pointer anyway, paying a perf cost that would unlikely be noticed. Again, I kind'a'thunk linking both in would be pretty ok, it's basically just one source file, but I haven't done it yet. Before I do this I need to be working on a platform with user threads, and then make them work, and then make them "switchable", and I want to bring up more platforms before I work on any user threads. AMD64_FREEBSD I think will be next. > I am not so sure, since it would entail some fairly low-level > and expensive decisions that would best instead be done at link-time. Again this doesn't agree with my /suspicion/ but I didn't do enough research/work to be all that informed.. > Actually, for non-standalone (dynamically-linked) code > we could make the choice at dynamic load time using the OS's support for dynamic library choice. I'd rather not use dlopen et. al. at least not until I understand various details of dynamic loading across more platforms. I always though Win32 did it all just about right, and then I find a surprising array of other implementation choices and options on other systems.. > I note that Solaris (but not Solaris Modula-3) currently lets > dynamically linked C programs choose among 3 different threads implementations dynamically. Too much of a good thing imho... At least in Windows, there are a lot of "in-process plugins", and often times, interoperating code has to agree on the same underlying pieces, so wherever there is a choice, is an opportunity to fail. For example, if I call malloc and give you the result to free, or I call fopen and give it to you to fwrite, we need to be using the same C runtime. Even Linux has a few to chose from -- glibc, dietlibc, uclibc, newlib, etc. If you push "plugins" out of process, things become usually easier. Then folks either interoperate through carefully formatted files / pipes, network protocols, or RPC, and not via function calls. I only knew of two threading libraries on Solaris, "pre-pthreads" and "pthreads". Oh, maybe "lwp" and "thr"? I was wondering -- these are all built on the same kernel threads, right? So if you use a mix of them in a process, you still get reasonable global scheduling, right? ie: There's no point in writing ThreadSolarisThis.m3 or ThreadSolarisThat.m3, ThreadPThread.m3 suffices plenty? Coming back to the bloat issue. If you make the transform I show, you could also have a variant of Thread.m3 that just calls ThreadPThread.m3 directly. That is, it should be easy (still not having done it) to alter the code to build both of m3coreboth.dll and m3corejustkernel.dll. They can both have the interface that accepts the request or mandate for user threads, and m3corejustkernel.dll could either ignore or error on it. Users could install one or the other .dll as m3core.dll. Of course you could alos build m3corejustuser.dll. (These are stupid names, I know.) I really need to try it and see, it's fairly hypothetical right now. It sounds like I might be missing something. But first some other things.. - Jay CC: wagner at elegosoft.com; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] dynamic chose between user/kernel threads?Date: Thu, 8 Jan 2009 13:51:15 +1100 Jay, perhaps you can provide some context and motivation for your proposals. I am unable to evaluate your proposals in the form of a simple laundry-list. On 8 Jan 2009, at 01:34, Jay wrote: I looked into this a bit..and I think it's actually pretty easy.It hardly churns the code even. I have other things I want to do first. In the meantime, specify the directive?There are actually a large number of subtle options. Can I ask for any of n libraries -- NT, pthreads, user threads? setjmp vs. context? Or is it just a boolean, user vs. kernel? Is the option to "favor" or "require" a certain library? Can I set it on libraries or only programs? What if the requests clash? Is it "Favor" or "Require"?Is it a function call or setting a global variable?I favor function call, but TARGET, WORD_SIZE, BUILD_DIR establish the other precedent,and either can work. Is it flags in the moduleinfo like incgc, gengc, or separate data thatthere is just one of in RTLinker? Probably separate data, unless it is allowed in libraries. What are the names of the libraries? "posix" and "pthreads" ? "user" and "kernel" ? "true" and "false" (or vice versa) ? Should NT implement user threads, using fibers? Presumably it works with both standalone and shared/dynamic programs.Presumably it is ok to always bloat up m3core.dll with both libraries.Presumably it is ok to have everyone pay a teeny tiny perf. That is, there is a microscopic dispatching layer, that everyone ends up going through, not chosing to link in one library or the other. And as part of this, whenever it happens, can we bump up the minimumbootstrap to a version that includes SchedulerPosix.DoesWaitPidYield()?Or does it become VAR Scheduler.UsingKerneThreads?(no, it should be a function; but naming matter remains). (ie. as I said, the decision currently is baked into m3core.dll, butnow it is also baked into sysutils.dll, but these should change together;m3core.dll should manage the knowledge). - Jay> Date: Sat, 3 Jan 2009 01:12:27 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] dynamic chose between user/kernel threads?> > An option to cm3 or a quake directive to use in the m3makefiles> would suffice in my opinion (and be a great improvement).> > Olaf> > Quoting Jay :> > >> > Should the user/kernel thread chose be available:> >> >> > On the command line to a Modula-3 executable (or even an executable > > where main is in another language, but which static or dynamic > > Modula-3 libs are used)?> >> >> > Via a quake directive when building programs?> >> >> > You know, imagine you have a bunch of Modula-3 programs and some but > > not all use a very large number of threads and benefit from > > userthreads.> >> >> > Currently the chose is locked into m3core when it is built.> >> >> > - Jay> > > -- > Olaf -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 8 07:36:44 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 8 Jan 2009 06:36:44 +0000 Subject: [M3devel] making Uerror "portable"? Message-ID: I've been thinking about "fixing" Uerrorto remove the system-dependentness of it. I have about given up. There are multiple easy options, but theyall have downsides that make me think itmight not be worth it. today it looks like: INTERFACE Uerror; CONST ENOFILE = 1; ENOMEM = 2; END Uerror; The values are intended the correct native values. There are a fair number of users. Fewer than 10 probably.They include switch/case statements, which requireconstants. The following are some of the possible changes,that make porting to basically any future systembe a no-op in this area, except for the occasional missing or possiblyequal errnos (if there is a switch in the C code; I ran into this case). - Change to VAR and initialize them in portable C code. disadvantages: more startup code possibly startup code runs too late more writable/written data (readonly data is best) slower to access not constant, not switchable, not source quite compatible You have to change the switch statements to "if ladders" (if/elseif/elseif/elseif). Compatible with most source, and incompatible source easily fixed. possible issues around "dynamic linking data" (not explained here, ask?) However not really a problem. More of a problem only on NT, and easily worked around just like is done for hand.obj. - change to VAR and const static initialize them in portable C "data" no additional startup code -- guaranteed initialized early enough no writable/written data slower to access not constant, not switchable, not source compatible (same as previous) same non-issue around dynamic linking of data - change to functions GetENOFILE(), GetENOMEM(), etc. slower to access definitely no problem dynamic linking easier to write the C code/data, no matter, the above are easy enough not constant, not switchable, not source compatible (similar to previous) - "translation"; introduce our own arbitrary values for any errno the system uses; change Cerrno.GetErrno to have a switch and translate from the native values to ours. This is fully source compatible, dynamic link compatible, in-between perf wise (slower to GetErrnor, but then constant and just as comparable/switchable), no initialization cost. Question then though what does any raised exception look like? Do the values get translated back? Or translated to strings? SetErrno translates back? Translation is at first simple and is unique among portable solutions in its source compatibility, but I am leary of it. I would rather a solution that traffics in unmodified native errnos values, but I don't that is viable with both constness and portability. To a large extent, translation is ok. If you look at SocketPosix.i3, it uses the errno very briefly to determine the next step to take. I don't think it ever returns or RAISEs it (or an exception containing it). But other parts of the system Fmt.Int(errno) and raise that, thus these become values that move through more of the system and therefore disagreement with the underlying system might show through. There is also question of how to chose "Max". Set it large, like 200? Set it "correctly"? Probably a better option is to make the cache that is currently Max-sized be instead small and fixed-size (e.g. 64), and "search" it quickly instead of "indexing" it very quickly, and always kick out the least recently used. I also have to check what the contents actually are, perhaps they are constant-initializable. Thoughts? I was somewhat keen to do something here, but have pretty much given up and will just generate Uerror.i3 for Solaris, NetBSD, FreeBSD, AIX, Irix, HP-UX, etc.. I might still be able to remove the Usignal and Ustat system-dependentness in m3core/src/unix, but Uerror will probably stand asis (in linux-common, openbsd-common, cygwin). In particular, I was putting off any more ports till I got the amount of work needed to port reduced to my satisfaction. I think I'm nearly there. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Thu Jan 8 09:19:26 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 08 Jan 2009 00:19:26 -0800 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: Your message of "Thu, 08 Jan 2009 05:28:12 GMT." Message-ID: <200901080819.n088JQtJ021157@camembert.async.caltech.edu> Jay writes: >--_659eacae-e435-4dfa-807c-8eaabce063a9_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > ... >PROCEDURE Fork()=3D >BEGIN IF KernelThreads > RETURN ThreadPThread.Fork()=3B > ELSE > RETURN ThreadPosix.Fork()=3B > END=3B > END Fork. ... If it's implemented properly, on many architectures LOCK should be at most a couple of instructions. I think adding a couple of branches to it may make a significant difference. On those architectures it really ought to be inlined, too... Here's the "quick path" for LockMutex under user threads: INC (inCritical); IF m.holder = NIL THEN <* ASSERT self # NIL *> m.holder := self; DEC (inCritical); RETURN; END; Mika From jay.krell at cornell.edu Thu Jan 8 10:46:28 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 8 Jan 2009 09:46:28 +0000 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: <200901080819.n088JQtJ021157@camembert.async.caltech.edu> References: Your message of "Thu, 08 Jan 2009 05:28:12 GMT." <200901080819.n088JQtJ021157@camembert.async.caltech.edu> Message-ID: Ok, then make it function pointers. That is a little more work. It won't likely be inlined, but I doubt it ever is currently anyway. A good implementation will have that be zero or one instructions, but it might impede the processor reading ahead in the instruction stream. Zero instructions if the interfaces are actually exposed as function pointers, one instruction if they remain functions that just jump through a pointer. One instruction being much easier to implement probably. (Actually conditional branches better preserve inlinability, but it takes a sophisticated compiler to benefit). > at most a couple of instructions It's pretty hard to do anything in 2 instructions..esp. without inlining.. call, return, budget gone. Here's the uncontended non-recursive EnterCriticalSection for comparison, not as an example of exactly what Modula-3 does, but as what is surely an example of a fairly well implemented lock (albeit the data structure is on the large size, and does support recursion). 0:000> u ntdll!RtlEnterCriticalSectionntdll!RtlEnterCriticalSection:00000000`76d87850 fff3 push rbx00000000`76d87852 4883ec20 sub rsp,20h00000000`76d87856 f00fba710800 lock btr dword ptr [rcx+8],000000000`76d8785c 488bd1 mov rdx,rcx00000000`76d8785f 0f832c58ffff jae 00000000`76d7d091 contention or recursion presumably 00000000`76d87865 65488b042530000000 mov rax,qword ptr gs:[30h]00000000`76d8786e 488b4848 mov rcx,qword ptr [rax+48h]00000000`76d87872 c7420c01000000 mov dword ptr [rdx+0Ch],100000000`76d87879 33c0 xor eax,eax00000000`76d8787b 48894a10 mov qword ptr [rdx+10h],rcx00000000`76d8787f 4883c420 add rsp,20h00000000`76d87883 5b pop rbx00000000`76d87884 c3 ret and then let's follow the contended/recursive path: 0:000> u 76d7d09100000000`76d7d091 65488b042530000000 mov rax,qword ptr gs:[30h]00000000`76d7d09a 488bd9 mov rbx,rcx00000000`76d7d09d 488b5048 mov rdx,qword ptr [rax+48h] Presumably this is a check to see if this thread already has the critical section.00000000`76d7d0a1 48395110 cmp qword ptr [rcx+10h],rdx00000000`76d7d0a5 0f851413feff jne 00000000`76d5e3bf if not wait for other guy00000000`76d7d0ab 83410c01 add dword ptr [rcx+0Ch],1 if so, increment recursion count and done00000000`76d7d0af 33c0 xor eax,eax00000000`76d7d0b1 4883c420 add rsp,20h00000000`76d7d0b5 5b pop rbx00000000`76d7d0b6 c3 ret contended path not shown. So that's 13 instructions for initial entry, 15 instructions for recursive entry. 0:000> u ntdll!RtlLeaveCriticalSectionntdll!RtlLeaveCriticalSection:00000000`76d87800 4883ec28 sub rsp,28h00000000`76d87804 83410cff add dword ptr [rcx+0Ch],0FFFFFFFFh00000000`76d87808 7535 jne ntdll!RtlLeaveCriticalSection+0x3f (00000000`76d8783f)00000000`76d8780a 48895c2430 mov qword ptr [rsp+30h],rbx00000000`76d8780f 48897c2420 mov qword ptr [rsp+20h],rdi00000000`76d87814 48c7411000000000 mov qword ptr [rcx+10h],000000000`76d8781c bf01000000 mov edi,100000000`76d87821 488bd9 mov rbx,rcx00000000`76d87824 f00fc17908 lock xadd dword ptr [rcx+8],edi00000000`76d87829 83c701 add edi,100000000`76d8782c 83ffff cmp edi,0FFFFFFFFh00000000`76d8782f 0f854380fdff jne 00000000`76d5f87800000000`76d87835 488b5c2430 mov rbx,qword ptr [rsp+30h]00000000`76d8783a 488b7c2420 mov rdi,qword ptr [rsp+20h]00000000`76d8783f 33c0 xor eax,eax00000000`76d87841 4883c428 add rsp,28h00000000`76d87845 c3 ret 6 instructions for recursive exit. 17 instructions for last exit..I assume the conditional branch is to wake waiters. x86: 0:000> u ntdll!RtlEnterCriticalSectionntdll!RtlEnterCriticalSection:76f03580 8bff mov edi,edi76f03582 55 push ebp76f03583 8bec mov ebp,esp76f03585 83ec0c sub esp,0Ch76f03588 56 push esi76f03589 57 push edi76f0358a 8b7d08 mov edi,dword ptr [ebp+8]76f0358d 8d7704 lea esi,[edi+4]76f03590 8bc6 mov eax,esi76f03592 f00fba3000 lock btr dword ptr [eax],076f03597 0f83bec60000 jae (76f0fc5b)76f0359d 64a118000000 mov eax,dword ptr fs:[00000018h]76f035a3 8b4824 mov ecx,dword ptr [eax+24h]76f035a6 894f0c mov dword ptr [edi+0Ch],ecx76f035a9 c7470801000000 mov dword ptr [edi+8],176f035b0 5f pop edi76f035b1 33c0 xor eax,eax76f035b3 5e pop esi76f035b4 8be5 mov esp,ebp76f035b6 5d pop ebp76f035b7 c20400 ret 4 21 instructions for initial entry 0:000> u 76f0fc5b76f0fc5b 648b0d18000000 mov ecx,dword ptr fs:[18h]76f0fc62 8b570c mov edx,dword ptr [edi+0Ch]76f0fc65 3b5124 cmp edx,dword ptr [ecx+24h]76f0fc68 0f8584de0000 jne 76f1daf276f0fc6e 83470801 add dword ptr [edi+8],176f0fc72 5f pop edi76f0fc73 33c0 xor eax,eax76f0fc75 5e pop esi76f0fc76 8be5 mov esp,ebp76f0fc78 5d pop ebp76f0fc79 c20400 ret 4 22 for recursive entry. ntdll!RtlLeaveCriticalSection:76f035c0 8bff mov edi,edi76f035c2 55 push ebp76f035c3 8bec mov ebp,esp76f035c5 56 push esi76f035c6 8b7508 mov esi,dword ptr [ebp+8]76f035c9 834608ff add dword ptr [esi+8],0FFFFFFFFh76f035cd 7525 jne ntdll!RtlLeaveCriticalSection+0x34 (76f035f4)76f035cf 53 push ebx76f035d0 57 push edi76f035d1 8d7e04 lea edi,[esi+4]76f035d4 c7460c00000000 mov dword ptr [esi+0Ch],076f035db bb01000000 mov ebx,176f035e0 8bc7 mov eax,edi76f035e2 f00fc118 lock xadd dword ptr [eax],ebx76f035e6 83c301 add ebx,176f035e9 83fbff cmp ebx,0FFFFFFFFh76f035ec 0f85d8a50100 jne 76f1dbca76f035f2 5f pop edi76f035f3 5b pop ebx76f035f4 33c0 xor eax,eax76f035f6 5e pop esi76f035f7 5d pop ebp76f035f8 c20400 ret 4 11 instructions for recursive exit.23 instructions for last exit, I guess, without waiters. - Jay> To: jay.krell at cornell.edu> Date: Thu, 8 Jan 2009 00:19:26 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] dynamic chose between user/kernel threads?> > Jay writes:> >--_659eacae-e435-4dfa-807c-8eaabce063a9_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> ...> >PROCEDURE Fork()=3D> >BEGIN IF KernelThreads> > RETURN ThreadPThread.Fork()=3B> > ELSE> > RETURN ThreadPosix.Fork()=3B> > END=3B> > END Fork.> ...> > If it's implemented properly, on many architectures LOCK should be> at most a couple of instructions. I think adding a couple of> branches to it may make a significant difference. On those> architectures it really ought to be inlined, too...> > Here's the "quick path" for LockMutex under user threads:> > INC (inCritical);> IF m.holder = NIL THEN> <* ASSERT self # NIL *>> m.holder := self;> DEC (inCritical);> RETURN;> END;> > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jan 8 14:38:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 08 Jan 2009 14:38:25 +0100 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: <234B3116-4C98-470B-9929-3E2AC72D67DC@cs.purdue.edu> References: <20090103011227.vgpfs347400088sg@mail.elegosoft.com> <44664E56-D816-4A94-AD2E-96A0DB383DDF@cs.purdue.edu> <234B3116-4C98-470B-9929-3E2AC72D67DC@cs.purdue.edu> Message-ID: <20090108143825.2rggu3h0xkwgws80@mail.elegosoft.com> As I noted earlier, I think that a link-time choice between (M3) user and system (kernel/p) threads would be completely satisfactory. Default could be pthreads/system threads, and cm3 -uthreads or cm3 -m3threads could substitute the old but efficient M3 implementation (with proper getcontext/makecontext for all target platforms ;-). Olaf Quoting Tony Hosking : > On 8 Jan 2009, at 14:10, Jay wrote: > >> Olaf understood the point (I think). :) >> >> Some programs, people say, and I believe, run "better" (faster, >> without running out of address space) with user threads instead of >> kernel threads. > > Is this still true for modern kernel thread systems? > >> On systems that have both. >> A good example might be a program that needs lots of threads and >> therefore small stacks, and the kernel threads, due to code below >> the Modula-3 runtime, might force fairly large stacks. (Such a >> program might have to adjust thread size differently for different >> threads, and only call into the underlying system on threads with >> larger stacks.) > > In a systems programming language like Modula-3 shouldn't threads have > a relationship to the system? > >> It might be nice for such programs to be able to mandate or request >> (two slightly different things) that the user thread library be >> used by them, even if the platform's default is to use kernel >> threads. > > This will need to be a link-time distinction. I would hate to have > both kernel and user thread code live in the same compiled run-time > system. > >> The only minor detail then is, how to express the request, and the >> precise meaning. >> It is a request or a mandate? > > I see no problem with factoring out the threads subsystem as a > separate library and linking accordingly. > >> As well, if the issue is address space, sholud there a "built in" >> way to only make the request on 32bit platforms, or should uses >> manually say if equal (WORD_SIZE, "32BITS")? >> >> Is it a boolean or an enum? >> Cygwin might conceivably get pthreads support (Cygwin has it, but >> Modula-3/Cygwin does not). >> Therefore, is the choice among "posix" threads, "pthreads" and "NT" >> threads? >> Or just user vs. kernel? > > I would argue for user vs. kernel. > >> I think the "important" part here is easy to implement. >> But again.. > > And managing the state-space explosion that multiple choices might > entail. I would like to avoid that. > >> The easier straightforward implementation always links both pieces >> of code in and makes a choice early in startup as to which to use, >> either setting a boolean, or an enum, or a pointer to a record of >> function pointers. This means that people that don't care to ever >> use user threads pay a small price, in code bloat and probably in >> a few extra instructions per certain functions. This is probably >> ok. > > I am not so sure, since it would entail some fairly low-level and > expensive decisions that would best instead be done at link-time. > >> However if that was not ok, the choice could be made at link time >> and only be supported for standalone programs. > > Actually, for non-standalone (dynamically-linked) code we could make > the choice at dynamic load time using the OS's support for dynamic > library choice. > > I note that Solaris (but not Solaris Modula-3) currently lets > dynamically linked C programs choose among 3 different threads > implementations dynamically. > >> >> >> - Jay >> >> >> >> >> CC: wagner at elegosoft.com; m3devel at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Subject: Re: [M3devel] dynamic chose between user/kernel threads? >> Date: Thu, 8 Jan 2009 13:51:15 +1100 >> >> >> Jay, perhaps you can provide some context and motivation for your >> proposals. I am unable to evaluate your proposals in the form of a >> simple laundry-list. >> >> On 8 Jan 2009, at 01:34, Jay wrote: >> >> I looked into this a bit..and I think it's actually pretty easy. >> It hardly churns the code even. >> >> >> I have other things I want to do first. >> >> >> In the meantime, specify the directive? >> There are actually a large number of subtle options. >> >> >> Can I ask for any of n libraries -- NT, pthreads, user threads? >> setjmp vs. context? Or is it just a boolean, user vs. kernel? >> >> >> Is the option to "favor" or "require" a certain library? >> >> >> Can I set it on libraries or only programs? >> What if the requests clash? >> >> >> Is it "Favor" or "Require"? >> Is it a function call or setting a global variable? >> I favor function call, but TARGET, WORD_SIZE, BUILD_DIR establish >> the other precedent, >> and either can work. >> >> Is it flags in the moduleinfo like incgc, gengc, or separate data that >> there is just one of in RTLinker? Probably separate data, unless it >> is allowed in libraries. >> >> >> What are the names of the libraries? >> "posix" and "pthreads" ? >> "user" and "kernel" ? >> "true" and "false" (or vice versa) ? >> >> >> Should NT implement user threads, using fibers? >> >> >> Presumably it works with both standalone and shared/dynamic programs. >> Presumably it is ok to always bloat up m3core.dll with both libraries. >> Presumably it is ok to have everyone pay a teeny tiny perf. >> That is, there is a microscopic dispatching layer, that everyone >> ends up going through, not chosing to link in one library or the other. >> >> >> And as part of this, whenever it happens, can we bump up the minimum >> bootstrap to a version that includes SchedulerPosix.DoesWaitPidYield()? >> Or does it become VAR Scheduler.UsingKerneThreads? >> (no, it should be a function; but naming matter remains). >> >> >> (ie. as I said, the decision currently is baked into m3core.dll, but >> now it is also baked into sysutils.dll, but these should change together; >> m3core.dll should manage the knowledge). >> >> >> - Jay >> >> >>> Date: Sat, 3 Jan 2009 01:12:27 +0100 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] dynamic chose between user/kernel threads? >>> >>> An option to cm3 or a quake directive to use in the m3makefiles >>> would suffice in my opinion (and be a great improvement). >>> >>> Olaf >>> >>> Quoting Jay : >>> >>> > >>> > Should the user/kernel thread chose be available: >>> > >>> > >>> > On the command line to a Modula-3 executable (or even an executable >>> > where main is in another language, but which static or dynamic >>> > Modula-3 libs are used)? >>> > >>> > >>> > Via a quake directive when building programs? >>> > >>> > >>> > You know, imagine you have a bunch of Modula-3 programs and some but >>> > not all use a very large number of threads and benefit from >>> > userthreads. >>> > >>> > >>> > Currently the chose is locked into m3core when it is built. >>> > >>> > >>> > - Jay >>> >>> >>> -- >>> Olaf >> >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jan 8 15:51:05 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 8 Jan 2009 14:51:05 +0000 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: <20090108143825.2rggu3h0xkwgws80@mail.elegosoft.com> References: <20090103011227.vgpfs347400088sg@mail.elegosoft.com> <44664E56-D816-4A94-AD2E-96A0DB383DDF@cs.purdue.edu> <234B3116-4C98-470B-9929-3E2AC72D67DC@cs.purdue.edu> <20090108143825.2rggu3h0xkwgws80@mail.elegosoft.com> Message-ID: I think you didn't realize some of what I was lumping into "link time". It could mean "constructing main to pass a parameter to RTLinker". Or setting a flag in the Main module (like how gengc/incgc flags are set in all modules, but this is a more difficult and likely wasteful change, no need to burn a bit in all modules, just the main module). I still think function pointers would suffice, costing zero or one instruction per function call.. But I haven't tried it yet. Systems with "build variants" tend to get "explosive" -- combinatorial explosions of "configurations". Boost is good (bad) example of this. - Jay> Date: Thu, 8 Jan 2009 14:38:25 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] dynamic chose between user/kernel threads?> > As I noted earlier, I think that a link-time choice between> (M3) user and system (kernel/p) threads would be completely> satisfactory. Default could be pthreads/system threads, and> cm3 -uthreads or cm3 -m3threads could substitute the old but> efficient M3 implementation (with proper getcontext/makecontext> for all target platforms ;-).> > Olaf> > Quoting Tony Hosking :> > > On 8 Jan 2009, at 14:10, Jay wrote:> >> >> Olaf understood the point (I think). :)> >>> >> Some programs, people say, and I believe, run "better" (faster, > >> without running out of address space) with user threads instead of > >> kernel threads.> >> > Is this still true for modern kernel thread systems?> >> >> On systems that have both.> >> A good example might be a program that needs lots of threads and > >> therefore small stacks, and the kernel threads, due to code below > >> the Modula-3 runtime, might force fairly large stacks. (Such a > >> program might have to adjust thread size differently for different > >> threads, and only call into the underlying system on threads with > >> larger stacks.)> >> > In a systems programming language like Modula-3 shouldn't threads have> > a relationship to the system?> >> >> It might be nice for such programs to be able to mandate or request > >> (two slightly different things) that the user thread library be > >> used by them, even if the platform's default is to use kernel > >> threads.> >> > This will need to be a link-time distinction. I would hate to have> > both kernel and user thread code live in the same compiled run-time> > system.> >> >> The only minor detail then is, how to express the request, and the > >> precise meaning.> >> It is a request or a mandate?> >> > I see no problem with factoring out the threads subsystem as a> > separate library and linking accordingly.> >> >> As well, if the issue is address space, sholud there a "built in" > >> way to only make the request on 32bit platforms, or should uses > >> manually say if equal (WORD_SIZE, "32BITS")?> >>> >> Is it a boolean or an enum?> >> Cygwin might conceivably get pthreads support (Cygwin has it, but > >> Modula-3/Cygwin does not).> >> Therefore, is the choice among "posix" threads, "pthreads" and "NT" > >> threads?> >> Or just user vs. kernel?> >> > I would argue for user vs. kernel.> >> >> I think the "important" part here is easy to implement.> >> But again..> >> > And managing the state-space explosion that multiple choices might> > entail. I would like to avoid that.> >> >> The easier straightforward implementation always links both pieces > >> of code in and makes a choice early in startup as to which to use, > >> either setting a boolean, or an enum, or a pointer to a record of > >> function pointers. This means that people that don't care to ever > >> use user threads pay a small price, in code bloat and probably in > >> a few extra instructions per certain functions. This is probably > >> ok.> >> > I am not so sure, since it would entail some fairly low-level and> > expensive decisions that would best instead be done at link-time.> >> >> However if that was not ok, the choice could be made at link time > >> and only be supported for standalone programs.> >> > Actually, for non-standalone (dynamically-linked) code we could make> > the choice at dynamic load time using the OS's support for dynamic> > library choice.> >> > I note that Solaris (but not Solaris Modula-3) currently lets> > dynamically linked C programs choose among 3 different threads> > implementations dynamically.> >> >>> >>> >> - Jay> >>> >>> >>> >>> >> CC: wagner at elegosoft.com; m3devel at elegosoft.com> >> From: hosking at cs.purdue.edu> >> To: jay.krell at cornell.edu> >> Subject: Re: [M3devel] dynamic chose between user/kernel threads?> >> Date: Thu, 8 Jan 2009 13:51:15 +1100> >>> >>> >> Jay, perhaps you can provide some context and motivation for your > >> proposals. I am unable to evaluate your proposals in the form of a > >> simple laundry-list.> >>> >> On 8 Jan 2009, at 01:34, Jay wrote:> >>> >> I looked into this a bit..and I think it's actually pretty easy.> >> It hardly churns the code even.> >>> >>> >> I have other things I want to do first.> >>> >>> >> In the meantime, specify the directive?> >> There are actually a large number of subtle options.> >>> >>> >> Can I ask for any of n libraries -- NT, pthreads, user threads?> >> setjmp vs. context? Or is it just a boolean, user vs. kernel?> >>> >>> >> Is the option to "favor" or "require" a certain library?> >>> >>> >> Can I set it on libraries or only programs?> >> What if the requests clash?> >>> >>> >> Is it "Favor" or "Require"?> >> Is it a function call or setting a global variable?> >> I favor function call, but TARGET, WORD_SIZE, BUILD_DIR establish > >> the other precedent,> >> and either can work.> >>> >> Is it flags in the moduleinfo like incgc, gengc, or separate data that> >> there is just one of in RTLinker? Probably separate data, unless it > >> is allowed in libraries.> >>> >>> >> What are the names of the libraries?> >> "posix" and "pthreads" ?> >> "user" and "kernel" ?> >> "true" and "false" (or vice versa) ?> >>> >>> >> Should NT implement user threads, using fibers?> >>> >>> >> Presumably it works with both standalone and shared/dynamic programs.> >> Presumably it is ok to always bloat up m3core.dll with both libraries.> >> Presumably it is ok to have everyone pay a teeny tiny perf.> >> That is, there is a microscopic dispatching layer, that everyone> >> ends up going through, not chosing to link in one library or the other.> >>> >>> >> And as part of this, whenever it happens, can we bump up the minimum> >> bootstrap to a version that includes SchedulerPosix.DoesWaitPidYield()?> >> Or does it become VAR Scheduler.UsingKerneThreads?> >> (no, it should be a function; but naming matter remains).> >>> >>> >> (ie. as I said, the decision currently is baked into m3core.dll, but> >> now it is also baked into sysutils.dll, but these should change together;> >> m3core.dll should manage the knowledge).> >>> >>> >> - Jay> >>> >>> >>> Date: Sat, 3 Jan 2009 01:12:27 +0100> >>> From: wagner at elegosoft.com> >>> To: m3devel at elegosoft.com> >>> Subject: Re: [M3devel] dynamic chose between user/kernel threads?> >>>> >>> An option to cm3 or a quake directive to use in the m3makefiles> >>> would suffice in my opinion (and be a great improvement).> >>>> >>> Olaf> >>>> >>> Quoting Jay :> >>>> >>> >> >>> > Should the user/kernel thread chose be available:> >>> >> >>> >> >>> > On the command line to a Modula-3 executable (or even an executable> >>> > where main is in another language, but which static or dynamic> >>> > Modula-3 libs are used)?> >>> >> >>> >> >>> > Via a quake directive when building programs?> >>> >> >>> >> >>> > You know, imagine you have a bunch of Modula-3 programs and some but> >>> > not all use a very large number of threads and benefit from> >>> > userthreads.> >>> >> >>> >> >>> > Currently the chose is locked into m3core when it is built.> >>> >> >>> >> >>> > - Jay> >>>> >>>> >>> --> >>> Olaf> >>> >>> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Jan 9 01:01:26 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 9 Jan 2009 11:01:26 +1100 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: <20090108143825.2rggu3h0xkwgws80@mail.elegosoft.com> References: <20090103011227.vgpfs347400088sg@mail.elegosoft.com> <44664E56-D816-4A94-AD2E-96A0DB383DDF@cs.purdue.edu> <234B3116-4C98-470B-9929-3E2AC72D67DC@cs.purdue.edu> <20090108143825.2rggu3h0xkwgws80@mail.elegosoft.com> Message-ID: I err on the side of simplicity, until there is an obvious need for adding complexity. In this case, I concur with Olaf that the most we would need is a simple link-time switch. 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 9 Jan 2009, at 00:38, Olaf Wagner wrote: > As I noted earlier, I think that a link-time choice between > (M3) user and system (kernel/p) threads would be completely > satisfactory. Default could be pthreads/system threads, and > cm3 -uthreads or cm3 -m3threads could substitute the old but > efficient M3 implementation (with proper getcontext/makecontext > for all target platforms ;-). > > Olaf > > Quoting Tony Hosking : > >> On 8 Jan 2009, at 14:10, Jay wrote: >> >>> Olaf understood the point (I think). :) >>> >>> Some programs, people say, and I believe, run "better" (faster, >>> without running out of address space) with user threads instead >>> of kernel threads. >> >> Is this still true for modern kernel thread systems? >> >>> On systems that have both. >>> A good example might be a program that needs lots of threads and >>> therefore small stacks, and the kernel threads, due to code >>> below the Modula-3 runtime, might force fairly large stacks. >>> (Such a program might have to adjust thread size differently for >>> different threads, and only call into the underlying system on >>> threads with larger stacks.) >> >> In a systems programming language like Modula-3 shouldn't threads >> have >> a relationship to the system? >> >>> It might be nice for such programs to be able to mandate or >>> request (two slightly different things) that the user thread >>> library be used by them, even if the platform's default is to >>> use kernel threads. >> >> This will need to be a link-time distinction. I would hate to have >> both kernel and user thread code live in the same compiled run-time >> system. >> >>> The only minor detail then is, how to express the request, and >>> the precise meaning. >>> It is a request or a mandate? >> >> I see no problem with factoring out the threads subsystem as a >> separate library and linking accordingly. >> >>> As well, if the issue is address space, sholud there a "built >>> in" way to only make the request on 32bit platforms, or should >>> uses manually say if equal (WORD_SIZE, "32BITS")? >>> >>> Is it a boolean or an enum? >>> Cygwin might conceivably get pthreads support (Cygwin has it, >>> but Modula-3/Cygwin does not). >>> Therefore, is the choice among "posix" threads, "pthreads" and >>> "NT" threads? >>> Or just user vs. kernel? >> >> I would argue for user vs. kernel. >> >>> I think the "important" part here is easy to implement. >>> But again.. >> >> And managing the state-space explosion that multiple choices might >> entail. I would like to avoid that. >> >>> The easier straightforward implementation always links both >>> pieces of code in and makes a choice early in startup as to >>> which to use, either setting a boolean, or an enum, or a pointer >>> to a record of function pointers. This means that people that >>> don't care to ever use user threads pay a small price, in code >>> bloat and probably in a few extra instructions per certain >>> functions. This is probably ok. >> >> I am not so sure, since it would entail some fairly low-level and >> expensive decisions that would best instead be done at link-time. >> >>> However if that was not ok, the choice could be made at link >>> time and only be supported for standalone programs. >> >> Actually, for non-standalone (dynamically-linked) code we could make >> the choice at dynamic load time using the OS's support for dynamic >> library choice. >> >> I note that Solaris (but not Solaris Modula-3) currently lets >> dynamically linked C programs choose among 3 different threads >> implementations dynamically. >> >>> >>> >>> - Jay >>> >>> >>> >>> >>> CC: wagner at elegosoft.com; m3devel at elegosoft.com >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Subject: Re: [M3devel] dynamic chose between user/kernel threads? >>> Date: Thu, 8 Jan 2009 13:51:15 +1100 >>> >>> >>> Jay, perhaps you can provide some context and motivation for >>> your proposals. I am unable to evaluate your proposals in the >>> form of a simple laundry-list. >>> >>> On 8 Jan 2009, at 01:34, Jay wrote: >>> >>> I looked into this a bit..and I think it's actually pretty easy. >>> It hardly churns the code even. >>> >>> >>> I have other things I want to do first. >>> >>> >>> In the meantime, specify the directive? >>> There are actually a large number of subtle options. >>> >>> >>> Can I ask for any of n libraries -- NT, pthreads, user threads? >>> setjmp vs. context? Or is it just a boolean, user vs. kernel? >>> >>> >>> Is the option to "favor" or "require" a certain library? >>> >>> >>> Can I set it on libraries or only programs? >>> What if the requests clash? >>> >>> >>> Is it "Favor" or "Require"? >>> Is it a function call or setting a global variable? >>> I favor function call, but TARGET, WORD_SIZE, BUILD_DIR >>> establish the other precedent, >>> and either can work. >>> >>> Is it flags in the moduleinfo like incgc, gengc, or separate data >>> that >>> there is just one of in RTLinker? Probably separate data, unless >>> it is allowed in libraries. >>> >>> >>> What are the names of the libraries? >>> "posix" and "pthreads" ? >>> "user" and "kernel" ? >>> "true" and "false" (or vice versa) ? >>> >>> >>> Should NT implement user threads, using fibers? >>> >>> >>> Presumably it works with both standalone and shared/dynamic >>> programs. >>> Presumably it is ok to always bloat up m3core.dll with both >>> libraries. >>> Presumably it is ok to have everyone pay a teeny tiny perf. >>> That is, there is a microscopic dispatching layer, that everyone >>> ends up going through, not chosing to link in one library or the >>> other. >>> >>> >>> And as part of this, whenever it happens, can we bump up the minimum >>> bootstrap to a version that includes >>> SchedulerPosix.DoesWaitPidYield()? >>> Or does it become VAR Scheduler.UsingKerneThreads? >>> (no, it should be a function; but naming matter remains). >>> >>> >>> (ie. as I said, the decision currently is baked into m3core.dll, but >>> now it is also baked into sysutils.dll, but these should change >>> together; >>> m3core.dll should manage the knowledge). >>> >>> >>> - Jay >>> >>> >>>> Date: Sat, 3 Jan 2009 01:12:27 +0100 >>>> From: wagner at elegosoft.com >>>> To: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] dynamic chose between user/kernel threads? >>>> >>>> An option to cm3 or a quake directive to use in the m3makefiles >>>> would suffice in my opinion (and be a great improvement). >>>> >>>> Olaf >>>> >>>> Quoting Jay : >>>> >>>> > >>>> > Should the user/kernel thread chose be available: >>>> > >>>> > >>>> > On the command line to a Modula-3 executable (or even an >>>> executable >>>> > where main is in another language, but which static or dynamic >>>> > Modula-3 libs are used)? >>>> > >>>> > >>>> > Via a quake directive when building programs? >>>> > >>>> > >>>> > You know, imagine you have a bunch of Modula-3 programs and >>>> some but >>>> > not all use a very large number of threads and benefit from >>>> > userthreads. >>>> > >>>> > >>>> > Currently the chose is locked into m3core when it is built. >>>> > >>>> > >>>> > - Jay >>>> >>>> >>>> -- >>>> Olaf >>> >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 11 04:02:41 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Jan 2009 03:02:41 +0000 Subject: [M3devel] fw: alignment greater than longint? In-Reply-To: <20090111004447.5014E10D535B@birch.elegosoft.com> References: <20090111004447.5014E10D535B@birch.elegosoft.com> Message-ID: Well, I'm not a fan of cloning headers..and in this case it doesn't matter anyway, and I'm actively uncloning them, but a way to be explicit about alignment might be good..? PPC_LINUX setjmp.h declares jmpbuf to be aligned to 16, though the comments say that 4 aligned suffices. I made it have an array of LONGINT to get as close as I could. - Jay> Date: Sun, 11 Jan 2009 01:44:47 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > 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> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 11 09:58:55 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Jan 2009 08:58:55 +0000 Subject: [M3devel] making Uerror "portable"? Message-ID: I still find pushing the system dependencies and cloned headers out of the system very tempting. To reduce what it takes to port to other systems, to raise the confidence of the correctness of any port, to keep ports correct in the face of possible underlying change. I think I'll change the case statements to if/else ladders and the consts to vars, that are actually statically initialized in C. This treatment is reasonable for other constants that remain in the cloned headers, system dependent or otherwise. - Jay From: jay.krell at cornell.eduTo: m3devel at elegosoft.comSubject: making Uerror "portable"?Date: Thu, 8 Jan 2009 06:36:44 +0000 I've been thinking about "fixing" Uerrorto remove the system-dependentness of it. I have about given up. There are multiple easy options, but theyall have downsides that make me think itmight not be worth it. today it looks like: INTERFACE Uerror;CONST ENOFILE = 1; ENOMEM = 2;END Uerror; The values are intended the correct native values.There are a fair number of users.Fewer than 10 probably.They include switch/case statements, which requireconstants. The following are some of the possible changes,that make porting to basically any future systembe a no-op in this area, except for the occasional missing or possiblyequal errnos (if there is a switch in the C code; I ran into this case). - Change to VAR and initialize them in portable C code. disadvantages: more startup code possibly startup code runs too late more writable/written data (readonly data is best) slower to access not constant, not switchable, not source quite compatible You have to change the switch statements to "if ladders" (if/elseif/elseif/elseif). Compatible with most source, and incompatible source easily fixed. possible issues around "dynamic linking data" (not explained here, ask?) However not really a problem. More of a problem only on NT, and easily worked around just like is done for hand.obj. - change to VAR and const static initialize them in portable C "data" no additional startup code -- guaranteed initialized early enough no writable/written data slower to access not constant, not switchable, not source compatible (same as previous) same non-issue around dynamic linking of data - change to functions GetENOFILE(), GetENOMEM(), etc. slower to access definitely no problem dynamic linking easier to write the C code/data, no matter, the above are easy enough not constant, not switchable, not source compatible (similar to previous) - "translation"; introduce our own arbitrary values for any errno the system uses; change Cerrno.GetErrno to have a switch and translate from the native values to ours. This is fully source compatible, dynamic link compatible, in-between perf wise (slower to GetErrnor, but then constant and just as comparable/switchable), no initialization cost. Question then though what does any raised exception look like? Do the values get translated back? Or translated to strings? SetErrno translates back? Translation is at first simple and is unique among portable solutions in its source compatibility, but I am leary of it. I would rather a solution that traffics in unmodified native errnos values, but I don't that is viable with both constness and portability. To a large extent, translation is ok. If you look at SocketPosix.i3, it uses the errno very briefly to determine the next step to take. I don't think it ever returns or RAISEs it (or an exception containing it). But other parts of the system Fmt.Int(errno) and raise that, thus these become values that move through more of the system and therefore disagreement with the underlying system might show through. There is also question of how to chose "Max". Set it large, like 200? Set it "correctly"? Probably a better option is to make the cache that is currently Max-sized be instead small and fixed-size (e.g. 64), and "search" it quickly instead of "indexing" it very quickly, and always kick out the least recently used. I also have to check what the contents actually are, perhaps they are constant-initializable. Thoughts? I was somewhat keen to do something here, but have pretty much given up and will just generate Uerror.i3 for Solaris, NetBSD, FreeBSD, AIX, Irix, HP-UX, etc.. I might still be able to remove the Usignal and Ustat system-dependentness in m3core/src/unix, but Uerror will probably stand asis (in linux-common, openbsd-common, cygwin). In particular, I was putting off any more ports till I got the amount of work neededto port reduced to my satisfaction. I think I'm nearly there. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 11 13:57:13 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Jan 2009 12:57:13 +0000 Subject: [M3devel] Juno (X) networking problem on AMD64_FREEBSD Message-ID: Hi. Unix network programming question.. AMD64_FREEBSD: $DISPLAY is set to point back to Cygwin host.It works for PPC_LINUX. [jay at fbsdamd64a /cm3/bin]$ ./Juno ****** runtime error:*** Exception "IPError.FatalError" not in RAISES list*** file "../src/common/IPError.m3", line 27*** Abort trap: 6 (core dumped)[jay at fbsdamd64a /cm3/bin]$ IP.m3: PROCEDURE GetHostAddr(): Address = VAR hname: ARRAY [0..255] OF CHAR; BEGIN LOCK mu DO IF Unix.gethostname(ADR(hname[0]), BYTESIZE(hname)) # 0 THEN IPError.Die (); END; VAR h := Unetdb.gethostbyname(ADR(hname[0])); BEGIN IF h = NIL THEN IPError.Die(); END; RETURN GetAddress(h); END; END; END GetHostAddr; PROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Address = VAR ua: Uin.struct_in_addr; BEGIN <* ASSERT ent.h_length <= BYTESIZE(Address) *> ua := LOOPHOLE(ent.h_addr_list, UNTRACED REF UNTRACED REF Uin.struct_in_addr)^^; RETURN LOOPHOLE(ua.s_addr, Address); END GetAddress; gethostbyname is failing. Analogous C code also fails: [jay at fbsdamd64a /cm3/bin]$ cat ~/5.c#include #include #include #include typedef struct hostent hostent_t; int main(){ char hostname[200]; hostent_t* h; int i; i = gethostname(hostname, 200); assert(i == 0); printf("hostname: %s\n", hostname); h = gethostbyname(hostname); herror("foo"); printf("%p %d %d\n", h, errno, h_errno); assert(h); return 0;} herror says "unknown host". Stack is: at ../src/runtime/ex_frame/RTExFrame.m3:58#13 0x0000000801a7f2b3 in RTHooks__Raise (M3_AJWxb1_ex=Error accessing memory address 0x8000ffffd278: Bad address.) at ../src/runtime/common/RTHooks.m3:79#14 0x000000080169c8d3 in IPError__Die () at ../src/common/IPError.m3:27#15 0x0000000801698a3e in IP__GetHostAddr (M3_BCxjPn__result=Error accessing memory address 0x8000ffffd338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x00000008012133d0 in XSharedMem__SameHost (M3_AQuuui_trsl=Error accessing memory address 0x8000ffffd4d8: Bad address.) at ../src/xvbt/XSharedMem.m3:96#17 0x0000000801212ab7 in XSharedMem__InitXClient (M3_AQuuui_v=Error accessing memory address 0x8000ffffd648: Bad address.) at ../src/xvbt/XSharedMem.m3:29#18 0x0000000801211819 in XExtensions__InitXClient (M3_AQuuui_xclient=Error accessing memory address 0x8000ffffd7f8: Bad address.) at ../src/xvbt/XExtensions.m3:14#19 0x00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst=0x1879b, M3_AQuuui_trsl=0x6) at ../src/xvbt/XClientF.m3:583---Type to continue, or q to quit---(More stack frames follow...)(gdb) (* return TRUE if server and client are on same host *)PROCEDURE SameHost (trsl: XClient.T): BOOLEAN = VAR display := DisplayHost(trsl); displayAddr: IP.Address; BEGIN IF display = NIL THEN RETURN TRUE; END; TRY IF NOT IP.GetHostByName(display, displayAddr) THEN RETURN FALSE; END; RETURN displayAddr = IP.GetHostAddr(); EXCEPT | IP.Error => RETURN FALSE; END; END SameHost; Thoughts? Perhaps my network isn't setup well, like I should add the local machine to /etc/hosts.I think this can be made to fail gracefully though.It seems like it has nothing to do with AMD64_FREEBSD, but could have to do with FreeBSD. Seems like SocketPosix has nearly the exact same code but appearsmore forgiving.. IOError instead of Fatal? SocketPosix.m3: PROCEDURE GetHostAddr (): Address RAISES {OSError.E} = VAR host : ARRAY [0..255] OF CHAR; info : Unetdb.struct_hostent_star; ua : Uin.struct_in_addr; BEGIN IF Unix.gethostname (ADR (host[0]), BYTESIZE (host)) # 0 THEN IOError (Unexpected); END; info := Unetdb.gethostbyname (ADR (host[0])); IF info = NIL THEN IOError (Unexpected); END; <* ASSERT info.h_length <= BYTESIZE (Address) *> ua := LOOPHOLE(info.h_addr_list, UNTRACED REF UNTRACED REF Uin.struct_in_addr)^^; RETURN LOOPHOLE (ua.s_addr, Address); END GetHostAddr; It is again disappointing to see such code duplication. I guess SameHost can duplicate the logic to predict the error state and return false upon error? Duplicating the logic for a third time. :( - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 11 14:37:37 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Jan 2009 13:37:37 +0000 Subject: [M3devel] Juno (X) networking problem on AMD64_FREEBSD In-Reply-To: References: Message-ID: I commited a workaround here, that introduces essentially a third copy of relevant code. Anyone have further ideas? (* This is a clone of IP.GetHostAddr that returns TRUE if IP.GetHostAddr is likely to succeed and FALSE if IP.GetHostAddr is likely to fail. *) VAR mu := NEW(MUTEX); PROCEDURE PredictIPGetHostAddrSuccess(): BOOLEAN = VAR hname: ARRAY [0..255] OF CHAR; BEGIN LOCK mu DO RETURN (Unix.gethostname(ADR(hname[0]), BYTESIZE(hname)) = 0) AND (Unetdb.gethostbyname(ADR(hname[0])) # NIL); END; END PredictIPGetHostAddrSuccess; (* return TRUE if server and client are on same host *) PROCEDURE SameHost (trsl: XClient.T): BOOLEAN = VAR display := DisplayHost(trsl); displayAddr: IP.Address; BEGIN IF display = NIL THEN RETURN TRUE; END; TRY IF NOT IP.GetHostByName(display, displayAddr) THEN RETURN FALSE; END; (* IP.GetHostAddr can return a fatal exception; try to avoid that by predicting its success. *) IF NOT PredictIPGetHostAddrSuccess() THEN RETURN FALSE; END; RETURN displayAddr = IP.GetHostAddr(); EXCEPT | IP.Error => RETURN FALSE; END; END SameHost; - Jay From: jay.krell at cornell.eduTo: m3devel at elegosoft.comDate: Sun, 11 Jan 2009 12:57:13 +0000Subject: [M3devel] Juno (X) networking problem on AMD64_FREEBSD Hi. Unix network programming question..AMD64_FREEBSD:$DISPLAY is set to point back to Cygwin host.It works for PPC_LINUX.[jay at fbsdamd64a /cm3/bin]$ ./Juno****** runtime error:*** Exception "IPError.FatalError" not in RAISES list*** file "../src/common/IPError.m3", line 27***Abort trap: 6 (core dumped)[jay at fbsdamd64a /cm3/bin]$IP.m3: PROCEDURE GetHostAddr(): Address = VAR hname: ARRAY [0..255] OF CHAR; BEGIN LOCK mu DO IF Unix.gethostname(ADR(hname[0]), BYTESIZE(hname)) # 0 THEN IPError.Die (); END; VAR h := Unetdb.gethostbyname(ADR(hname[0])); BEGIN IF h = NIL THEN IPError.Die(); END; RETURN GetAddress(h); END; END; END GetHostAddr;PROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Address = VAR ua: Uin.struct_in_addr; BEGIN <* ASSERT ent.h_length <= BYTESIZE(Address) *> ua := LOOPHOLE(ent.h_addr_list, UNTRACED REF UNTRACED REF Uin.struct_in_addr)^^; RETURN LOOPHOLE(ua.s_addr, Address); END GetAddress; gethostbyname is failing. Analogous C code also fails: [jay at fbsdamd64a /cm3/bin]$ cat ~/5.c#include #include #include #include typedef struct hostent hostent_t; int main(){ char hostname[200]; hostent_t* h; int i; i = gethostname(hostname, 200); assert(i == 0); printf("hostname: %s\n", hostname); h = gethostbyname(hostname); herror("foo"); printf("%p %d %d\n", h, errno, h_errno); assert(h); return 0;} herror says "unknown host".Stack is: at ../src/runtime/ex_frame/RTExFrame.m3:58#13 0x0000000801a7f2b3 in RTHooks__Raise (M3_AJWxb1_ex=Error accessing memory address 0x8000ffffd278: Bad address.) at ../src/runtime/common/RTHooks.m3:79#14 0x000000080169c8d3 in IPError__Die () at ../src/common/IPError.m3:27#15 0x0000000801698a3e in IP__GetHostAddr (M3_BCxjPn__result=Error accessing memory address 0x8000ffffd338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x00000008012133d0 in XSharedMem__SameHost (M3_AQuuui_trsl=Error accessing memory address 0x8000ffffd4d8: Bad address.) at ../src/xvbt/XSharedMem.m3:96#17 0x0000000801212ab7 in XSharedMem__InitXClient (M3_AQuuui_v=Error accessing memory address 0x8000ffffd648: Bad address.) at ../src/xvbt/XSharedMem.m3:29#18 0x0000000801211819 in XExtensions__InitXClient (M3_AQuuui_xclient=Error accessing memory address 0x8000ffffd7f8: Bad address.) at ../src/xvbt/XExtensions.m3:14#19 0x00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst=0x1879b, M3_AQuuui_trsl=0x6) at ../src/xvbt/XClientF.m3:583---Type to continue, or q to quit---(More stack frames follow...)(gdb)(* return TRUE if server and client are on same host *)PROCEDURE SameHost (trsl: XClient.T): BOOLEAN = VAR display := DisplayHost(trsl); displayAddr: IP.Address; BEGIN IF display = NIL THEN RETURN TRUE; END; TRY IF NOT IP.GetHostByName(display, displayAddr) THEN RETURN FALSE; END; RETURN displayAddr = IP.GetHostAddr(); EXCEPT | IP.Error => RETURN FALSE; END; END SameHost; Thoughts? Perhaps my network isn't setup well, like I should add the local machine to /etc/hosts.I think this can be made to fail gracefully though.It seems like it has nothing to do with AMD64_FREEBSD, but could have to do with FreeBSD. Seems like SocketPosix has nearly the exact same code but appearsmore forgiving.. IOError instead of Fatal? SocketPosix.m3: PROCEDURE GetHostAddr (): Address RAISES {OSError.E} = VAR host : ARRAY [0..255] OF CHAR; info : Unetdb.struct_hostent_star; ua : Uin.struct_in_addr; BEGIN IF Unix.gethostname (ADR (host[0]), BYTESIZE (host)) # 0 THEN IOError (Unexpected); END; info := Unetdb.gethostbyname (ADR (host[0])); IF info = NIL THEN IOError (Unexpected); END; <* ASSERT info.h_length <= BYTESIZE (Address) *> ua := LOOPHOLE(info.h_addr_list, UNTRACED REF UNTRACED REF Uin.struct_in_addr)^^; RETURN LOOPHOLE (ua.s_addr, Address); END GetHostAddr; It is again disappointing to see such code duplication. I guess SameHost can duplicate the logic to predict the error state and return false upon error?Duplicating the logic for a third time. :( - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 11 15:44:14 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Jan 2009 14:44:14 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? Message-ID: Is there a way in Modula-3 to declare that a type exists, and there are <*external*> instances of it, without "fully" declaring it, so that no Modula-3 can instantiate it? I have done this for sigset_t and sem_t, but they could erroneously be instantiated by Modula-3 and I'd like to remove that ability to mess up so easily. (* This type is not declared correctly. It is only instantiated in C code. *) sigset_t = RECORD END; (* This type is not declared correctly. It is only instantiated in C code. *) sem_t = RECORD END; In C I believe you can do this, like: typedef struct foo foo_t; extern foo_t foo; void UseFoo(foo_t*); foo_t* GetFoo(void); Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Jan 11 17:02:18 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 11 Jan 2009 08:02:18 -0800 Subject: [M3devel] Juno (X) networking problem on AMD64_FREEBSD In-Reply-To: Your message of "Sun, 11 Jan 2009 12:57:13 GMT." Message-ID: <200901111602.n0BG2IUG047813@camembert.async.caltech.edu> This is a screwy thing in Modula-3. A bug I would call it. I've noticed a lot of networking M3 programs don't work right unless the return value of Unix's "hostname" maps to a real IP address via gethostbyname. I accomplish it in practice by adding my hostname to /etc/hosts. This is obviously not the right way to fix it... Mika Jay writes: >--_9e67232c-a064-417d-879e-227a77e310f9_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Hi. Unix network programming question.. >AMD64_FREEBSD: >$DISPLAY is set to point back to Cygwin host.It works for PPC_LINUX. >[jay at fbsdamd64a /cm3/bin]$ ./Juno >****** runtime error:*** Exception "IPError.FatalError" not in RAISES li= >st*** file "../src/common/IPError.m3"=2C line 27*** >Abort trap: 6 (core dumped)[jay at fbsdamd64a /cm3/bin]$ >IP.m3: >=20 >PROCEDURE GetHostAddr(): Address =3D VAR hname: ARRAY [0..255] OF CHAR=3B = > BEGIN LOCK mu DO IF Unix.gethostname(ADR(hname[0])=2C BYTESIZE(hna= >me)) # 0 THEN IPError.Die ()=3B END=3B VAR h :=3D Unetdb.g= >ethostbyname(ADR(hname[0]))=3B BEGIN IF h =3D NIL THEN IPError.Die()= >=3B END=3B RETURN GetAddress(h)=3B END=3B END=3B END GetHos= >tAddr=3B >PROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Address =3D VAR ua= >: Uin.struct_in_addr=3B BEGIN <* ASSERT ent.h_length <=3D BYTESIZE(Addr= >ess) *> ua :=3D LOOPHOLE(ent.h_addr_list=2C UNTRACED = >REF UNTRACED REF Uin.struct_in_addr)^^=3B RETURN LOOPHOLE(ua.s_addr=2C A= >ddress)=3B END GetAddress=3B >=20 >gethostbyname is failing. >=20 >Analogous C code also fails: >=20 >[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c#include #include #i= >nclude #include typedef struct hostent hostent_t=3B >=20 >int main(){ char hostname[200]=3B hostent_t* h=3B int i=3B > i =3D gethostname(hostname=2C 200)=3B assert(i =3D=3D 0)=3B printf("hostna= >me: %s\n"=2C hostname)=3B h =3D gethostbyname(hostname)=3B herror("foo")=3B= > printf("%p %d %d\n"=2C h=2C errno=2C h_errno)=3B assert(h)=3B return 0=3B} >=20 >herror says "unknown host". >Stack is: > at ../src/runtime/ex_frame/RTExFrame.m3:58#13 0x0000000801a7f2b3 in RTH= >ooks__Raise (M3_AJWxb1_ex=3DError accessing memory address 0x8000ffffd278: = >Bad address.) at ../src/runtime/common/RTHooks.m3:79#14 0x000000080169c8= >d3 in IPError__Die () at ../src/common/IPError.m3:27#15 0x0000000801698a3e = >in IP__GetHostAddr (M3_BCxjPn__result=3DError accessing memory address 0x80= >00ffffd338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x00000008012133d0= > in XSharedMem__SameHost (M3_AQuuui_trsl=3DError accessing memory address 0= >x8000ffffd4d8: Bad address.) at ../src/xvbt/XSharedMem.m3:96#17 0x000000= >0801212ab7 in XSharedMem__InitXClient (M3_AQuuui_v=3DError accessing memory= > address 0x8000ffffd648: Bad address.) at ../src/xvbt/XSharedMem.m3:29#1= >8 0x0000000801211819 in XExtensions__InitXClient (M3_AQuuui_xclient=3DError= > accessing memory address 0x8000ffffd7f8: Bad address.) at ../src/xvbt/X= >Extensions.m3:14#19 0x00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst= >=3D0x1879b=2C M3_AQuuui_trsl=3D0x6) at ../src/xvbt/XClientF.m3:583---Typ= >e to continue=2C or q to quit---(More stack frames follow= >...)(gdb) >(* return TRUE if server and client are on same host *)PROCEDURE SameHost (= >trsl: XClient.T): BOOLEAN =3D VAR display :=3D DisplayH= >ost(trsl)=3B displayAddr: IP.Address=3B BEGIN IF display =3D NIL THE= >N RETURN TRUE=3B END=3B > TRY IF NOT IP.GetHostByName(display=2C displayAddr) THEN RETURN FA= >LSE=3B END=3B RETURN displayAddr =3D IP.GetHostAddr()=3B EXCEPT = >| IP.Error =3D> RETURN FALSE=3B END=3B END SameHost=3B >=20 >Thoughts? >=20 >Perhaps my network isn't setup well=2C like I should add the local machine = >to /etc/hosts.I think this can be made to fail gracefully though.It seems l= >ike it has nothing to do with AMD64_FREEBSD=2C but could have to do with Fr= >eeBSD. >=20 >Seems like SocketPosix has nearly the exact same code but appearsmore forgi= >ving.. IOError instead of Fatal? >=20 >SocketPosix.m3: >=20 >PROCEDURE GetHostAddr (): Address RAISES {OSError.E} =3D VAR host : AR= >RAY [0..255] OF CHAR=3B info : Unetdb.struct_hostent_star=3B ua : U= >in.struct_in_addr=3B BEGIN IF Unix.gethostname (ADR (host[0])=2C BYTESI= >ZE (host)) # 0 THEN IOError (Unexpected)=3B END=3B > info :=3D Unetdb.gethostbyname (ADR (host[0]))=3B IF info =3D NIL TH= >EN IOError (Unexpected)=3B END=3B <* ASSERT info.h_length <=3D BYTESIZE = >(Address) *> > ua :=3D LOOPHOLE(info.h_addr_list=2C UNTRACED REF UNT= >RACED REF Uin.struct_in_addr)^^=3B RETURN LOOPHOLE (ua.s_addr=2C Address= >)=3B END GetHostAddr=3B >=20 >=20 >It is again disappointing to see such code duplication. >=20 >=20 >I guess SameHost can duplicate the logic to predict the error state and ret= >urn false upon error? >Duplicating the logic for a third time. :( >=20 > - Jay= > >--_9e67232c-a064-417d-879e-227a77e310f9_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Hi. Unix network programming question..
>
AMD64_FREEBSD:
>
$DISPLAY is set to point back to Cygwin host.
It works for PPC_LINUX= >.
>
[jay at fbsdamd64a /cm3/bin]$ ./Juno
>
***
*** runtime error:
*** =3B =3B =3B Exception "IPE= >rror.FatalError" not in RAISES list
*** =3B =3B =3B file "..= >/src/common/IPError.m3"=2C line 27
***
>
Abort trap: 6 (core dumped)
[jay at fbsdamd64a /cm3/bin]$
>
IP.m3:
> =3B
>PROCEDURE GetHostAddr(): Address =3D
 =3B VAR hname: ARRAY [0..255] = OF CHAR=3B
 =3B BEGIN
 =3B =3B =3B LOCK mu DO
&nbs= >p=3B =3B =3B =3B =3B IF Unix.gethostname(ADR(hname[0])=2C B= >YTESIZE(hname)) # 0 THEN
 =3B =3B =3B =3B =3B = >=3B =3B IPError.Die ()=3B
 =3B =3B =3B =3B =3B E= >ND=3B
 =3B =3B =3B =3B =3B VAR h :=3D Unetdb.gethost= >byname(ADR(hname[0]))=3B BEGIN
 =3B =3B =3B =3B =3B&= >nbsp=3B =3B IF h =3D NIL THEN IPError.Die()=3B END=3B
 =3B = >=3B =3B =3B =3B =3B =3B RETURN GetAddress(h)=3B
&nbs= >p=3B =3B =3B =3B =3B END=3B
 =3B =3B =3B END= >=3B
 =3B END GetHostAddr=3B
>
PROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Address =3D
= > =3B VAR ua: Uin.struct_in_addr=3B
 =3B BEGIN
 =3B = >=3B =3B <=3B* ASSERT ent.h_length <=3B=3D BYTESIZE(Address) *>=3B= >
 =3B =3B =3B ua :=3D LOOPHOLE(ent.h_addr_list=2C
 = >=3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= > =3B =3B =3B =3B =3B =3B =3B =3B =3B UN= >TRACED REF UNTRACED REF Uin.struct_in_addr)^^=3B
 =3B =3B = >=3B RETURN LOOPHOLE(ua.s_addr=2C Address)=3B
 =3B END GetAddress=3B<= >BR> > =3B
>gethostbyname is failing.
>
 =3B
>Analogous C code also fails:
> =3B
>
[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c
#include <=3Bassert.h>=3BR>#include <=3Bnetdb.h>=3B
#include <=3Bstdio.h>=3B
#include = ><=3Berrno.h>=3B
typedef struct hostent hostent_t=3B
> =3B
>int main()
{
 =3Bchar hostname[200]=3B
 =3Bhostent_t* h=3B= >
 =3Bint i=3B
> =3Bi =3D gethostname(hostname=2C 200)=3B
 =3Bassert(i =3D=3D 0)= >=3B
 =3Bprintf("hostname: %s\n"=2C hostname)=3B
 =3Bh =3D get= >hostbyname(hostname)=3B
 =3Bherror("foo")=3B
 =3Bprintf("%p %= >d %d\n"=2C h=2C errno=2C h_errno)=3B
 =3Bassert(h)=3B
 =3Bret= >urn 0=3B
}
> =3B
>herror says "unknown host".
>
Stack is:
> =3B =3B =3B at ../src/runtime/ex_frame/RTExFrame.m3:58
#13 = >0x0000000801a7f2b3 in RTHooks__Raise (M3_AJWxb1_ex=3DError accessing memory= > ad
dress 0x8000ffffd278: Bad address.
)
 =3B =3B =3B = >at ../src/runtime/common/RTHooks.m3:79
#14 0x000000080169c8d3 in IPError= >__Die () at ../src/common/IPError.m3:27
#15 0x0000000801698a3e in IP__Ge= >tHostAddr (M3_BCxjPn__result=3DError accessing mem
ory address 0x8000fff= >fd338: Bad address.
)
 =3B =3B =3B at ../src/POSIX/IP.m3:= >82
#16 0x00000008012133d0 in XSharedMem__SameHost (M3_AQuuui_trsl=3DErro= >r accessing m
emory address 0x8000ffffd4d8: Bad address.
)
 = >=3B =3B =3B at ../src/xvbt/XSharedMem.m3:96
#17 0x0000000801212a= >b7 in XSharedMem__InitXClient (M3_AQuuui_v=3DError accessing m
emory add= >ress 0x8000ffffd648: Bad address.
)
 =3B =3B =3B at ../sr= >c/xvbt/XSharedMem.m3:29
#18 0x0000000801211819 in XExtensions__InitXClie= >nt (M3_AQuuui_xclient=3DError acce
ssing memory address 0x8000ffffd7f8: = >Bad address.
)
 =3B =3B =3B at ../src/xvbt/XExtensions.m3= >:14
#19 0x00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst=3D0x1879= >b=2C
 =3B =3B =3B M3_AQuuui_trsl=3D0x6) at ../src/xvbt/XClie= >ntF.m3:583
---Type <=3Breturn>=3B to continue=2C or q <=3Breturn&g= >t=3B to quit---
(More stack frames follow...)
(gdb)
>
(* return TRUE if server and client are on same host *)
PROCEDURE Sa= >meHost (trsl: XClient.T): BOOLEAN =3D
 =3B VAR
 =3B =3B&n= >bsp=3B display =3B =3B =3B =3B =3B =3B =3B = >=3B =3B =3B =3B =3B =3B =3B =3B =3B :=3D Di= >splayHost(trsl)=3B
 =3B =3B =3B displayAddr: IP.Address=3BR> =3B BEGIN
 =3B =3B =3B IF display =3D NIL THEN RETURN= > TRUE=3B END=3B
> =3B =3B =3B TRY
 =3B =3B =3B =3B =3B IF= > NOT IP.GetHostByName(display=2C displayAddr) THEN RETURN FALSE=3B END=3BR> =3B =3B =3B =3B =3B RETURN displayAddr =3D IP.GetHos= >tAddr()=3B
 =3B =3B =3B EXCEPT
 =3B =3B =3B |= > IP.Error =3D>=3B RETURN FALSE=3B
 =3B =3B =3B END=3B
&= >nbsp=3B END SameHost=3B
> =3B
>Thoughts?
> =3B
>
Perhaps my network isn't setup well=2C like I should add the local mach= >ine to /etc/hosts.
I think this can be made to fail gracefully though.R>It seems like it has nothing to do with AMD64_FREEBSD=2C but could have t= >o do with FreeBSD.
>
 =3B
>Seems like SocketPosix has nearly the exact same code but appears
more f= >orgiving.. IOError instead of Fatal?
> =3B
>
SocketPosix.m3:
> =3B
>
PROCEDURE GetHostAddr (): Address
 =3B RAISES {OSError.E} =3D> =3B VAR
 =3B =3B =3B host : ARRAY [0..255] OF CHAR=3B<= >BR> =3B =3B =3B info : Unetdb.struct_hostent_star=3B
 = >=3B =3B =3B ua =3B =3B : Uin.struct_in_addr=3B
 =3B = >BEGIN
 =3B =3B =3B IF Unix.gethostname (ADR (host[0])=2C BYT= >ESIZE (host)) # 0 THEN
 =3B =3B =3B =3B =3B IOError = >(Unexpected)=3B
 =3B =3B =3B END=3B
> =3B =3B =3B info :=3D Unetdb.gethostbyname (ADR (host[0]))=3B<= >BR> =3B =3B =3B IF info =3D NIL THEN IOError (Unexpected)=3B EN= >D=3B
 =3B =3B =3B <=3B* ASSERT info.h_length <=3B=3D BYT= >ESIZE (Address) *>=3B
> =3B =3B =3B ua :=3D LOOPHOLE(info.h_addr_list=2C
 =3B&n= >bsp=3B =3B =3B =3B =3B =3B =3B =3B =3B = >=3B =3B =3B =3B =3B =3B =3B =3B UNTRACED REF UN= >TRACED REF Uin.struct_in_addr)^^=3B
 =3B =3B =3B RETURN LOOP= >HOLE (ua.s_addr=2C Address)=3B
 =3B END GetHostAddr=3B
> =3B
> =3B
>It is again disappointing to see such code duplication.
> =3B
> =3B
>I guess =3BSameHost can duplicate the logic to predict the error state = >and return false =3Bupon error?
>Duplicating the logic for a third time. :(
> =3B
>
 =3B- Jay

>= > >--_9e67232c-a064-417d-879e-227a77e310f9_-- From jay.krell at cornell.edu Sun Jan 11 23:02:18 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Jan 2009 22:02:18 +0000 Subject: [M3devel] Juno (X) networking problem on AMD64_FREEBSD In-Reply-To: <200901111602.n0BG2IUG047813@camembert.async.caltech.edu> References: Your message of "Sun, 11 Jan 2009 12:57:13 GMT." <200901111602.n0BG2IUG047813@camembert.async.caltech.edu> Message-ID: Do you know the right way? PPC_LINUX "just worked", and I can check Solaris and Darwin. I don't want to edit /etc/hosts -- I use DHCP. Though DHCP has been bothering me -- only for some of my machines do names resolve, so I end using IP addresses, which change sometimes, and I loop over them running ssh to all of them and "see what I get", not ideal. - Jay> To: jay.krell at cornell.edu> Date: Sun, 11 Jan 2009 08:02:18 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Juno (X) networking problem on AMD64_FREEBSD> > This is a screwy thing in Modula-3. A bug I would call it.> > I've noticed a lot of networking M3 programs don't work right unless> the return value of Unix's "hostname" maps to a real IP address via> gethostbyname. I accomplish it in practice by adding my hostname> to /etc/hosts.> > This is obviously not the right way to fix it... > > Mika> > Jay writes:> >--_9e67232c-a064-417d-879e-227a77e310f9_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >Hi. Unix network programming question..> >AMD64_FREEBSD:> >$DISPLAY is set to point back to Cygwin host.It works for PPC_LINUX.> >[jay at fbsdamd64a /cm3/bin]$ ./Juno> >****** runtime error:*** Exception "IPError.FatalError" not in RAISES li=> >st*** file "../src/common/IPError.m3"=2C line 27***> >Abort trap: 6 (core dumped)[jay at fbsdamd64a /cm3/bin]$> >IP.m3:> >=20> >PROCEDURE GetHostAddr(): Address =3D VAR hname: ARRAY [0..255] OF CHAR=3B => > BEGIN LOCK mu DO IF Unix.gethostname(ADR(hname[0])=2C BYTESIZE(hna=> >me)) # 0 THEN IPError.Die ()=3B END=3B VAR h :=3D Unetdb.g=> >ethostbyname(ADR(hname[0]))=3B BEGIN IF h =3D NIL THEN IPError.Die()=> >=3B END=3B RETURN GetAddress(h)=3B END=3B END=3B END GetHos=> >tAddr=3B> >PROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Address =3D VAR ua=> >: Uin.struct_in_addr=3B BEGIN <* ASSERT ent.h_length <=3D BYTESIZE(Addr=> >ess) *> ua :=3D LOOPHOLE(ent.h_addr_list=2C UNTRACED => >REF UNTRACED REF Uin.struct_in_addr)^^=3B RETURN LOOPHOLE(ua.s_addr=2C A=> >ddress)=3B END GetAddress=3B> >=20> >gethostbyname is failing.> >=20> >Analogous C code also fails:> >=20> >[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c#include #include #i=> >nclude #include typedef struct hostent hostent_t=3B> >=20> >int main(){ char hostname[200]=3B hostent_t* h=3B int i=3B> > i =3D gethostname(hostname=2C 200)=3B assert(i =3D=3D 0)=3B printf("hostna=> >me: %s\n"=2C hostname)=3B h =3D gethostbyname(hostname)=3B herror("foo")=3B=> > printf("%p %d %d\n"=2C h=2C errno=2C h_errno)=3B assert(h)=3B return 0=3B}> >=20> >herror says "unknown host".> >Stack is:> > at ../src/runtime/ex_frame/RTExFrame.m3:58#13 0x0000000801a7f2b3 in RTH=> >ooks__Raise (M3_AJWxb1_ex=3DError accessing memory address 0x8000ffffd278: => >Bad address.) at ../src/runtime/common/RTHooks.m3:79#14 0x000000080169c8=> >d3 in IPError__Die () at ../src/common/IPError.m3:27#15 0x0000000801698a3e => >in IP__GetHostAddr (M3_BCxjPn__result=3DError accessing memory address 0x80=> >00ffffd338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x00000008012133d0=> > in XSharedMem__SameHost (M3_AQuuui_trsl=3DError accessing memory address 0=> >x8000ffffd4d8: Bad address.) at ../src/xvbt/XSharedMem.m3:96#17 0x000000=> >0801212ab7 in XSharedMem__InitXClient (M3_AQuuui_v=3DError accessing memory=> > address 0x8000ffffd648: Bad address.) at ../src/xvbt/XSharedMem.m3:29#1=> >8 0x0000000801211819 in XExtensions__InitXClient (M3_AQuuui_xclient=3DError=> > accessing memory address 0x8000ffffd7f8: Bad address.) at ../src/xvbt/X=> >Extensions.m3:14#19 0x00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst=> >=3D0x1879b=2C M3_AQuuui_trsl=3D0x6) at ../src/xvbt/XClientF.m3:583---Typ=> >e to continue=2C or q to quit---(More stack frames follow=> >...)(gdb)> >(* return TRUE if server and client are on same host *)PROCEDURE SameHost (=> >trsl: XClient.T): BOOLEAN =3D VAR display :=3D DisplayH=> >ost(trsl)=3B displayAddr: IP.Address=3B BEGIN IF display =3D NIL THE=> >N RETURN TRUE=3B END=3B> > TRY IF NOT IP.GetHostByName(display=2C displayAddr) THEN RETURN FA=> >LSE=3B END=3B RETURN displayAddr =3D IP.GetHostAddr()=3B EXCEPT => >| IP.Error =3D> RETURN FALSE=3B END=3B END SameHost=3B> >=20> >Thoughts?> >=20> >Perhaps my network isn't setup well=2C like I should add the local machine => >to /etc/hosts.I think this can be made to fail gracefully though.It seems l=> >ike it has nothing to do with AMD64_FREEBSD=2C but could have to do with Fr=> >eeBSD.> >=20> >Seems like SocketPosix has nearly the exact same code but appearsmore forgi=> >ving.. IOError instead of Fatal?> >=20> >SocketPosix.m3:> >=20> >PROCEDURE GetHostAddr (): Address RAISES {OSError.E} =3D VAR host : AR=> >RAY [0..255] OF CHAR=3B info : Unetdb.struct_hostent_star=3B ua : U=> >in.struct_in_addr=3B BEGIN IF Unix.gethostname (ADR (host[0])=2C BYTESI=> >ZE (host)) # 0 THEN IOError (Unexpected)=3B END=3B> > info :=3D Unetdb.gethostbyname (ADR (host[0]))=3B IF info =3D NIL TH=> >EN IOError (Unexpected)=3B END=3B <* ASSERT info.h_length <=3D BYTESIZE => >(Address) *>> > ua :=3D LOOPHOLE(info.h_addr_list=2C UNTRACED REF UNT=> >RACED REF Uin.struct_in_addr)^^=3B RETURN LOOPHOLE (ua.s_addr=2C Address=> >)=3B END GetHostAddr=3B> >=20> >=20> >It is again disappointing to see such code duplication.> >=20> >=20> >I guess SameHost can duplicate the logic to predict the error state and ret=> >urn false upon error?> >Duplicating the logic for a third time. :(> >=20> > - Jay=> >> >--_9e67232c-a064-417d-879e-227a77e310f9_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >> >Hi. Unix network programming question..
> >
AMD64_FREEBSD:
> >
$DISPLAY is set to point back to Cygwin host.
It works for PPC_LINUX=> >.
> >
[jay at fbsdamd64a /cm3/bin]$ ./Juno
> >
***
*** runtime error:
*** =3B =3B =3B Exception "IPE=> >rror.FatalError" not in RAISES list
*** =3B =3B =3B file "..=> >/src/common/IPError.m3"=2C line 27
***
> >
Abort trap: 6 (core dumped)
[jay at fbsdamd64a /cm3/bin]$
> >
IP.m3:
> > =3B
> >PROCEDURE GetHostAddr(): Address =3D
 =3B VAR hname: ARRAY [0..255] => OF CHAR=3B
 =3B BEGIN
 =3B =3B =3B LOCK mu DO
&nbs=> >p=3B =3B =3B =3B =3B IF Unix.gethostname(ADR(hname[0])=2C B=> >YTESIZE(hname)) # 0 THEN
 =3B =3B =3B =3B =3B => >=3B =3B IPError.Die ()=3B
 =3B =3B =3B =3B =3B E=> >ND=3B
 =3B =3B =3B =3B =3B VAR h :=3D Unetdb.gethost=> >byname(ADR(hname[0]))=3B BEGIN
 =3B =3B =3B =3B =3B&=> >nbsp=3B =3B IF h =3D NIL THEN IPError.Die()=3B END=3B
 =3B => >=3B =3B =3B =3B =3B =3B RETURN GetAddress(h)=3B
&nbs=> >p=3B =3B =3B =3B =3B END=3B
 =3B =3B =3B END=> >=3B
 =3B END GetHostAddr=3B
> >
PROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Address =3D
=> > =3B VAR ua: Uin.struct_in_addr=3B
 =3B BEGIN
 =3B => >=3B =3B <=3B* ASSERT ent.h_length <=3B=3D BYTESIZE(Address) *>=3B=> >
 =3B =3B =3B ua :=3D LOOPHOLE(ent.h_addr_list=2C
 => >=3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=> > =3B =3B =3B =3B =3B =3B =3B =3B =3B UN=> >TRACED REF UNTRACED REF Uin.struct_in_addr)^^=3B
 =3B =3B => >=3B RETURN LOOPHOLE(ua.s_addr=2C Address)=3B
 =3B END GetAddress=3B<=> >BR>> > =3B
> >gethostbyname is failing.
> >
 =3B
> >Analogous C code also fails:
> > =3B
> >
[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c
#include <=3Bassert.h>=3B >R>#include <=3Bnetdb.h>=3B
#include <=3Bstdio.h>=3B
#include => ><=3Berrno.h>=3B
typedef struct hostent hostent_t=3B
> > =3B
> >int main()
{
 =3Bchar hostname[200]=3B
 =3Bhostent_t* h=3B=> >
 =3Bint i=3B
> > =3Bi =3D gethostname(hostname=2C 200)=3B
 =3Bassert(i =3D=3D 0)=> >=3B
 =3Bprintf("hostname: %s\n"=2C hostname)=3B
 =3Bh =3D get=> >hostbyname(hostname)=3B
 =3Bherror("foo")=3B
 =3Bprintf("%p %=> >d %d\n"=2C h=2C errno=2C h_errno)=3B
 =3Bassert(h)=3B
 =3Bret=> >urn 0=3B
}
> > =3B
> >herror says "unknown host".
> >
Stack is:
> > =3B =3B =3B at ../src/runtime/ex_frame/RTExFrame.m3:58
#13 => >0x0000000801a7f2b3 in RTHooks__Raise (M3_AJWxb1_ex=3DError accessing memory=> > ad
dress 0x8000ffffd278: Bad address.
)
 =3B =3B =3B => >at ../src/runtime/common/RTHooks.m3:79
#14 0x000000080169c8d3 in IPError=> >__Die () at ../src/common/IPError.m3:27
#15 0x0000000801698a3e in IP__Ge=> >tHostAddr (M3_BCxjPn__result=3DError accessing mem
ory address 0x8000fff=> >fd338: Bad address.
)
 =3B =3B =3B at ../src/POSIX/IP.m3:=> >82
#16 0x00000008012133d0 in XSharedMem__SameHost (M3_AQuuui_trsl=3DErro=> >r accessing m
emory address 0x8000ffffd4d8: Bad address.
)
 => >=3B =3B =3B at ../src/xvbt/XSharedMem.m3:96
#17 0x0000000801212a=> >b7 in XSharedMem__InitXClient (M3_AQuuui_v=3DError accessing m
emory add=> >ress 0x8000ffffd648: Bad address.
)
 =3B =3B =3B at ../sr=> >c/xvbt/XSharedMem.m3:29
#18 0x0000000801211819 in XExtensions__InitXClie=> >nt (M3_AQuuui_xclient=3DError acce
ssing memory address 0x8000ffffd7f8: => >Bad address.
)
 =3B =3B =3B at ../src/xvbt/XExtensions.m3=> >:14
#19 0x00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst=3D0x1879=> >b=2C
 =3B =3B =3B M3_AQuuui_trsl=3D0x6) at ../src/xvbt/XClie=> >ntF.m3:583
---Type <=3Breturn>=3B to continue=2C or q <=3Breturn&g=> >t=3B to quit---
(More stack frames follow...)
(gdb)
> >
(* return TRUE if server and client are on same host *)
PROCEDURE Sa=> >meHost (trsl: XClient.T): BOOLEAN =3D
 =3B VAR
 =3B =3B&n=> >bsp=3B display =3B =3B =3B =3B =3B =3B =3B => >=3B =3B =3B =3B =3B =3B =3B =3B =3B :=3D Di=> >splayHost(trsl)=3B
 =3B =3B =3B displayAddr: IP.Address=3B >R> =3B BEGIN
 =3B =3B =3B IF display =3D NIL THEN RETURN=> > TRUE=3B END=3B
> > =3B =3B =3B TRY
 =3B =3B =3B =3B =3B IF=> > NOT IP.GetHostByName(display=2C displayAddr) THEN RETURN FALSE=3B END=3B >R> =3B =3B =3B =3B =3B RETURN displayAddr =3D IP.GetHos=> >tAddr()=3B
 =3B =3B =3B EXCEPT
 =3B =3B =3B |=> > IP.Error =3D>=3B RETURN FALSE=3B
 =3B =3B =3B END=3B
&=> >nbsp=3B END SameHost=3B
> > =3B
> >Thoughts?
> > =3B
> >
Perhaps my network isn't setup well=2C like I should add the local mach=> >ine to /etc/hosts.
I think this can be made to fail gracefully though. >R>It seems like it has nothing to do with AMD64_FREEBSD=2C but could have t=> >o do with FreeBSD.
> >
 =3B
> >Seems like SocketPosix has nearly the exact same code but appears
more f=> >orgiving.. IOError instead of Fatal?
> > =3B
> >
SocketPosix.m3:
> > =3B
> >
PROCEDURE GetHostAddr (): Address
 =3B RAISES {OSError.E} =3D >> =3B VAR
 =3B =3B =3B host : ARRAY [0..255] OF CHAR=3B<=> >BR> =3B =3B =3B info : Unetdb.struct_hostent_star=3B
 => >=3B =3B =3B ua =3B =3B : Uin.struct_in_addr=3B
 =3B => >BEGIN
 =3B =3B =3B IF Unix.gethostname (ADR (host[0])=2C BYT=> >ESIZE (host)) # 0 THEN
 =3B =3B =3B =3B =3B IOError => >(Unexpected)=3B
 =3B =3B =3B END=3B
> > =3B =3B =3B info :=3D Unetdb.gethostbyname (ADR (host[0]))=3B<=> >BR> =3B =3B =3B IF info =3D NIL THEN IOError (Unexpected)=3B EN=> >D=3B
 =3B =3B =3B <=3B* ASSERT info.h_length <=3B=3D BYT=> >ESIZE (Address) *>=3B
> > =3B =3B =3B ua :=3D LOOPHOLE(info.h_addr_list=2C
 =3B&n=> >bsp=3B =3B =3B =3B =3B =3B =3B =3B =3B => >=3B =3B =3B =3B =3B =3B =3B =3B UNTRACED REF UN=> >TRACED REF Uin.struct_in_addr)^^=3B
 =3B =3B =3B RETURN LOOP=> >HOLE (ua.s_addr=2C Address)=3B
 =3B END GetHostAddr=3B
> > =3B
> > =3B
> >It is again disappointing to see such code duplication.
> > =3B
> > =3B
> >I guess =3BSameHost can duplicate the logic to predict the error state => >and return false =3Bupon error?
> >Duplicating the logic for a third time. :(
> > =3B
> >
 =3B- Jay

> >=> >> >--_9e67232c-a064-417d-879e-227a77e310f9_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 11 23:28:08 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Jan 2009 22:28:08 +0000 Subject: [M3devel] registers and garbage collector? Message-ID: Is this a safe assumption? PROCEDURE ProcessOther (act: Activation; p: PROCEDURE (start, stop: ADDRESS)) =... IF RTMachine.GetState # NIL THEN (* process explicit state *) sp := RTMachine.GetState(act.handle, state); ELSE (* assume registers are saved in suspended thread's stack *) sp := act.sp; END; As I understand..insert question marks a bunch here: The threads are all sitting waiting in their signal handler, with a ucontext pointer...which could be in a register and not on the stack..which contains a pointer to the registers...which could be to a thread local..and not on the stack..and not in the Modula-3 heap..would be a simple matter to strengthen this..be sure to store the ucontext in a thread local (no, actually)..or somehow be sure to get it on the stack (might as well skip the ucontext and use the gregs or whatever is in it)? Storing the ucontext in a thread local doesn't work, because you can't access thread locals that aren't yours. Instead a global array would likely be needed, that the signal handlers would all store into. I'd suggest, like, storing the ucontext/gregs into a local, or maybe a volatile local in C, maybe a struct/record, but I don't think there's any guaranteeing these aren't registers, I think a global array would be the way. I guess the assumption is fairly safe, but I'm not 100% sure. No, I'm not suspecting any problem here. I was just remembering that I'd seen platform specific stuff for some platforms (Darwin) that I'd managed to avoid, somehow, and went and looked closer, see if I was legitimately avoiding it. Most platforms do avoid it. ?? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 00:22:39 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Jan 2009 23:22:39 +0000 Subject: [M3devel] AMD64_FREEBSD available Message-ID: AMD64_FREEBSD is available now at: http://modula3.elegosoft.com/cm3/uploaded-archives built native, from a clean source checkout, on the recently released 7.1 (which might not be compatible with 6.x). You'll want to maybe update cm3cfg.common from current source to remove the use of the "ROOT" variable, which isn't always defined. The system builds itself and Juno comes up (remoted to Cygwin/X). Also new LINUXLIBC6 there (they are also built regularly by the Tinderbox). SPARC32_LINUX maybe later today (the "boot" archive that is there I think is broken, but current source tree is much better, related to struct dirent). - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 00:27:34 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Jan 2009 23:27:34 +0000 Subject: [M3devel] AMD64_FREEBSD available Message-ID: (oops, I think that was on a beta or RC, I need to reinstall..should be ok though) From: jay.krell at cornell.eduTo: m3devel at elegosoft.comSubject: AMD64_FREEBSD availableDate: Sun, 11 Jan 2009 23:22:39 +0000 AMD64_FREEBSD is available now at: http://modula3.elegosoft.com/cm3/uploaded-archives built native, from a clean source checkout, on the recently released 7.1 (which might not be compatible with 6.x). You'll want to maybe update cm3cfg.common from current source to remove the use of the "ROOT" variable, which isn't always defined. The system builds itself and Juno comes up (remoted to Cygwin/X). Also new LINUXLIBC6 there (they are also built regularly by the Tinderbox).SPARC32_LINUX maybe later today (the "boot" archive that is there I think is broken, but current source tree is much better, related to struct dirent). - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 01:01:16 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 11:01:16 +1100 Subject: [M3devel] making Uerror "portable"? In-Reply-To: References: Message-ID: <3D81B7DE-436C-4893-9129-EAA4E0551534@cs.purdue.edu> CONST is faster than VAR since the compiler can optimize them. Why would you want VAR? On 11 Jan 2009, at 19:58, Jay wrote: > I still find pushing the system dependencies and cloned headers out > of the system very tempting. > To reduce what it takes to port to other systems, to raise the > confidence of the correctness of any port, to keep ports correct in > the face of possible underlying change. > > I think I'll change the case statements to if/else ladders and the > consts to vars, that are actually statically initialized in C. This > treatment is reasonable for other constants that remain in the > cloned headers, system dependent or otherwise. > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: making Uerror "portable"? > Date: Thu, 8 Jan 2009 06:36:44 +0000 > > I've been thinking about "fixing" Uerror > to remove the system-dependentness of it. > > > I have about given up. > > > There are multiple easy options, but they > all have downsides that make me think it > might not be worth it. > > > today it looks like: > > > INTERFACE Uerror; > CONST > ENOFILE = 1; > ENOMEM = 2; > END Uerror; > > > The values are intended the correct native values. > There are a fair number of users. > Fewer than 10 probably. > They include switch/case statements, which require > constants. > > > The following are some of the possible changes, > that make porting to basically any future system > be a no-op in this area, except for the occasional missing or possibly > equal errnos (if there is a switch in the C code; I ran into this > case). > > > - Change to VAR and initialize them in portable C code. > disadvantages: > more startup code > possibly startup code runs too late > more writable/written data (readonly data is best) > slower to access > not constant, not switchable, not source quite compatible > You have to change the switch statements to "if ladders" (if/ > elseif/elseif/elseif). > Compatible with most source, and incompatible source easily > fixed. > possible issues around "dynamic linking data" (not explained > here, ask?) > However not really a problem. More of a problem only on NT, and > easily worked > around just like is done for hand.obj. > > > - change to VAR and const static initialize them in portable C "data" > no additional startup code -- guaranteed initialized early enough > no writable/written data > slower to access > not constant, not switchable, not source compatible (same as > previous) > same non-issue around dynamic linking of data > > > - change to functions GetENOFILE(), GetENOMEM(), etc. > slower to access > definitely no problem dynamic linking > easier to write the C code/data, no matter, the above > are easy enough > not constant, not switchable, not source compatible (similar to > previous) > > > - "translation"; introduce our own arbitrary values for > any errno the system uses; change Cerrno.GetErrno to have > a switch and translate from the native values to ours. > > > This is fully source compatible, dynamic link compatible, > in-between perf wise (slower to GetErrnor, but then constant > and just as comparable/switchable), no initialization cost. > > > Question then though what does any raised exception look like? > Do the values get translated back? Or translated to strings? > SetErrno translates back? > > > Translation is at first simple and is unique among portable > solutions > in its source compatibility, but I am leary of it. I would > rather a solution that traffics in unmodified native errnos > values, but > I don't that is viable with both constness and portability. > > > To a large extent, translation is ok. If you look at > SocketPosix.i3, it > uses the errno very briefly to determine the next step to take. > I don't think > it ever returns or RAISEs it (or an exception containing it). > > But other parts of the system Fmt.Int(errno) and raise that, thus > these become values that move through more of the system and > therefore > disagreement with the underlying system might show through. > > > There is also question of how to chose "Max". Set it large, like > 200? > Set it "correctly"? Probably a better option is to make the cache > that is currently Max-sized be instead small and fixed-size (e.g. > 64), > and "search" it quickly instead of "indexing" it very quickly, and > always > kick out the least recently used. I also have to check what the > contents actually are, perhaps they are constant-initializable. > > > Thoughts? > > > I was somewhat keen to do something here, but have pretty much > given up and > will just generate Uerror.i3 for Solaris, NetBSD, FreeBSD, AIX, > Irix, HP-UX, etc.. > I might still be able to remove the Usignal and Ustat system- > dependentness > in m3core/src/unix, but Uerror will probably stand asis (in linux- > common, > openbsd-common, cygwin). > > > In particular, I was putting off any more ports till I got the > amount of work needed > to port reduced to my satisfaction. I think I'm nearly there. > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 01:03:33 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 11:03:33 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> Message-ID: <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> Jay, Can you remind me again why Cygwin was unable to use pthreads? It seems you have introduced a bunch of hair into the PTHREADS implementation to deal with broken Cygwin pthreads. As many of us have already pointed out, Cygwin should be a port that tries as much as possible to be like a standard POSIX platform (pthread-based) as opposed to a weird Windows/POSIX hybrid. I have a bunch of code that will be going into the PTHREADS base that I am now at a loss to integrate with the changes you have made. Help! -- Tony From hosking at cs.purdue.edu Mon Jan 12 01:12:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 11:12:36 +1100 Subject: [M3devel] ThreadPThread (PTHREAD) In-Reply-To: <20090111233442.57DE510D5FB1@birch.elegosoft.com> References: <20090111233442.57DE510D5FB1@birch.elegosoft.com> Message-ID: <23468C51-9108-4131-9B12-6BDA68AA648E@cs.purdue.edu> Jay, can you give me a sense of what the purpose of your recent changes to the pthread-based threading code are intended to achieve? I haven't been able to follow too closely all the changes you are making, and I would like some sort of high-level rationale to help me understand. Also, if sysutils has thread-dependent stuff in it then I suggest sysutils should be rewritten to call the thread code rather than re-implement. m3core is a library that is always linked, so sysutils could easily depend on it. What's the problem? From hosking at cs.purdue.edu Mon Jan 12 01:13:00 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 11:13:00 +1100 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: References: Message-ID: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> What's wrong with using ADDRESS for references to opaque values? If sigset_t is never instantiated in Modula-3, then why do you need it declared there? 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 01:44, Jay wrote: > Is there a way in Modula-3 to declare that a type exists, and there > are <*external*> instances of it, without "fully" declaring it, so > that no Modula-3 can instantiate it? > > I have done this for sigset_t and sem_t, but they could erroneously > be instantiated by Modula-3 and I'd like to remove that ability to > mess up so easily. > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sigset_t = RECORD END; > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sem_t = RECORD END; > > In C I believe you can do this, like: > typedef struct foo foo_t; > extern foo_t foo; > > void UseFoo(foo_t*); > foo_t* GetFoo(void); > > Thanks, > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 01:55:16 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 00:55:16 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> Message-ID: I considered ADDRESS. However I think it still doesn't satisfy. I want to be able to do this: TYPE Foo_t = something; <* EXTERNAL *> VAR Foo1, Foo2:Foo_t; <* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); (* Modula-3, not external *) PROCEDURE x()= BEGIN UseFoo(Foo1); UseFoo(Foo2); END x; AND I want any use of: VAR Foo3:Foo3_t; (* Modula-3, not external *) to error. This is sem_t and sigset_t in particular. Possibly renaming is the thing. They used to be declared in Modula-3, system-dependently, but I moved them to portable C. I could remove the types entirely and change UseFoo to take an address, and declare mask and ackSem to be integers or I guess. <*EXTERNAL> VAR ackSem : RECORD END; That would satisfy but I thought it might be nicer to still provide the named types to refer to the external variables. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?What's wrong with using ADDRESS for references to opaque values? If sigset_t is never instantiated in Modula-3, then why do you need it declared there? 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 01:44, Jay wrote: Is there a way in Modula-3 to declare that a type exists, and there are <*external*> instances of it, without "fully" declaring it, so that no Modula-3 can instantiate it? I have done this for sigset_t and sem_t, but they could erroneously be instantiated by Modula-3 and I'd like to remove that ability to mess up so easily. (* This type is not declared correctly. It is only instantiated in C code. *) sigset_t = RECORD END;(* This type is not declared correctly. It is only instantiated in C code. *) sem_t = RECORD END;In C I believe you can do this, like: typedef struct foo foo_t; extern foo_t foo; void UseFoo(foo_t*); foo_t* GetFoo(void); Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 01:13:10 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 11:13:10 +1100 Subject: [M3devel] registers and garbage collector? In-Reply-To: References: Message-ID: <60C81864-8A4F-4A5F-B4FC-434FAB9F8919@cs.purdue.edu> Yes, this is safe. Some platforms require that we account for the red- zone, but generally the registers have been saved on the stack in the signal handler frame. I do not want to go the global array route that you suggest -- no need and very slow! On 12 Jan 2009, at 09:28, Jay wrote: > Is this a safe assumption? > > > PROCEDURE ProcessOther (act: Activation; p: PROCEDURE (start, stop: > ADDRESS)) = > ... > IF RTMachine.GetState # NIL THEN > (* process explicit state *) > sp := RTMachine.GetState(act.handle, state); > ELSE > (* assume registers are saved in suspended thread's stack *) > sp := act.sp; > END; > > > As I understand..insert question marks a bunch here: > > > The threads are all sitting waiting in their signal handler, with a > ucontext pointer...which could be in a register and not on the > stack..which contains a pointer to the registers...which could be to > a thread local..and not on the stack..and not in the Modula-3 > heap..would be a simple matter to strengthen this..be sure to store > the ucontext in a thread local (no, actually)..or somehow be sure to > get it on the stack (might as well skip the ucontext and use the > gregs or whatever is in it)? > Storing the ucontext in a thread local doesn't work, because you > can't access thread locals that aren't yours. Instead a global array > would likely be needed, that the signal handlers would all store > into. I'd suggest, like, storing the ucontext/gregs into a local, or > maybe a volatile local in C, maybe a struct/record, but I don't > think there's any guaranteeing these aren't registers, I think a > global array would be the way. > I guess the assumption is fairly safe, but I'm not 100% sure. > No, I'm not suspecting any problem here. I was just remembering that > I'd seen platform specific stuff for some platforms (Darwin) that > I'd managed to avoid, somehow, and went and looked closer, see if I > was legitimately avoiding it. Most platforms do avoid it. > > ?? > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 02:04:12 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 01:04:12 +0000 Subject: [M3devel] ThreadPThread (PTHREAD) In-Reply-To: <23468C51-9108-4131-9B12-6BDA68AA648E@cs.purdue.edu> References: <20090111233442.57DE510D5FB1@birch.elegosoft.com> <23468C51-9108-4131-9B12-6BDA68AA648E@cs.purdue.edu> Message-ID: Yes I can explain mostly. I was not able to get Cygwin/pthreads to work. I don't know why. I could try another round of debugging. It was a while ago, like a year ago. I did debug it on some depth, rebuilding cygwin1.dll, and such. I was inclined to give up. Consensus at the time was people didn't really care. As long as they had forward slashes (which are abstracted from code, but not from the user..and slow fork..), and Modula-3 abstracted threads, no matter how the Modula-3 threads were impelented. So Cygwin uses Win32 threads. More recently..well, it bothered me slightly that the "wait" code was duplicated, but that's very little code. In looking at it though, I realized that Cygwin didn't have a proper SchedulerPosix, which I think is an abstraction of select(). What I did is move the SchedulerPosix code out of ThreadPThread. This way it can be reused against ThreadPThread or ThreadWin32. It is a fairly mechanical change, with no real semantic change. I realize that movement of code from one file to another is hard to track though using simple text methods. The stuff around "WaitPidYields" is what got me looking here and has some value, but I think giving Cygwin a proper SchedulerPosix is more valuable. WaitPidYields is contorted because sysutils bootstraps against old m3core, and I strongly suspect that sysutils exposes essentially a different variant of m3core's abstractions, and cannot be implemented on top of it. That m3core hides too much for sysutils. If we bump up the minimum m3core that we build from, the contortions can go away. "contortions" == "quake generating Modula-3 code, with different names per client". Make sense? - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:12:36 +1100> CC: m3devel at elegosoft.com> Subject: [M3devel] ThreadPThread (PTHREAD)> > Jay, can you give me a sense of what the purpose of your recent > changes to the pthread-based threading code are intended to achieve? > I haven't been able to follow too closely all the changes you are > making, and I would like some sort of high-level rationale to help me > understand. Also, if sysutils has thread-dependent stuff in it then I > suggest sysutils should be rewritten to call the thread code rather > than re-implement. m3core is a library that is always linked, so > sysutils could easily depend on it. What's the problem?> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 02:09:52 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 01:09:52 +0000 Subject: [M3devel] making Uerror "portable"? In-Reply-To: <118F7713-A9E8-441C-90EF-8D255C386078@cs.purdue.edu> References: <118F7713-A9E8-441C-90EF-8D255C386078@cs.purdue.edu> Message-ID: Understood. So I can remove Uerror's system-dependentness. in place of CONST EFOO =1, EBAR = 2; I want: <*EXTERNAL*> (*const*) VAR EFOO, EBAR:int; UerrorC.c: #include enum { eEFOO = EFOO, eEBAR = EBAR }; const Max = sizeof(union { char a[EFOO]; char b[EBAR]; }); #undef EFOO #undef EBAR const EFOO = eEFOO; const EBAR = eEBAR; Very much like that. ok? I was probably going to do this tonight for cygwin/openbsd/amd64. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] making Uerror "portable"?Date: Mon, 12 Jan 2009 11:13:16 +1100 CONST is faster than VAR since the compiler can optimize them. Why would you want VAR? On 11 Jan 2009, at 19:58, Jay wrote: I still find pushing the system dependencies and cloned headers out of the system very tempting. To reduce what it takes to port to other systems, to raise the confidence of the correctness of any port, to keep ports correct in the face of possible underlying change. I think I'll change the case statements to if/else ladders and the consts to vars, that are actually statically initialized in C. This treatment is reasonable for other constants that remain in the cloned headers, system dependent or otherwise. - Jay From: jay.krell at cornell.eduTo: m3devel at elegosoft.comSubject: making Uerror "portable"?Date: Thu, 8 Jan 2009 06:36:44 +0000I've been thinking about "fixing" Uerrorto remove the system-dependentness of it. I have about given up. There are multiple easy options, but theyall have downsides that make me think itmight not be worth it. today it looks like: INTERFACE Uerror;CONST ENOFILE = 1; ENOMEM = 2;END Uerror; The values are intended the correct native values.There are a fair number of users.Fewer than 10 probably.They include switch/case statements, which requireconstants. The following are some of the possible changes,that make porting to basically any future systembe a no-op in this area, except for the occasional missing or possiblyequal errnos (if there is a switch in the C code; I ran into this case). - Change to VAR and initialize them in portable C code. disadvantages: more startup code possibly startup code runs too late more writable/written data (readonly data is best) slower to access not constant, not switchable, not source quite compatible You have to change the switch statements to "if ladders" (if/elseif/elseif/elseif). Compatible with most source, and incompatible source easily fixed. possible issues around "dynamic linking data" (not explained here, ask?) However not really a problem. More of a problem only on NT, and easily worked around just like is done for hand.obj. - change to VAR and const static initialize them in portable C "data" no additional startup code -- guaranteed initialized early enough no writable/written data slower to access not constant, not switchable, not source compatible (same as previous) same non-issue around dynamic linking of data - change to functions GetENOFILE(), GetENOMEM(), etc. slower to access definitely no problem dynamic linking easier to write the C code/data, no matter, the above are easy enough not constant, not switchable, not source compatible (similar to previous) - "translation"; introduce our own arbitrary values for any errno the system uses; change Cerrno.GetErrno to have a switch and translate from the native values to ours. This is fully source compatible, dynamic link compatible, in-between perf wise (slower to GetErrnor, but then constant and just as comparable/switchable), no initialization cost. Question then though what does any raised exception look like? Do the values get translated back? Or translated to strings? SetErrno translates back? Translation is at first simple and is unique among portable solutions in its source compatibility, but I am leary of it. I would rather a solution that traffics in unmodified native errnos values, but I don't that is viable with both constness and portability. To a large extent, translation is ok. If you look at SocketPosix.i3, it uses the errno very briefly to determine the next step to take. I don't think it ever returns or RAISEs it (or an exception containing it). But other parts of the system Fmt.Int(errno) and raise that, thus these become values that move through more of the system and therefore disagreement with the underlying system might show through. There is also question of how to chose "Max". Set it large, like 200? Set it "correctly"? Probably a better option is to make the cache that is currently Max-sized be instead small and fixed-size (e.g. 64), and "search" it quickly instead of "indexing" it very quickly, and always kick out the least recently used. I also have to check what the contents actually are, perhaps they are constant-initializable. Thoughts? I was somewhat keen to do something here, but have pretty much given up and will just generate Uerror.i3 for Solaris, NetBSD, FreeBSD, AIX, Irix, HP-UX, etc.. I might still be able to remove the Usignal and Ustat system-dependentness in m3core/src/unix, but Uerror will probably stand asis (in linux-common, openbsd-common, cygwin). In particular, I was putting off any more ports till I got the amount of work neededto port reduced to my satisfaction. I think I'm nearly there. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 02:19:35 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 01:19:35 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> Message-ID: btw, I don't think it's that hairy, I merely split it into two or three files, and added interfaces so they can reuse code with each other. Movement between files is hard to track though (depending on version control, but with all I've used). The SchedulerPosix implementation moved to ThreadPScheduler.m3. What is shared between it and ThreadPThread/Win32.m3 is ThreadInternal.i3, which maybe should be in ThreadF.i3, though that's exposed outside m3core, and ThreadInternal.i3 includes a variable. I can try again to debug Cygwin pthreads though. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:03:33 +1100> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Jay,> > Can you remind me again why Cygwin was unable to use pthreads? It > seems you have introduced a bunch of hair into the PTHREADS > implementation to deal with broken Cygwin pthreads. As many of us > have already pointed out, Cygwin should be a port that tries as much > as possible to be like a standard POSIX platform (pthread-based) as > opposed to a weird Windows/POSIX hybrid.> > I have a bunch of code that will be going into the PTHREADS base that > I am now at a loss to integrate with the changes you have made.> > Help!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 02:35:32 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 12:35:32 +1100 Subject: [M3devel] making Uerror "portable"? In-Reply-To: References: <118F7713-A9E8-441C-90EF-8D255C386078@cs.purdue.edu> Message-ID: On 12 Jan 2009, at 12:09, Jay wrote: > Understood. > So I can remove Uerror's system-dependentness. > > > in place of > CONST EFOO =1, EBAR = 2; > > I want: > > <*EXTERNAL*> (*const*) VAR EFOO, EBAR:int; This is gross. Again, if they are constants in C they should be constants in Modula-3. To reiterate: I think your contortions to eliminate C-header-file cloning are distorting the Modula-3 code in ways that make it much less transparent. Can we please revert some of these bad design decisions? > UerrorC.c: > #include > enum { eEFOO = EFOO, eEBAR = EBAR }; > const Max = sizeof(union { char a[EFOO]; char b[EBAR]; }); > #undef EFOO > #undef EBAR > const EFOO = eEFOO; > const EBAR = eEBAR; > > Very much like that. > ok? I was probably going to do this tonight for cygwin/openbsd/amd64. > > - Jay > > > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] making Uerror "portable"? > Date: Mon, 12 Jan 2009 11:13:16 +1100 > > > CONST is faster than VAR since the compiler can optimize them. Why > would you want VAR? > > On 11 Jan 2009, at 19:58, Jay wrote: > > I still find pushing the system dependencies and cloned headers out > of the system very tempting. > To reduce what it takes to port to other systems, to raise the > confidence of the correctness of any port, to keep ports correct in > the face of possible underlying change. > > I think I'll change the case statements to if/else ladders and the > consts to vars, that are actually statically initialized in C. This > treatment is reasonable for other constants that remain in the > cloned headers, system dependent or otherwise. > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: making Uerror "portable"? > Date: Thu, 8 Jan 2009 06:36:44 +0000 > > I've been thinking about "fixing" Uerror > to remove the system-dependentness of it. > > > I have about given up. > > > There are multiple easy options, but they > all have downsides that make me think it > might not be worth it. > > > today it looks like: > > > INTERFACE Uerror; > CONST > ENOFILE = 1; > ENOMEM = 2; > END Uerror; > > > The values are intended the correct native values. > There are a fair number of users. > Fewer than 10 probably. > They include switch/case statements, which require > constants. > > > The following are some of the possible changes, > that make porting to basically any future system > be a no-op in this area, except for the occasional missing or possibly > equal errnos (if there is a switch in the C code; I ran into this > case). > > > - Change to VAR and initialize them in portable C code. > disadvantages: > more startup code > possibly startup code runs too late > more writable/written data (readonly data is best) > slower to access > not constant, not switchable, not source quite compatible > You have to change the switch statements to "if ladders" (if/ > elseif/elseif/elseif). > Compatible with most source, and incompatible source easily > fixed. > possible issues around "dynamic linking data" (not explained > here, ask?) > However not really a problem. More of a problem only on NT, and > easily worked > around just like is done for hand.obj. > > > - change to VAR and const static initialize them in portable C "data" > no additional startup code -- guaranteed initialized early enough > no writable/written data > slower to access > not constant, not switchable, not source compatible (same as > previous) > same non-issue around dynamic linking of data > > > - change to functions GetENOFILE(), GetENOMEM(), etc. > slower to access > definitely no problem dynamic linking > easier to write the C code/data, no matter, the above > are easy enough > not constant, not switchable, not source compatible (similar to > previous) > > > - "translation"; introduce our own arbitrary values for > any errno the system uses; change Cerrno.GetErrno to have > a switch and translate from the native values to ours. > > > This is fully source compatible, dynamic link compatible, > in-between perf wise (slower to GetErrnor, but then constant > and just as comparable/switchable), no initialization cost. > > > Question then though what does any raised exception look like? > Do the values get translated back? Or translated to strings? > SetErrno translates back? > > > Translation is at first simple and is unique among portable > solutions > in its source compatibility, but I am leary of it. I would > rather a solution that traffics in unmodified native errnos > values, but > I don't that is viable with both constness and portability. > > > To a large extent, translation is ok. If you look at > SocketPosix.i3, it > uses the errno very briefly to determine the next step to take. > I don't think > it ever returns or RAISEs it (or an exception containing it). > > But other parts of the system Fmt.Int(errno) and raise that, thus > these become values that move through more of the system and > therefore > disagreement with the underlying system might show through. > > > There is also question of how to chose "Max". Set it large, like > 200? > Set it "correctly"? Probably a better option is to make the cache > that is currently Max-sized be instead small and fixed-size (e.g. > 64), > and "search" it quickly instead of "indexing" it very quickly, and > always > kick out the least recently used. I also have to check what the > contents actually are, perhaps they are constant-initializable. > > > Thoughts? > > > I was somewhat keen to do something here, but have pretty much > given up and > will just generate Uerror.i3 for Solaris, NetBSD, FreeBSD, AIX, > Irix, HP-UX, etc.. > I might still be able to remove the Usignal and Ustat system- > dependentness > in m3core/src/unix, but Uerror will probably stand asis (in linux- > common, > openbsd-common, cygwin). > > > In particular, I was putting off any more ports till I got the > amount of work needed > to port reduced to my satisfaction. I think I'm nearly there. > > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 02:32:15 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 12:32:15 +1100 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> Message-ID: <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> Jay, I really think you are bending over backwards too far just to be able to shoe-horn things into C. I *like* having the transpar of C header files expressed in Modula-3, *particularly* for system calls, where you might even be trying to build on a system that does not have the C header files installed, even though the libraries exist and can be linked to. Fundamentally, I think anytime the Modula-3 code is made less transparent you should think hard about what you are doing. The same with the change of constants to variables. I am getting very nervous that the changes you are making are destroying the clarity of the Modula-3 run-time code. In this particular case, you are wanting to use a Modula-3 parameter passing mechanism on something that is not declared in Modula-3. Seems kind of dubious to me. Also, I really don't like the idea of accessing external variables in C. -- Tony On 12 Jan 2009, at 11:55, Jay wrote: > I considered ADDRESS. > However I think it still doesn't satisfy. > > I want to be able to do this: > > TYPE Foo_t = something; > <* EXTERNAL *> VAR Foo1, Foo2:Foo_t; > <* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); > > (* Modula-3, not external *) > PROCEDURE x()= > BEGIN > UseFoo(Foo1); > UseFoo(Foo2); > END x; > > AND I want any use of: > VAR Foo3:Foo3_t; (* Modula-3, not external *) > > to error. This is sem_t and sigset_t in particular. > > Possibly renaming is the thing. > They used to be declared in Modula-3, system-dependently, but > I moved them to portable C. > > I could remove the types entirely and change UseFoo to take an > address, > and declare mask and ackSem to be integers or I guess. > <*EXTERNAL> VAR ackSem : RECORD END; > > That would satisfy but I thought it might be nicer to still provide > the named > types to refer to the external variables. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 11:13:00 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > > What's wrong with using ADDRESS for references to opaque values? If > sigset_t is never instantiated in Modula-3, then why do you need it > declared there? > > 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 01:44, Jay wrote: > > Is there a way in Modula-3 to declare that a type exists, and there > are <*external*> instances of it, without "fully" declaring it, so > that no Modula-3 can instantiate it? > > I have done this for sigset_t and sem_t, but they could erroneously > be instantiated by Modula-3 and I'd like to remove that ability to > mess up so easily. > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sigset_t = RECORD END; > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sem_t = RECORD END; > > In C I believe you can do this, like: > typedef struct foo foo_t; > extern foo_t foo; > > void UseFoo(foo_t*); > foo_t* GetFoo(void); > > Thanks, > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 02:42:39 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 12:42:39 +1100 Subject: [M3devel] ThreadPThread (PTHREAD) In-Reply-To: References: <20090111233442.57DE510D5FB1@birch.elegosoft.com> <23468C51-9108-4131-9B12-6BDA68AA648E@cs.purdue.edu> Message-ID: <45DAF3DE-F1E6-47C5-A113-BD94776197F9@cs.purdue.edu> On 12 Jan 2009, at 12:04, Jay wrote: > Yes I can explain mostly. > > > I was not able to get Cygwin/pthreads to work. > I don't know why. I could try another round of debugging. > It was a while ago, like a year ago. > I did debug it on some depth, rebuilding cygwin1.dll, and such. > I was inclined to give up. But now you are distorting the whole threads subsystem to work around a bug. Sounds screwy to me. > Consensus at the time was people didn't really care. > As long as they had forward slashes (which are abstracted > from code, but not from the user..and slow fork..), > and Modula-3 abstracted threads, > no matter how the Modula-3 threads were impelented. I care if the threads system becomes a tangled mess. > So Cygwin uses Win32 threads. Fine insofar as the implementation is hidden. But then you go on and try to impose POSIX thread semantics (for waitpid and friends) [as far as I understand things] onto a Win32 threads implementation. Weird. > More recently..well, it bothered me slightly that the "wait" code was > duplicated, but that's very little code. In looking at it though, I > realized > that Cygwin didn't have a proper SchedulerPosix, which I think is > an abstraction of select(). > > > What I did is move the SchedulerPosix code out of ThreadPThread. > This way it can be reused against ThreadPThread or ThreadWin32. Does this even make sense? > It is a fairly mechanical change, with no real semantic change. > I realize that movement of code from one file to another is hard to > track though > using simple text methods. > > > The stuff around "WaitPidYields" is what got me looking here and > has some value, but I think giving Cygwin a proper SchedulerPosix > is more valuable. I don't know what this comment refers to. Can you give a high-level overview? > WaitPidYields is contorted because sysutils bootstraps against old > m3core, > and I strongly suspect that sysutils exposes essentially a different > variant of m3core's abstractions, and cannot be implemented on top > of it. > That m3core hides too much for sysutils. sysutils is a *hack* that needs to be fixed so as not to expose m3core abstractions. It is only used in a very few places, and we would be much better situated if we figured out what functionality is needed by clients of sysutils rather than breaking m3core to let sysutils in on things. > If we bump up the minimum m3core that we build from, the contortions > can go away. "contortions" == "quake generating Modula-3 code, > with different names per client". What do you propose? What is the "minimum m3core"? What do we need to add to it? > > > > Make sense? > > - Jay > > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:12:36 +1100 > > CC: m3devel at elegosoft.com > > Subject: [M3devel] ThreadPThread (PTHREAD) > > > > Jay, can you give me a sense of what the purpose of your recent > > changes to the pthread-based threading code are intended to achieve? > > I haven't been able to follow too closely all the changes you are > > making, and I would like some sort of high-level rationale to help > me > > understand. Also, if sysutils has thread-dependent stuff in it > then I > > suggest sysutils should be rewritten to call the thread code rather > > than re-implement. m3core is a library that is always linked, so > > sysutils could easily depend on it. What's the problem? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 02:46:54 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 12:46:54 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> Message-ID: <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> You are smearing implementation details across multiple files and directories. Up until now, ThreadPThread has been nicely self- contained, and captured all the basic pieces of the thread implementation. Also, how does all of this fit with the ThreadPosix implementation? On 12 Jan 2009, at 12:19, Jay wrote: > btw, I don't think it's that hairy, I merely split it into two or > three files, and added interfaces so they can reuse code with each > other. Movement between files is hard to track though (depending on > version control, but with all I've used). > > The SchedulerPosix implementation moved to ThreadPScheduler.m3. > What is shared between it and ThreadPThread/Win32.m3 is > ThreadInternal.i3, which maybe should be in ThreadF.i3, though > that's exposed outside m3core, and ThreadInternal.i3 includes a > variable. > > I can try again to debug Cygwin pthreads though. > > - Jay > > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:03:33 +1100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay, > > > > Can you remind me again why Cygwin was unable to use pthreads? It > > seems you have introduced a bunch of hair into the PTHREADS > > implementation to deal with broken Cygwin pthreads. As many of us > > have already pointed out, Cygwin should be a port that tries as much > > as possible to be like a standard POSIX platform (pthread-based) as > > opposed to a weird Windows/POSIX hybrid. > > > > I have a bunch of code that will be going into the PTHREADS base > that > > I am now at a loss to integrate with the changes you have made. > > > > Help! > > > > -- Tony > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 01:13:16 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 11:13:16 +1100 Subject: [M3devel] making Uerror "portable"? In-Reply-To: References: Message-ID: <118F7713-A9E8-441C-90EF-8D255C386078@cs.purdue.edu> CONST is faster than VAR since the compiler can optimize them. Why would you want VAR? On 11 Jan 2009, at 19:58, Jay wrote: > I still find pushing the system dependencies and cloned headers out > of the system very tempting. > To reduce what it takes to port to other systems, to raise the > confidence of the correctness of any port, to keep ports correct in > the face of possible underlying change. > > I think I'll change the case statements to if/else ladders and the > consts to vars, that are actually statically initialized in C. This > treatment is reasonable for other constants that remain in the > cloned headers, system dependent or otherwise. > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: making Uerror "portable"? > Date: Thu, 8 Jan 2009 06:36:44 +0000 > > I've been thinking about "fixing" Uerror > to remove the system-dependentness of it. > > > I have about given up. > > > There are multiple easy options, but they > all have downsides that make me think it > might not be worth it. > > > today it looks like: > > > INTERFACE Uerror; > CONST > ENOFILE = 1; > ENOMEM = 2; > END Uerror; > > > The values are intended the correct native values. > There are a fair number of users. > Fewer than 10 probably. > They include switch/case statements, which require > constants. > > > The following are some of the possible changes, > that make porting to basically any future system > be a no-op in this area, except for the occasional missing or possibly > equal errnos (if there is a switch in the C code; I ran into this > case). > > > - Change to VAR and initialize them in portable C code. > disadvantages: > more startup code > possibly startup code runs too late > more writable/written data (readonly data is best) > slower to access > not constant, not switchable, not source quite compatible > You have to change the switch statements to "if ladders" (if/ > elseif/elseif/elseif). > Compatible with most source, and incompatible source easily > fixed. > possible issues around "dynamic linking data" (not explained > here, ask?) > However not really a problem. More of a problem only on NT, and > easily worked > around just like is done for hand.obj. > > > - change to VAR and const static initialize them in portable C "data" > no additional startup code -- guaranteed initialized early enough > no writable/written data > slower to access > not constant, not switchable, not source compatible (same as > previous) > same non-issue around dynamic linking of data > > > - change to functions GetENOFILE(), GetENOMEM(), etc. > slower to access > definitely no problem dynamic linking > easier to write the C code/data, no matter, the above > are easy enough > not constant, not switchable, not source compatible (similar to > previous) > > > - "translation"; introduce our own arbitrary values for > any errno the system uses; change Cerrno.GetErrno to have > a switch and translate from the native values to ours. > > > This is fully source compatible, dynamic link compatible, > in-between perf wise (slower to GetErrnor, but then constant > and just as comparable/switchable), no initialization cost. > > > Question then though what does any raised exception look like? > Do the values get translated back? Or translated to strings? > SetErrno translates back? > > > Translation is at first simple and is unique among portable > solutions > in its source compatibility, but I am leary of it. I would > rather a solution that traffics in unmodified native errnos > values, but > I don't that is viable with both constness and portability. > > > To a large extent, translation is ok. If you look at > SocketPosix.i3, it > uses the errno very briefly to determine the next step to take. > I don't think > it ever returns or RAISEs it (or an exception containing it). > > But other parts of the system Fmt.Int(errno) and raise that, thus > these become values that move through more of the system and > therefore > disagreement with the underlying system might show through. > > > There is also question of how to chose "Max". Set it large, like > 200? > Set it "correctly"? Probably a better option is to make the cache > that is currently Max-sized be instead small and fixed-size (e.g. > 64), > and "search" it quickly instead of "indexing" it very quickly, and > always > kick out the least recently used. I also have to check what the > contents actually are, perhaps they are constant-initializable. > > > Thoughts? > > > I was somewhat keen to do something here, but have pretty much > given up and > will just generate Uerror.i3 for Solaris, NetBSD, FreeBSD, AIX, > Irix, HP-UX, etc.. > I might still be able to remove the Usignal and Ustat system- > dependentness > in m3core/src/unix, but Uerror will probably stand asis (in linux- > common, > openbsd-common, cygwin). > > > In particular, I was putting off any more ports till I got the > amount of work needed > to port reduced to my satisfaction. I think I'm nearly there. > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: [M3devel] [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 hosking at cs.purdue.edu Mon Jan 12 05:27:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 15:27:07 +1100 Subject: [M3devel] waitpid contortions Message-ID: <055997B8-7083-4DF6-A373-D2BF3E4351BC@cs.purdue.edu> Jay, To avoid your contortions surrounding usage of waitpid in sysutils, I propose the following. Implement ThreadPosix.WaitProcess as a thing wrapper over waitpid: PROCEDURE WaitProcess (pid: int; VAR status: int): int = (* ThreadPThread.m3 and ThreadPosix.m3 are very similar. *) BEGIN LOOP WITH r = Uexec.waitpid(pid, ADR(status), 0) DO <*ASSERT r # 0*> IF r > 0 THEN RETURN r END; IF Cerrno.GetErrno() # Uerror.EINTR THEN RETURN r END; END; END; END WaitProcess; Implement Process.Wait as it used to be originally, calling SchedulerPosix.WaitProcess instead of waitpid. Implement SystemPosix.Wait using SchedulerPosix.Wait to throw exceptions as defined in the original code. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 05:46:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 15:46:34 +1100 Subject: [M3devel] waitpid Message-ID: Does anyone know why the SchedulerPosix.Wait code (which originally came from ProcessPosix.m3 and is similar in SystemPosix.m3) was doing strange unpacking of the status word returned from waitpid? It seems to be unnecessary when waitpid is typed as: int waitpid (pid_t pid, int *status, int options) From jay.krell at cornell.edu Mon Jan 12 07:39:26 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 06:39:26 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: ThreadPosix is basically unaffected -- I never provided user threads on Cygwin. I guess it got a slight reduction regarding DoesWaitPidYield, but its SchedulerPosix implementation was unchanged. The code in ThreadPosix is similar to but different than ThreadPThread. It is possible they could be merged but it wasn't trivial so I left ThreadPosix alone. > You are smearing implementation details across multiple files and directories You really think it is bad to have SchedulerPosix implemented in a small separate file? On top of what happens to be common implementation details of ThreadPThread.m3 and ThreadWin32.m3? ThreadPScheduler.m3 is just basically three functions: IOWait, IOAlertWait, XIOWait Plus the little internal utility, UTimeFromTime, the one liner DoesWaitPidYield, and non-trivial functions nested in XIOWait: TestFDS, CallSelect. I mean, you know, an alternative is to copy out very large chunks of ThreadWin32.m3 and ThreadPThread.m3 and merge them into ThreadCygwin.m3. That would be worse imho. "Directories" hardly. Or I can try debugging cygwin pthreads again. - Jay CC: jkrell at elego.de; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 12:46:54 +1100You are smearing implementation details across multiple files and directories. Up until now, ThreadPThread has been nicely self-contained, and captured all the basic pieces of the thread implementation. Also, how does all of this fit with the ThreadPosix implementation? On 12 Jan 2009, at 12:19, Jay wrote: btw, I don't think it's that hairy, I merely split it into two or three files, and added interfaces so they can reuse code with each other. Movement between files is hard to track though (depending on version control, but with all I've used). The SchedulerPosix implementation moved to ThreadPScheduler.m3.What is shared between it and ThreadPThread/Win32.m3 is ThreadInternal.i3, which maybe should be in ThreadF.i3, though that's exposed outside m3core, and ThreadInternal.i3 includes a variable. I can try again to debug Cygwin pthreads though. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:03:33 +1100> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Jay,> > Can you remind me again why Cygwin was unable to use pthreads? It > seems you have introduced a bunch of hair into the PTHREADS > implementation to deal with broken Cygwin pthreads. As many of us > have already pointed out, Cygwin should be a port that tries as much > as possible to be like a standard POSIX platform (pthread-based) as > opposed to a weird Windows/POSIX hybrid.> > I have a bunch of code that will be going into the PTHREADS base that > I am now at a loss to integrate with the changes you have made.> > Help!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: [M3devel] [M3commit] 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: [M3devel] [M3commit] 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 hosking at cs.purdue.edu Mon Jan 12 07:53:02 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 17:53:02 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: Why does sysutils need to be compatible with both old and new versions of m3core? On 12 Jan 2009, at 17:39, Jay wrote: > ThreadPosix is basically unaffected -- I never provided user threads > on Cygwin. > I guess it got a slight reduction regarding DoesWaitPidYield, but > its SchedulerPosix implementation was unchanged. > > The code in ThreadPosix is similar to but different than > ThreadPThread. > It is possible they could be merged but it wasn't trivial so I left > ThreadPosix alone. > > > You are smearing implementation details across multiple files and > directories > > You really think it is bad to have SchedulerPosix implemented in a > small separate file? > On top of what happens to be common implementation details of > ThreadPThread.m3 and ThreadWin32.m3? > > ThreadPScheduler.m3 is just basically three functions: IOWait, > IOAlertWait, XIOWait > Plus the little internal utility, UTimeFromTime, the one liner > DoesWaitPidYield, and non-trivial functions nested in XIOWait: > TestFDS, CallSelect. > > I mean, you know, an alternative is to copy out very large chunks of > ThreadWin32.m3 and ThreadPThread.m3 and merge them into > ThreadCygwin.m3. That would be worse imho. > > "Directories" hardly. > > Or I can try debugging cygwin pthreads again. > > - Jay > > > CC: jkrell at elego.de; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Mon, 12 Jan 2009 12:46:54 +1100 > > You are smearing implementation details across multiple files and > directories. Up until now, ThreadPThread has been nicely self- > contained, and captured all the basic pieces of the thread > implementation. Also, how does all of this fit with the ThreadPosix > implementation? > > On 12 Jan 2009, at 12:19, Jay wrote: > > btw, I don't think it's that hairy, I merely split it into two or > three files, and added interfaces so they can reuse code with each > other. Movement between files is hard to track though (depending on > version control, but with all I've used). > > The SchedulerPosix implementation moved to ThreadPScheduler.m3. > What is shared between it and ThreadPThread/Win32.m3 is > ThreadInternal.i3, which maybe should be in ThreadF.i3, though > that's exposed outside m3core, and ThreadInternal.i3 includes a > variable. > > I can try again to debug Cygwin pthreads though. > > - Jay > > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:03:33 +1100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay, > > > > Can you remind me again why Cygwin was unable to use pthreads? It > > seems you have introduced a bunch of hair into the PTHREADS > > implementation to deal with broken Cygwin pthreads. As many of us > > have already pointed out, Cygwin should be a port that tries as much > > as possible to be like a standard POSIX platform (pthread-based) as > > opposed to a weird Windows/POSIX hybrid. > > > > I have a bunch of code that will be going into the PTHREADS base > that > > I am now at a loss to integrate with the changes you have made. > > > > Help! > > > > -- Tony > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 07:58:00 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 06:58:00 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> Message-ID: We have conflicting goals. Keeping things as fast as possible and with as little C as possible, vs. keeping things more portable, more easily ported, more obviously correct. I want to drastically reduce the header cloning, or, the work of porting. It is already reduced, but I want to keep going. I think having to make any changes at all in m3-libs/m3core/src/unix can be removed, other than adding the platform to the list of platforms that uses the "portable" stuff. Porting would devolve to: update the lists of platforms -- including some in m3makefiles update Target.m3 clone/edit Csetjmp.i3 add the GNU platform to m3cc/src/makefile and maybe nothing else. It is likely even that the IR is now portable, for "Posix" systems. Pick word size, pick endian, generate 4 versions of IR, pick the right one for your platform. Except for the OSConfigPosix that sometimes returns the platform name and cm3's defining "HOST". A variable isn't great, but it is faster and more source compatible than a function call, at least. And the C variable really will generally be read only. Writes to it should fault. > In this particular case, you are wanting to use a Modula-3 parameter > passing mechanism on something that is not declared in Modula-3. Isn't this just a variation on what is done all the time? -- having Modula-3 call C and sometimes vice versa? C code calls Modula-3 signal handlers, with data created in the C code. The Modula-3 code can then pass them on. I don't see the line really. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 12:32:15 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it? Jay, I really think you are bending over backwards too far just to be able to shoe-horn things into C. I *like* having the transpar of C header files expressed in Modula-3, *particularly* for system calls, where you might even be trying to build on a system that does not have the C header files installed, even though the libraries exist and can be linked to. Fundamentally, I think anytime the Modula-3 code is made less transparent you should think hard about what you are doing. The same with the change of constants to variables. I am getting very nervous that the changes you are making are destroying the clarity of the Modula-3 run-time code. In this particular case, you are wanting to use a Modula-3 parameter passing mechanism on something that is not declared in Modula-3. Seems kind of dubious to me. Also, I really don't like the idea of accessing external variables in C. -- Tony On 12 Jan 2009, at 11:55, Jay wrote: I considered ADDRESS.However I think it still doesn't satisfy. I want to be able to do this: TYPE Foo_t = something;<* EXTERNAL *> VAR Foo1, Foo2:Foo_t;<* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); (* Modula-3, not external *)PROCEDURE x()=BEGIN UseFoo(Foo1); UseFoo(Foo2);END x; AND I want any use of:VAR Foo3:Foo3_t; (* Modula-3, not external *)to error. This is sem_t and sigset_t in particular. Possibly renaming is the thing.They used to be declared in Modula-3, system-dependently, butI moved them to portable C. I could remove the types entirely and change UseFoo to take an address,and declare mask and ackSem to be integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END; That would satisfy but I thought it might be nicer to still provide the namedtypes to refer to the external variables. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?What's wrong with using ADDRESS for references to opaque values? If sigset_t is never instantiated in Modula-3, then why do you need it declared there? 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 01:44, Jay wrote: Is there a way in Modula-3 to declare that a type exists, and there are <*external*> instances of it, without "fully" declaring it, so that no Modula-3 can instantiate it? I have done this for sigset_t and sem_t, but they could erroneously be instantiated by Modula-3 and I'd like to remove that ability to mess up so easily. (* This type is not declared correctly. It is only instantiated in C code. *) sigset_t = RECORD END;(* This type is not declared correctly. It is only instantiated in C code. *) sem_t = RECORD END;In C I believe you can do this, like: typedef struct foo foo_t; extern foo_t foo; void UseFoo(foo_t*); foo_t* GetFoo(void); Thanks, - Jay -------------- 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: [M3devel] [M3commit] 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 jay.krell at cornell.edu Mon Jan 12 07:58:44 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 06:58:44 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: To bootstrap I believe. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 17:53:02 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3Why does sysutils need to be compatible with both old and new versions of m3core? On 12 Jan 2009, at 17:39, Jay wrote: ThreadPosix is basically unaffected -- I never provided user threads on Cygwin. I guess it got a slight reduction regarding DoesWaitPidYield, but its SchedulerPosix implementation was unchanged. The code in ThreadPosix is similar to but different than ThreadPThread.It is possible they could be merged but it wasn't trivial so I left ThreadPosix alone. > You are smearing implementation details across multiple files and directories You really think it is bad to have SchedulerPosix implemented in a small separate file?On top of what happens to be common implementation details of ThreadPThread.m3 and ThreadWin32.m3? ThreadPScheduler.m3 is just basically three functions: IOWait, IOAlertWait, XIOWaitPlus the little internal utility, UTimeFromTime, the one liner DoesWaitPidYield, and non-trivial functions nested in XIOWait: TestFDS, CallSelect. I mean, you know, an alternative is to copy out very large chunks of ThreadWin32.m3 and ThreadPThread.m3 and merge them into ThreadCygwin.m3. That would be worse imho. "Directories" hardly. Or I can try debugging cygwin pthreads again. - Jay CC: jkrell at elego.de; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 12:46:54 +1100You are smearing implementation details across multiple files and directories. Up until now, ThreadPThread has been nicely self-contained, and captured all the basic pieces of the thread implementation. Also, how does all of this fit with the ThreadPosix implementation? On 12 Jan 2009, at 12:19, Jay wrote: btw, I don't think it's that hairy, I merely split it into two or three files, and added interfaces so they can reuse code with each other. Movement between files is hard to track though (depending on version control, but with all I've used). The SchedulerPosix implementation moved to ThreadPScheduler.m3.What is shared between it and ThreadPThread/Win32.m3 is ThreadInternal.i3, which maybe should be in ThreadF.i3, though that's exposed outside m3core, and ThreadInternal.i3 includes a variable. I can try again to debug Cygwin pthreads though. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:03:33 +1100> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Jay,> > Can you remind me again why Cygwin was unable to use pthreads? It > seems you have introduced a bunch of hair into the PTHREADS > implementation to deal with broken Cygwin pthreads. As many of us > have already pointed out, Cygwin should be a port that tries as much > as possible to be like a standard POSIX platform (pthread-based) as > opposed to a weird Windows/POSIX hybrid.> > I have a bunch of code that will be going into the PTHREADS base that > I am now at a loss to integrate with the changes you have made.> > Help!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 08:04:46 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 18:04:46 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: Jay, Your changes are occurring way too fast for us to keep up with you, and some of them are distorting the code base unnecessarily. When you make these sorts of drastic reorgs it is important that the primary developers are in consensus. Right now I am most distressed by the damage that seems to have been done to m3core/src/thread -- I haven't had time to look over the other things you've been doing closely enough to know. For now, I am going to go in and change the source code head to reflect what I believe the solution for waitpid should look like. On 12 Jan 2009, at 17:53, Tony Hosking wrote: > Why does sysutils need to be compatible with both old and new > versions of m3core? > > On 12 Jan 2009, at 17:39, Jay wrote: > >> ThreadPosix is basically unaffected -- I never provided user >> threads on Cygwin. >> I guess it got a slight reduction regarding DoesWaitPidYield, but >> its SchedulerPosix implementation was unchanged. >> >> The code in ThreadPosix is similar to but different than >> ThreadPThread. >> It is possible they could be merged but it wasn't trivial so I left >> ThreadPosix alone. >> >> > You are smearing implementation details across multiple files >> and directories >> >> You really think it is bad to have SchedulerPosix implemented in a >> small separate file? >> On top of what happens to be common implementation details of >> ThreadPThread.m3 and ThreadWin32.m3? >> >> ThreadPScheduler.m3 is just basically three functions: IOWait, >> IOAlertWait, XIOWait >> Plus the little internal utility, UTimeFromTime, the one liner >> DoesWaitPidYield, and non-trivial functions nested in XIOWait: >> TestFDS, CallSelect. >> >> I mean, you know, an alternative is to copy out very large chunks >> of ThreadWin32.m3 and ThreadPThread.m3 and merge them into >> ThreadCygwin.m3. That would be worse imho. >> >> "Directories" hardly. >> >> Or I can try debugging cygwin pthreads again. >> >> - Jay >> >> >> CC: jkrell at elego.de; m3devel at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Subject: Re: [M3devel] [M3commit] CVS Update: cm3 >> Date: Mon, 12 Jan 2009 12:46:54 +1100 >> >> You are smearing implementation details across multiple files and >> directories. Up until now, ThreadPThread has been nicely self- >> contained, and captured all the basic pieces of the thread >> implementation. Also, how does all of this fit with the >> ThreadPosix implementation? >> >> On 12 Jan 2009, at 12:19, Jay wrote: >> >> btw, I don't think it's that hairy, I merely split it into two or >> three files, and added interfaces so they can reuse code with each >> other. Movement between files is hard to track though (depending on >> version control, but with all I've used). >> >> The SchedulerPosix implementation moved to ThreadPScheduler.m3. >> What is shared between it and ThreadPThread/Win32.m3 is >> ThreadInternal.i3, which maybe should be in ThreadF.i3, though >> that's exposed outside m3core, and ThreadInternal.i3 includes a >> variable. >> >> I can try again to debug Cygwin pthreads though. >> >> - Jay >> >> >> > From: hosking at cs.purdue.edu >> > To: jkrell at elego.de >> > Date: Mon, 12 Jan 2009 11:03:33 +1100 >> > CC: m3devel at elegosoft.com >> > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 >> > >> > Jay, >> > >> > Can you remind me again why Cygwin was unable to use pthreads? It >> > seems you have introduced a bunch of hair into the PTHREADS >> > implementation to deal with broken Cygwin pthreads. As many of us >> > have already pointed out, Cygwin should be a port that tries as >> much >> > as possible to be like a standard POSIX platform (pthread-based) as >> > opposed to a weird Windows/POSIX hybrid. >> > >> > I have a bunch of code that will be going into the PTHREADS base >> that >> > I am now at a loss to integrate with the changes you have made. >> > >> > Help! >> > >> > -- 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: [M3devel] [M3commit] 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: [M3devel] [M3commit] 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: [M3devel] [M3commit] 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: [M3devel] [M3commit] 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 hosking at cs.purdue.edu Mon Jan 12 08:19:55 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 18:19:55 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: Not true. sysutils should be built against the m3core with which it will be linked. I don't think this is correct. On 12 Jan 2009, at 17:58, Jay wrote: > To bootstrap I believe. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 17:53:02 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Why does sysutils need to be compatible with both old and new > versions of m3core? > > On 12 Jan 2009, at 17:39, Jay wrote: > > ThreadPosix is basically unaffected -- I never provided user threads > on Cygwin. > I guess it got a slight reduction regarding DoesWaitPidYield, but > its SchedulerPosix implementation was unchanged. > > The code in ThreadPosix is similar to but different than > ThreadPThread. > It is possible they could be merged but it wasn't trivial so I left > ThreadPosix alone. > > > You are smearing implementation details across multiple files and > directories > > You really think it is bad to have SchedulerPosix implemented in a > small separate file? > On top of what happens to be common implementation details of > ThreadPThread.m3 and ThreadWin32.m3? > > ThreadPScheduler.m3 is just basically three functions: IOWait, > IOAlertWait, XIOWait > Plus the little internal utility, UTimeFromTime, the one liner > DoesWaitPidYield, and non-trivial functions nested in XIOWait: > TestFDS, CallSelect. > > I mean, you know, an alternative is to copy out very large chunks of > ThreadWin32.m3 and ThreadPThread.m3 and merge them into > ThreadCygwin.m3. That would be worse imho. > > "Directories" hardly. > > Or I can try debugging cygwin pthreads again. > > - Jay > > > CC: jkrell at elego.de; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Mon, 12 Jan 2009 12:46:54 +1100 > > You are smearing implementation details across multiple files and > directories. Up until now, ThreadPThread has been nicely self- > contained, and captured all the basic pieces of the thread > implementation. Also, how does all of this fit with the ThreadPosix > implementation? > > On 12 Jan 2009, at 12:19, Jay wrote: > > btw, I don't think it's that hairy, I merely split it into two or > three files, and added interfaces so they can reuse code with each > other. Movement between files is hard to track though (depending on > version control, but with all I've used). > > The SchedulerPosix implementation moved to ThreadPScheduler.m3. > What is shared between it and ThreadPThread/Win32.m3 is > ThreadInternal.i3, which maybe should be in ThreadF.i3, though > that's exposed outside m3core, and ThreadInternal.i3 includes a > variable. > > I can try again to debug Cygwin pthreads though. > > - Jay > > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:03:33 +1100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay, > > > > Can you remind me again why Cygwin was unable to use pthreads? It > > seems you have introduced a bunch of hair into the PTHREADS > > implementation to deal with broken Cygwin pthreads. As many of us > > have already pointed out, Cygwin should be a port that tries as much > > as possible to be like a standard POSIX platform (pthread-based) as > > opposed to a weird Windows/POSIX hybrid. > > > > I have a bunch of code that will be going into the PTHREADS base > that > > I am now at a loss to integrate with the changes you have made. > > > > Help! > > > > -- 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: [M3devel] [M3commit] 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 hosking at cs.purdue.edu Mon Jan 12 08:24:43 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 18:24:43 +1100 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> Message-ID: Jay, What the hell is the ROOT variable supposed to do now. I can't build m3core with a compiler that doesn't define ROOT. And why does the m3makefile that includes Uwaitpid.quake expect a hardwired cm3 directory hierarchy. Surely, I should be able to build m3core as a separate package, regardless of the structure in which it appears. You are doing damage to the package structures here too, by hardwiring these paths into the m3makefile. -- Tony On 12 Jan 2009, at 17:58, Jay wrote: > We have conflicting goals. > > Keeping things as fast as possible and with as little C as possible, > vs. keeping things more portable, more easily ported, more obviously > correct. > > I want to drastically reduce the header cloning, or, the work of > porting. > It is already reduced, but I want to keep going. > I think having to make any changes at all in m3-libs/m3core/src/ > unix can be removed, other than adding the platform to the list of > platforms that uses the "portable" stuff. > Porting would devolve to: > update the lists of platforms -- including some in m3makefiles > update Target.m3 > clone/edit Csetjmp.i3 > add the GNU platform to m3cc/src/makefile > > and maybe nothing else. > > It is likely even that the IR is now portable, for "Posix" systems. > Pick word size, pick endian, generate 4 versions of IR, pick the > right one for your platform. > Except for the OSConfigPosix that sometimes returns the platform > name and cm3's defining "HOST". > > A variable isn't great, but it is faster and more source compatible > than a function call, at least. > And the C variable really will generally be read only. Writes to it > should fault. > > > In this particular case, you are wanting to use a Modula-3 > parameter > > passing mechanism on something that is not declared in Modula-3. > > Isn't this just a variation on what is done all the time? -- having > Modula-3 call C and sometimes vice versa? > C code calls Modula-3 signal handlers, with data created in the C > code. The Modula-3 code can then pass them on. I don't see the line > really. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 12:32:15 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > > > Jay, I really think you are bending over backwards too far just to > be able to shoe-horn things into C. I *like* having the transpar of > C header files expressed in Modula-3, *particularly* for system > calls, where you might even be trying to build on a system that does > not have the C header files installed, even though the libraries > exist and can be linked to. Fundamentally, I think anytime the > Modula-3 code is made less transparent you should think hard about > what you are doing. The same with the change of constants to > variables. > > I am getting very nervous that the changes you are making are > destroying the clarity of the Modula-3 run-time code. > > In this particular case, you are wanting to use a Modula-3 parameter > passing mechanism on something that is not declared in Modula-3. > Seems kind of dubious to me. Also, I really don't like the idea of > accessing external variables in C. > > -- Tony > > On 12 Jan 2009, at 11:55, Jay wrote: > > I considered ADDRESS. > However I think it still doesn't satisfy. > > I want to be able to do this: > > TYPE Foo_t = something; > <* EXTERNAL *> VAR Foo1, Foo2:Foo_t; > <* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); > > (* Modula-3, not external *) > PROCEDURE x()= > BEGIN > UseFoo(Foo1); > UseFoo(Foo2); > END x; > > AND I want any use of: > VAR Foo3:Foo3_t; (* Modula-3, not external *) > > to error. This is sem_t and sigset_t in particular. > > Possibly renaming is the thing. > They used to be declared in Modula-3, system-dependently, but > I moved them to portable C. > > I could remove the types entirely and change UseFoo to take an > address, > and declare mask and ackSem to be integers or I guess. > <*EXTERNAL> VAR ackSem : RECORD END; > > That would satisfy but I thought it might be nicer to still provide > the named > types to refer to the external variables. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 11:13:00 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > > What's wrong with using ADDRESS for references to opaque values? If > sigset_t is never instantiated in Modula-3, then why do you need it > declared there? > > 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 01:44, Jay wrote: > > Is there a way in Modula-3 to declare that a type exists, and there > are <*external*> instances of it, without "fully" declaring it, so > that no Modula-3 can instantiate it? > > I have done this for sigset_t and sem_t, but they could erroneously > be instantiated by Modula-3 and I'd like to remove that ability to > mess up so easily. > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sigset_t = RECORD END; > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sem_t = RECORD END; > > In C I believe you can do this, like: > typedef struct foo foo_t; > extern foo_t foo; > > void UseFoo(foo_t*); > foo_t* GetFoo(void); > > Thanks, > - Jay > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 08:25:03 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 07:25:03 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: The compiler uses sysutils. The first pass builds against an old package store, which might not have sysutils at all, if it is that old. Again, once new m3core is around, no problem. I could/should have put in the m3core change and just waited on the sysutils change, rather than go ahead and do the quake stuff, and we can do that now (or your change that moots it, which I haven't looked into yet). I was browsing the docs and it appears there is an "import_pkg" directive for like, copying in a package contents, instead of linking. That might also solve this. I found that relatively late and never looked into it. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:19:55 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3Not true. sysutils should be built against the m3core with which it will be linked. I don't think this is correct. On 12 Jan 2009, at 17:58, Jay wrote: To bootstrap I believe. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 17:53:02 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3Why does sysutils need to be compatible with both old and new versions of m3core? On 12 Jan 2009, at 17:39, Jay wrote: ThreadPosix is basically unaffected -- I never provided user threads on Cygwin. I guess it got a slight reduction regarding DoesWaitPidYield, but its SchedulerPosix implementation was unchanged. The code in ThreadPosix is similar to but different than ThreadPThread.It is possible they could be merged but it wasn't trivial so I left ThreadPosix alone. > You are smearing implementation details across multiple files and directories You really think it is bad to have SchedulerPosix implemented in a small separate file?On top of what happens to be common implementation details of ThreadPThread.m3 and ThreadWin32.m3? ThreadPScheduler.m3 is just basically three functions: IOWait, IOAlertWait, XIOWaitPlus the little internal utility, UTimeFromTime, the one liner DoesWaitPidYield, and non-trivial functions nested in XIOWait: TestFDS, CallSelect. I mean, you know, an alternative is to copy out very large chunks of ThreadWin32.m3 and ThreadPThread.m3 and merge them into ThreadCygwin.m3. That would be worse imho. "Directories" hardly. Or I can try debugging cygwin pthreads again. - Jay CC: jkrell at elego.de; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 12:46:54 +1100You are smearing implementation details across multiple files and directories. Up until now, ThreadPThread has been nicely self-contained, and captured all the basic pieces of the thread implementation. Also, how does all of this fit with the ThreadPosix implementation? On 12 Jan 2009, at 12:19, Jay wrote: btw, I don't think it's that hairy, I merely split it into two or three files, and added interfaces so they can reuse code with each other. Movement between files is hard to track though (depending on version control, but with all I've used). The SchedulerPosix implementation moved to ThreadPScheduler.m3.What is shared between it and ThreadPThread/Win32.m3 is ThreadInternal.i3, which maybe should be in ThreadF.i3, though that's exposed outside m3core, and ThreadInternal.i3 includes a variable. I can try again to debug Cygwin pthreads though. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:03:33 +1100> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Jay,> > Can you remind me again why Cygwin was unable to use pthreads? It > seems you have introduced a bunch of hair into the PTHREADS > implementation to deal with broken Cygwin pthreads. As many of us > have already pointed out, Cygwin should be a port that tries as much > as possible to be like a standard POSIX platform (pthread-based) as > opposed to a weird Windows/POSIX hybrid.> > I have a bunch of code that will be going into the PTHREADS base that > I am now at a loss to integrate with the changes you have made.> > Help!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 08:27:09 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 07:27:09 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> Message-ID: Huh..that's what I was saying about the way m3overrides work -- the directory structure IS duplicated /everywhere/.. I don't know what choice there is, if quake code is to be shared across packages. m3tests does the same sort of thing, also to me. Ok, hold, I'll slow sysutils back down. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:24:43 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?Jay, What the hell is the ROOT variable supposed to do now. I can't build m3core with a compiler that doesn't define ROOT. And why does the m3makefile that includes Uwaitpid.quake expect a hardwired cm3 directory hierarchy. Surely, I should be able to build m3core as a separate package, regardless of the structure in which it appears. You are doing damage to the package structures here too, by hardwiring these paths into the m3makefile. -- Tony On 12 Jan 2009, at 17:58, Jay wrote: We have conflicting goals. Keeping things as fast as possible and with as little C as possible, vs. keeping things more portable, more easily ported, more obviously correct. I want to drastically reduce the header cloning, or, the work of porting. It is already reduced, but I want to keep going. I think having to make any changes at all in m3-libs/m3core/src/unix can be removed, other than adding the platform to the list of platforms that uses the "portable" stuff.Porting would devolve to: update the lists of platforms -- including some in m3makefiles update Target.m3 clone/edit Csetjmp.i3 add the GNU platform to m3cc/src/makefile and maybe nothing else. It is likely even that the IR is now portable, for "Posix" systems.Pick word size, pick endian, generate 4 versions of IR, pick the right one for your platform.Except for the OSConfigPosix that sometimes returns the platform name and cm3's defining "HOST". A variable isn't great, but it is faster and more source compatible than a function call, at least.And the C variable really will generally be read only. Writes to it should fault. > In this particular case, you are wanting to use a Modula-3 parameter > passing mechanism on something that is not declared in Modula-3. Isn't this just a variation on what is done all the time? -- having Modula-3 call C and sometimes vice versa?C code calls Modula-3 signal handlers, with data created in the C code. The Modula-3 code can then pass them on. I don't see the line really. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 12:32:15 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it? Jay, I really think you are bending over backwards too far just to be able to shoe-horn things into C. I *like* having the transpar of C header files expressed in Modula-3, *particularly* for system calls, where you might even be trying to build on a system that does not have the C header files installed, even though the libraries exist and can be linked to. Fundamentally, I think anytime the Modula-3 code is made less transparent you should think hard about what you are doing. The same with the change of constants to variables. I am getting very nervous that the changes you are making are destroying the clarity of the Modula-3 run-time code. In this particular case, you are wanting to use a Modula-3 parameter passing mechanism on something that is not declared in Modula-3. Seems kind of dubious to me. Also, I really don't like the idea of accessing external variables in C. -- Tony On 12 Jan 2009, at 11:55, Jay wrote: I considered ADDRESS.However I think it still doesn't satisfy. I want to be able to do this: TYPE Foo_t = something;<* EXTERNAL *> VAR Foo1, Foo2:Foo_t;<* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); (* Modula-3, not external *)PROCEDURE x()=BEGIN UseFoo(Foo1); UseFoo(Foo2);END x; AND I want any use of:VAR Foo3:Foo3_t; (* Modula-3, not external *)to error. This is sem_t and sigset_t in particular. Possibly renaming is the thing.They used to be declared in Modula-3, system-dependently, butI moved them to portable C. I could remove the types entirely and change UseFoo to take an address,and declare mask and ackSem to be integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END; That would satisfy but I thought it might be nicer to still provide the namedtypes to refer to the external variables. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?What's wrong with using ADDRESS for references to opaque values? If sigset_t is never instantiated in Modula-3, then why do you need it declared there? 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 01:44, Jay wrote: Is there a way in Modula-3 to declare that a type exists, and there are <*external*> instances of it, without "fully" declaring it, so that no Modula-3 can instantiate it? I have done this for sigset_t and sem_t, but they could erroneously be instantiated by Modula-3 and I'd like to remove that ability to mess up so easily. (* This type is not declared correctly. It is only instantiated in C code. *) sigset_t = RECORD END;(* This type is not declared correctly. It is only instantiated in C code. *) sem_t = RECORD END;In C I believe you can do this, like: typedef struct foo foo_t; extern foo_t foo; void UseFoo(foo_t*); foo_t* GetFoo(void); Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 08:31:40 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 18:31:40 +1100 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> Message-ID: <079DF9EE-C4DE-4563-B21E-53EA34F364AD@cs.purdue.edu> Don't mess with sysutils. I am about to check in my code. You could help by reverting from the current quake generated copies of waitpid to a single copy. On 12 Jan 2009, at 18:27, Jay wrote: > Huh..that's what I was saying about the way m3overrides work -- the > directory structure IS duplicated /everywhere/.. I don't know what > choice there is, if quake code is to be shared across packages. > > m3tests does the same sort of thing, also to me. > > Ok, hold, I'll slow sysutils back down. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 18:24:43 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > > Jay, > > What the hell is the ROOT variable supposed to do now. I can't > build m3core with a compiler that doesn't define ROOT. And why does > the m3makefile that includes Uwaitpid.quake expect a hardwired cm3 > directory hierarchy. Surely, I should be able to build m3core as a > separate package, regardless of the structure in which it appears. > You are doing damage to the package structures here too, by > hardwiring these paths into the m3makefile. > > -- Tony > > On 12 Jan 2009, at 17:58, Jay wrote: > > We have conflicting goals. > > Keeping things as fast as possible and with as little C as possible, > vs. keeping things more portable, more easily ported, more obviously > correct. > > I want to drastically reduce the header cloning, or, the work of > porting. > It is already reduced, but I want to keep going. > I think having to make any changes at all in m3-libs/m3core/src/ > unix can be removed, other than adding the platform to the list of > platforms that uses the "portable" stuff. > Porting would devolve to: > update the lists of platforms -- including some in m3makefiles > update Target.m3 > clone/edit Csetjmp.i3 > add the GNU platform to m3cc/src/makefile > > and maybe nothing else. > > It is likely even that the IR is now portable, for "Posix" systems. > Pick word size, pick endian, generate 4 versions of IR, pick the > right one for your platform. > Except for the OSConfigPosix that sometimes returns the platform > name and cm3's defining "HOST". > > A variable isn't great, but it is faster and more source compatible > than a function call, at least. > And the C variable really will generally be read only. Writes to it > should fault. > > > In this particular case, you are wanting to use a Modula-3 > parameter > > passing mechanism on something that is not declared in Modula-3. > > Isn't this just a variation on what is done all the time? -- having > Modula-3 call C and sometimes vice versa? > C code calls Modula-3 signal handlers, with data created in the C > code. The Modula-3 code can then pass them on. I don't see the line > really. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 12:32:15 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > > > Jay, I really think you are bending over backwards too far just to > be able to shoe-horn things into C. I *like* having the transpar of > C header files expressed in Modula-3, *particularly* for system > calls, where you might even be trying to build on a system that does > not have the C header files installed, even though the libraries > exist and can be linked to. Fundamentally, I think anytime the > Modula-3 code is made less transparent you should think hard about > what you are doing. The same with the change of constants to > variables. > > I am getting very nervous that the changes you are making are > destroying the clarity of the Modula-3 run-time code. > > In this particular case, you are wanting to use a Modula-3 parameter > passing mechanism on something that is not declared in Modula-3. > Seems kind of dubious to me. Also, I really don't like the idea of > accessing external variables in C. > > -- Tony > > On 12 Jan 2009, at 11:55, Jay wrote: > > I considered ADDRESS. > However I think it still doesn't satisfy. > > I want to be able to do this: > > TYPE Foo_t = something; > <* EXTERNAL *> VAR Foo1, Foo2:Foo_t; > <* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); > > (* Modula-3, not external *) > PROCEDURE x()= > BEGIN > UseFoo(Foo1); > UseFoo(Foo2); > END x; > > AND I want any use of: > VAR Foo3:Foo3_t; (* Modula-3, not external *) > > to error. This is sem_t and sigset_t in particular. > > Possibly renaming is the thing. > They used to be declared in Modula-3, system-dependently, but > I moved them to portable C. > > I could remove the types entirely and change UseFoo to take an > address, > and declare mask and ackSem to be integers or I guess. > <*EXTERNAL> VAR ackSem : RECORD END; > > That would satisfy but I thought it might be nicer to still provide > the named > types to refer to the external variables. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 11:13:00 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > > What's wrong with using ADDRESS for references to opaque values? If > sigset_t is never instantiated in Modula-3, then why do you need it > declared there? > > 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 01:44, Jay wrote: > > Is there a way in Modula-3 to declare that a type exists, and there > are <*external*> instances of it, without "fully" declaring it, so > that no Modula-3 can instantiate it? > > I have done this for sigset_t and sem_t, but they could erroneously > be instantiated by Modula-3 and I'd like to remove that ability to > mess up so easily. > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sigset_t = RECORD END; > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sem_t = RECORD END; > > In C I believe you can do this, like: > typedef struct foo foo_t; > extern foo_t foo; > > void UseFoo(foo_t*); > foo_t* GetFoo(void); > > Thanks, > - Jay > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 08:32:13 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 07:32:13 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> Message-ID: I didn't slow it back down yet, but I changed to a relative path instead of ROOT. All the scripts define ROOT and my config files ferry environment variable CM3_ROOT to ROOT. (ROOT is too generic for an environment variable.) oh -- m3core or sysytils? sysutils needed it. I don't see what m3core does. - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] declaring a type's existance but not enough to instantiate it?Date: Mon, 12 Jan 2009 07:27:09 +0000 Huh..that's what I was saying about the way m3overrides work -- the directory structure IS duplicated /everywhere/.. I don't know what choice there is, if quake code is to be shared across packages. m3tests does the same sort of thing, also to me. Ok, hold, I'll slow sysutils back down. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:24:43 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?Jay, What the hell is the ROOT variable supposed to do now. I can't build m3core with a compiler that doesn't define ROOT. And why does the m3makefile that includes Uwaitpid.quake expect a hardwired cm3 directory hierarchy. Surely, I should be able to build m3core as a separate package, regardless of the structure in which it appears. You are doing damage to the package structures here too, by hardwiring these paths into the m3makefile. -- Tony On 12 Jan 2009, at 17:58, Jay wrote: We have conflicting goals. Keeping things as fast as possible and with as little C as possible, vs. keeping things more portable, more easily ported, more obviously correct. I want to drastically reduce the header cloning, or, the work of porting. It is already reduced, but I want to keep going. I think having to make any changes at all in m3-libs/m3core/src/unix can be removed, other than adding the platform to the list of platforms that uses the "portable" stuff.Porting would devolve to: update the lists of platforms -- including some in m3makefiles update Target.m3 clone/edit Csetjmp.i3 add the GNU platform to m3cc/src/makefile and maybe nothing else. It is likely even that the IR is now portable, for "Posix" systems.Pick word size, pick endian, generate 4 versions of IR, pick the right one for your platform.Except for the OSConfigPosix that sometimes returns the platform name and cm3's defining "HOST". A variable isn't great, but it is faster and more source compatible than a function call, at least.And the C variable really will generally be read only. Writes to it should fault. > In this particular case, you are wanting to use a Modula-3 parameter > passing mechanism on something that is not declared in Modula-3. Isn't this just a variation on what is done all the time? -- having Modula-3 call C and sometimes vice versa?C code calls Modula-3 signal handlers, with data created in the C code. The Modula-3 code can then pass them on. I don't see the line really. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 12:32:15 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it? Jay, I really think you are bending over backwards too far just to be able to shoe-horn things into C. I *like* having the transpar of C header files expressed in Modula-3, *particularly* for system calls, where you might even be trying to build on a system that does not have the C header files installed, even though the libraries exist and can be linked to. Fundamentally, I think anytime the Modula-3 code is made less transparent you should think hard about what you are doing. The same with the change of constants to variables. I am getting very nervous that the changes you are making are destroying the clarity of the Modula-3 run-time code. In this particular case, you are wanting to use a Modula-3 parameter passing mechanism on something that is not declared in Modula-3. Seems kind of dubious to me. Also, I really don't like the idea of accessing external variables in C. -- Tony On 12 Jan 2009, at 11:55, Jay wrote: I considered ADDRESS.However I think it still doesn't satisfy. I want to be able to do this: TYPE Foo_t = something;<* EXTERNAL *> VAR Foo1, Foo2:Foo_t;<* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); (* Modula-3, not external *)PROCEDURE x()=BEGIN UseFoo(Foo1); UseFoo(Foo2);END x; AND I want any use of:VAR Foo3:Foo3_t; (* Modula-3, not external *)to error. This is sem_t and sigset_t in particular. Possibly renaming is the thing.They used to be declared in Modula-3, system-dependently, butI moved them to portable C. I could remove the types entirely and change UseFoo to take an address,and declare mask and ackSem to be integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END; That would satisfy but I thought it might be nicer to still provide the namedtypes to refer to the external variables. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?What's wrong with using ADDRESS for references to opaque values? If sigset_t is never instantiated in Modula-3, then why do you need it declared there? 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 01:44, Jay wrote: Is there a way in Modula-3 to declare that a type exists, and there are <*external*> instances of it, without "fully" declaring it, so that no Modula-3 can instantiate it? I have done this for sigset_t and sem_t, but they could erroneously be instantiated by Modula-3 and I'd like to remove that ability to mess up so easily. (* This type is not declared correctly. It is only instantiated in C code. *) sigset_t = RECORD END;(* This type is not declared correctly. It is only instantiated in C code. *) sem_t = RECORD END;In C I believe you can do this, like: typedef struct foo foo_t; extern foo_t foo; void UseFoo(foo_t*); foo_t* GetFoo(void); Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 08:38:59 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 07:38:59 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> Message-ID: > sysutils needed it. I don't see what m3core does. I see. "fixing". - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] declaring a type's existance but not enough to instantiate it?Date: Mon, 12 Jan 2009 07:32:13 +0000 I didn't slow it back down yet, but I changed to a relative path instead of ROOT.All the scripts define ROOT and my config files ferry environment variable CM3_ROOT to ROOT.(ROOT is too generic for an environment variable.)oh -- m3core or sysytils?sysutils needed it. I don't see what m3core does. - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] declaring a type's existance but not enough to instantiate it?Date: Mon, 12 Jan 2009 07:27:09 +0000 Huh..that's what I was saying about the way m3overrides work -- the directory structure IS duplicated /everywhere/.. I don't know what choice there is, if quake code is to be shared across packages. m3tests does the same sort of thing, also to me. Ok, hold, I'll slow sysutils back down. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:24:43 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?Jay, What the hell is the ROOT variable supposed to do now. I can't build m3core with a compiler that doesn't define ROOT. And why does the m3makefile that includes Uwaitpid.quake expect a hardwired cm3 directory hierarchy. Surely, I should be able to build m3core as a separate package, regardless of the structure in which it appears. You are doing damage to the package structures here too, by hardwiring these paths into the m3makefile. -- Tony On 12 Jan 2009, at 17:58, Jay wrote: We have conflicting goals. Keeping things as fast as possible and with as little C as possible, vs. keeping things more portable, more easily ported, more obviously correct. I want to drastically reduce the header cloning, or, the work of porting. It is already reduced, but I want to keep going. I think having to make any changes at all in m3-libs/m3core/src/unix can be removed, other than adding the platform to the list of platforms that uses the "portable" stuff.Porting would devolve to: update the lists of platforms -- including some in m3makefiles update Target.m3 clone/edit Csetjmp.i3 add the GNU platform to m3cc/src/makefile and maybe nothing else. It is likely even that the IR is now portable, for "Posix" systems.Pick word size, pick endian, generate 4 versions of IR, pick the right one for your platform.Except for the OSConfigPosix that sometimes returns the platform name and cm3's defining "HOST". A variable isn't great, but it is faster and more source compatible than a function call, at least.And the C variable really will generally be read only. Writes to it should fault. > In this particular case, you are wanting to use a Modula-3 parameter > passing mechanism on something that is not declared in Modula-3. Isn't this just a variation on what is done all the time? -- having Modula-3 call C and sometimes vice versa?C code calls Modula-3 signal handlers, with data created in the C code. The Modula-3 code can then pass them on. I don't see the line really. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 12:32:15 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it? Jay, I really think you are bending over backwards too far just to be able to shoe-horn things into C. I *like* having the transpar of C header files expressed in Modula-3, *particularly* for system calls, where you might even be trying to build on a system that does not have the C header files installed, even though the libraries exist and can be linked to. Fundamentally, I think anytime the Modula-3 code is made less transparent you should think hard about what you are doing. The same with the change of constants to variables. I am getting very nervous that the changes you are making are destroying the clarity of the Modula-3 run-time code. In this particular case, you are wanting to use a Modula-3 parameter passing mechanism on something that is not declared in Modula-3. Seems kind of dubious to me. Also, I really don't like the idea of accessing external variables in C. -- Tony On 12 Jan 2009, at 11:55, Jay wrote: I considered ADDRESS.However I think it still doesn't satisfy. I want to be able to do this: TYPE Foo_t = something;<* EXTERNAL *> VAR Foo1, Foo2:Foo_t;<* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); (* Modula-3, not external *)PROCEDURE x()=BEGIN UseFoo(Foo1); UseFoo(Foo2);END x; AND I want any use of:VAR Foo3:Foo3_t; (* Modula-3, not external *)to error. This is sem_t and sigset_t in particular. Possibly renaming is the thing.They used to be declared in Modula-3, system-dependently, butI moved them to portable C. I could remove the types entirely and change UseFoo to take an address,and declare mask and ackSem to be integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END; That would satisfy but I thought it might be nicer to still provide the namedtypes to refer to the external variables. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?What's wrong with using ADDRESS for references to opaque values? If sigset_t is never instantiated in Modula-3, then why do you need it declared there? 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 01:44, Jay wrote: Is there a way in Modula-3 to declare that a type exists, and there are <*external*> instances of it, without "fully" declaring it, so that no Modula-3 can instantiate it? I have done this for sigset_t and sem_t, but they could erroneously be instantiated by Modula-3 and I'd like to remove that ability to mess up so easily. (* This type is not declared correctly. It is only instantiated in C code. *) sigset_t = RECORD END;(* This type is not declared correctly. It is only instantiated in C code. *) sem_t = RECORD END;In C I believe you can do this, like: typedef struct foo foo_t; extern foo_t foo; void UseFoo(foo_t*); foo_t* GetFoo(void); Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 08:51:08 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 18:51:08 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: Why do you not build in the following order to get a new compiler? (You may need to downgrade Compiler.tmpl for use with an old compiler so that you don't get a mismatch between m3core and libm3, but otherwise the following sequence should work). m3core libm3 sysutils m3middle m3objfile m3linker m3back m3front m3quake cm3 On 12 Jan 2009, at 18:25, Jay wrote: > The compiler uses sysutils. The first pass builds against an old > package store, which might not have sysutils at all, if it is that > old. > > Again, once new m3core is around, no problem. > I could/should have put in the m3core change and just waited on the > sysutils change, rather than go ahead and do the quake stuff, and we > can do that now (or your change that moots it, which I haven't > looked into yet). > > I was browsing the docs and it appears there is an "import_pkg" > directive for like, copying in a package contents, instead of > linking. That might also solve this. I found that relatively late > and never looked into it. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 18:19:55 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Not true. sysutils should be built against the m3core with which it > will be linked. I don't think this is correct. > > On 12 Jan 2009, at 17:58, Jay wrote: > > To bootstrap I believe. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 17:53:02 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Why does sysutils need to be compatible with both old and new > versions of m3core? > > On 12 Jan 2009, at 17:39, Jay wrote: > > ThreadPosix is basically unaffected -- I never provided user threads > on Cygwin. > I guess it got a slight reduction regarding DoesWaitPidYield, but > its SchedulerPosix implementation was unchanged. > > The code in ThreadPosix is similar to but different than > ThreadPThread. > It is possible they could be merged but it wasn't trivial so I left > ThreadPosix alone. > > > You are smearing implementation details across multiple files and > directories > > You really think it is bad to have SchedulerPosix implemented in a > small separate file? > On top of what happens to be common implementation details of > ThreadPThread.m3 and ThreadWin32.m3? > > ThreadPScheduler.m3 is just basically three functions: IOWait, > IOAlertWait, XIOWait > Plus the little internal utility, UTimeFromTime, the one liner > DoesWaitPidYield, and non-trivial functions nested in XIOWait: > TestFDS, CallSelect. > > I mean, you know, an alternative is to copy out very large chunks of > ThreadWin32.m3 and ThreadPThread.m3 and merge them into > ThreadCygwin.m3. That would be worse imho. > > "Directories" hardly. > > Or I can try debugging cygwin pthreads again. > > - Jay > > > CC: jkrell at elego.de; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Mon, 12 Jan 2009 12:46:54 +1100 > > You are smearing implementation details across multiple files and > directories. Up until now, ThreadPThread has been nicely self- > contained, and captured all the basic pieces of the thread > implementation. Also, how does all of this fit with the ThreadPosix > implementation? > > On 12 Jan 2009, at 12:19, Jay wrote: > > btw, I don't think it's that hairy, I merely split it into two or > three files, and added interfaces so they can reuse code with each > other. Movement between files is hard to track though (depending on > version control, but with all I've used). > > The SchedulerPosix implementation moved to ThreadPScheduler.m3. > What is shared between it and ThreadPThread/Win32.m3 is > ThreadInternal.i3, which maybe should be in ThreadF.i3, though > that's exposed outside m3core, and ThreadInternal.i3 includes a > variable. > > I can try again to debug Cygwin pthreads though. > > - Jay > > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:03:33 +1100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay, > > > > Can you remind me again why Cygwin was unable to use pthreads? It > > seems you have introduced a bunch of hair into the PTHREADS > > implementation to deal with broken Cygwin pthreads. As many of us > > have already pointed out, Cygwin should be a port that tries as much > > as possible to be like a standard POSIX platform (pthread-based) as > > opposed to a weird Windows/POSIX hybrid. > > > > I have a bunch of code that will be going into the PTHREADS base > that > > I am now at a loss to integrate with the changes you have made. > > > > Help! > > > > -- Tony > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 08:52:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 18:52:34 +1100 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> Message-ID: <5406617A-EFAC-4506-B6F7-F1EFCE4A230E@cs.purdue.edu> There are some of us around who don't use your scripts and expect to be able to build any package using cm3 out of the box. I don't use scripts for my bootstrapping -- I just compile and ship the packages in the right order. On 12 Jan 2009, at 18:32, Jay wrote: > I didn't slow it back down yet, but I changed to a relative path > instead of ROOT. > All the scripts define ROOT and my config files ferry environment > variable CM3_ROOT to ROOT. > (ROOT is too generic for an environment variable.) > > oh -- m3core or sysytils? > sysutils needed it. I don't see what m3core does. > > - Jay > > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] declaring a type's existance but not enough > to instantiate it? > Date: Mon, 12 Jan 2009 07:27:09 +0000 > > Huh..that's what I was saying about the way m3overrides work -- the > directory structure IS duplicated /everywhere/.. I don't know what > choice there is, if quake code is to be shared across packages. > > m3tests does the same sort of thing, also to me. > > Ok, hold, I'll slow sysutils back down. > > - Jay > > > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 18:24:43 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > > Jay, > > > What the hell is the ROOT variable supposed to do now. I can't > build m3core with a compiler that doesn't define ROOT. And why does > the m3makefile that includes Uwaitpid.quake expect a hardwired cm3 > directory hierarchy. Surely, I should be able to build m3core as a > separate package, regardless of the structure in which it appears. > You are doing damage to the package structures here too, by > hardwiring these paths into the m3makefile. > > -- Tony > > On 12 Jan 2009, at 17:58, Jay wrote: > > We have conflicting goals. > > Keeping things as fast as possible and with as little C as possible, > vs. keeping things more portable, more easily ported, more obviously > correct. > > I want to drastically reduce the header cloning, or, the work of > porting. > It is already reduced, but I want to keep going. > I think having to make any changes at all in m3-libs/m3core/src/ > unix can be removed, other than adding the platform to the list of > platforms that uses the "portable" stuff. > Porting would devolve to: > update the lists of platforms -- including some in m3makefiles > update Target.m3 > clone/edit Csetjmp.i3 > add the GNU platform to m3cc/src/makefile > > and maybe nothing else. > > It is likely even that the IR is now portable, for "Posix" systems. > Pick word size, pick endian, generate 4 versions of IR, pick the > right one for your platform. > Except for the OSConfigPosix that sometimes returns the platform > name and cm3's defining "HOST". > > A variable isn't great, but it is faster and more source compatible > than a function call, at least. > And the C variable really will generally be read only. Writes to it > should fault. > > > In this particular case, you are wanting to use a Modula-3 > parameter > > passing mechanism on something that is not declared in Modula-3. > > Isn't this just a variation on what is done all the time? -- having > Modula-3 call C and sometimes vice versa? > C code calls Modula-3 signal handlers, with data created in the C > code. The Modula-3 code can then pass them on. I don't see the line > really. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 12:32:15 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > > > Jay, I really think you are bending over backwards too far just to > be able to shoe-horn things into C. I *like* having the transpar of > C header files expressed in Modula-3, *particularly* for system > calls, where you might even be trying to build on a system that does > not have the C header files installed, even though the libraries > exist and can be linked to. Fundamentally, I think anytime the > Modula-3 code is made less transparent you should think hard about > what you are doing. The same with the change of constants to > variables. > > I am getting very nervous that the changes you are making are > destroying the clarity of the Modula-3 run-time code. > > In this particular case, you are wanting to use a Modula-3 parameter > passing mechanism on something that is not declared in Modula-3. > Seems kind of dubious to me. Also, I really don't like the idea of > accessing external variables in C. > > -- Tony > > On 12 Jan 2009, at 11:55, Jay wrote: > > I considered ADDRESS. > However I think it still doesn't satisfy. > > I want to be able to do this: > > TYPE Foo_t = something; > <* EXTERNAL *> VAR Foo1, Foo2:Foo_t; > <* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); > > (* Modula-3, not external *) > PROCEDURE x()= > BEGIN > UseFoo(Foo1); > UseFoo(Foo2); > END x; > > AND I want any use of: > VAR Foo3:Foo3_t; (* Modula-3, not external *) > > to error. This is sem_t and sigset_t in particular. > > Possibly renaming is the thing. > They used to be declared in Modula-3, system-dependently, but > I moved them to portable C. > > I could remove the types entirely and change UseFoo to take an > address, > and declare mask and ackSem to be integers or I guess. > <*EXTERNAL> VAR ackSem : RECORD END; > > That would satisfy but I thought it might be nicer to still provide > the named > types to refer to the external variables. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 11:13:00 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > > What's wrong with using ADDRESS for references to opaque values? If > sigset_t is never instantiated in Modula-3, then why do you need it > declared there? > > 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 01:44, Jay wrote: > > Is there a way in Modula-3 to declare that a type exists, and there > are <*external*> instances of it, without "fully" declaring it, so > that no Modula-3 can instantiate it? > > I have done this for sigset_t and sem_t, but they could erroneously > be instantiated by Modula-3 and I'd like to remove that ability to > mess up so easily. > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sigset_t = RECORD END; > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sem_t = RECORD END; > > In C I believe you can do this, like: > typedef struct foo foo_t; > extern foo_t foo; > > void UseFoo(foo_t*); > foo_t* GetFoo(void); > > Thanks, > - Jay > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 08:59:09 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 07:59:09 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: <5406617A-EFAC-4506-B6F7-F1EFCE4A230E@cs.purdue.edu> References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> <5406617A-EFAC-4506-B6F7-F1EFCE4A230E@cs.purdue.edu> Message-ID: Understood. It should be ok now (well, "better" at least). > I just compile and ship the packages in the right order. Most folks claim an inability to do that actually. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:52:34 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it? There are some of us around who don't use your scripts and expect to be able to build any package using cm3 out of the box. I don't use scripts for my bootstrapping -- I just compile and ship the packages in the right order. On 12 Jan 2009, at 18:32, Jay wrote: I didn't slow it back down yet, but I changed to a relative path instead of ROOT.All the scripts define ROOT and my config files ferry environment variable CM3_ROOT to ROOT.(ROOT is too generic for an environment variable.)oh -- m3core or sysytils?sysutils needed it. I don't see what m3core does. - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] declaring a type's existance but not enough to instantiate it?Date: Mon, 12 Jan 2009 07:27:09 +0000Huh..that's what I was saying about the way m3overrides work -- the directory structure IS duplicated /everywhere/.. I don't know what choice there is, if quake code is to be shared across packages. m3tests does the same sort of thing, also to me. Ok, hold, I'll slow sysutils back down. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:24:43 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?Jay, What the hell is the ROOT variable supposed to do now. I can't build m3core with a compiler that doesn't define ROOT. And why does the m3makefile that includes Uwaitpid.quake expect a hardwired cm3 directory hierarchy. Surely, I should be able to build m3core as a separate package, regardless of the structure in which it appears. You are doing damage to the package structures here too, by hardwiring these paths into the m3makefile. -- Tony On 12 Jan 2009, at 17:58, Jay wrote: We have conflicting goals. Keeping things as fast as possible and with as little C as possible, vs. keeping things more portable, more easily ported, more obviously correct. I want to drastically reduce the header cloning, or, the work of porting. It is already reduced, but I want to keep going. I think having to make any changes at all in m3-libs/m3core/src/unix can be removed, other than adding the platform to the list of platforms that uses the "portable" stuff.Porting would devolve to: update the lists of platforms -- including some in m3makefiles update Target.m3 clone/edit Csetjmp.i3 add the GNU platform to m3cc/src/makefile and maybe nothing else. It is likely even that the IR is now portable, for "Posix" systems.Pick word size, pick endian, generate 4 versions of IR, pick the right one for your platform.Except for the OSConfigPosix that sometimes returns the platform name and cm3's defining "HOST". A variable isn't great, but it is faster and more source compatible than a function call, at least.And the C variable really will generally be read only. Writes to it should fault. > In this particular case, you are wanting to use a Modula-3 parameter > passing mechanism on something that is not declared in Modula-3. Isn't this just a variation on what is done all the time? -- having Modula-3 call C and sometimes vice versa?C code calls Modula-3 signal handlers, with data created in the C code. The Modula-3 code can then pass them on. I don't see the line really. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 12:32:15 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it? Jay, I really think you are bending over backwards too far just to be able to shoe-horn things into C. I *like* having the transpar of C header files expressed in Modula-3, *particularly* for system calls, where you might even be trying to build on a system that does not have the C header files installed, even though the libraries exist and can be linked to. Fundamentally, I think anytime the Modula-3 code is made less transparent you should think hard about what you are doing. The same with the change of constants to variables. I am getting very nervous that the changes you are making are destroying the clarity of the Modula-3 run-time code. In this particular case, you are wanting to use a Modula-3 parameter passing mechanism on something that is not declared in Modula-3. Seems kind of dubious to me. Also, I really don't like the idea of accessing external variables in C. -- Tony On 12 Jan 2009, at 11:55, Jay wrote: I considered ADDRESS.However I think it still doesn't satisfy. I want to be able to do this: TYPE Foo_t = something;<* EXTERNAL *> VAR Foo1, Foo2:Foo_t;<* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); (* Modula-3, not external *)PROCEDURE x()=BEGIN UseFoo(Foo1); UseFoo(Foo2);END x; AND I want any use of:VAR Foo3:Foo3_t; (* Modula-3, not external *)to error. This is sem_t and sigset_t in particular. Possibly renaming is the thing.They used to be declared in Modula-3, system-dependently, butI moved them to portable C. I could remove the types entirely and change UseFoo to take an address,and declare mask and ackSem to be integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END; That would satisfy but I thought it might be nicer to still provide the namedtypes to refer to the external variables. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?What's wrong with using ADDRESS for references to opaque values? If sigset_t is never instantiated in Modula-3, then why do you need it declared there? 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 01:44, Jay wrote: Is there a way in Modula-3 to declare that a type exists, and there are <*external*> instances of it, without "fully" declaring it, so that no Modula-3 can instantiate it? I have done this for sigset_t and sem_t, but they could erroneously be instantiated by Modula-3 and I'd like to remove that ability to mess up so easily. (* This type is not declared correctly. It is only instantiated in C code. *) sigset_t = RECORD END;(* This type is not declared correctly. It is only instantiated in C code. *) sem_t = RECORD END;In C I believe you can do this, like: typedef struct foo foo_t; extern foo_t foo; void UseFoo(foo_t*); foo_t* GetFoo(void); Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 09:02:37 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 08:02:37 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: If old compiler can't build m3core, such as if old compiler predates LONGINT. You already know this. Are we "past" such compilers? - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:51:08 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3 Why do you not build in the following order to get a new compiler? (You may need to downgrade Compiler.tmpl for use with an old compiler so that you don't get a mismatch between m3core and libm3, but otherwise the following sequence should work). m3core libm3 sysutils m3middle m3objfile m3linker m3back m3front m3quake cm3 On 12 Jan 2009, at 18:25, Jay wrote: The compiler uses sysutils. The first pass builds against an old package store, which might not have sysutils at all, if it is that old. Again, once new m3core is around, no problem.I could/should have put in the m3core change and just waited on the sysutils change, rather than go ahead and do the quake stuff, and we can do that now (or your change that moots it, which I haven't looked into yet). I was browsing the docs and it appears there is an "import_pkg" directive for like, copying in a package contents, instead of linking. That might also solve this. I found that relatively late and never looked into it. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:19:55 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3Not true. sysutils should be built against the m3core with which it will be linked. I don't think this is correct. On 12 Jan 2009, at 17:58, Jay wrote: To bootstrap I believe. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 17:53:02 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3Why does sysutils need to be compatible with both old and new versions of m3core? On 12 Jan 2009, at 17:39, Jay wrote: ThreadPosix is basically unaffected -- I never provided user threads on Cygwin. I guess it got a slight reduction regarding DoesWaitPidYield, but its SchedulerPosix implementation was unchanged. The code in ThreadPosix is similar to but different than ThreadPThread.It is possible they could be merged but it wasn't trivial so I left ThreadPosix alone. > You are smearing implementation details across multiple files and directories You really think it is bad to have SchedulerPosix implemented in a small separate file?On top of what happens to be common implementation details of ThreadPThread.m3 and ThreadWin32.m3? ThreadPScheduler.m3 is just basically three functions: IOWait, IOAlertWait, XIOWaitPlus the little internal utility, UTimeFromTime, the one liner DoesWaitPidYield, and non-trivial functions nested in XIOWait: TestFDS, CallSelect. I mean, you know, an alternative is to copy out very large chunks of ThreadWin32.m3 and ThreadPThread.m3 and merge them into ThreadCygwin.m3. That would be worse imho. "Directories" hardly. Or I can try debugging cygwin pthreads again. - Jay CC: jkrell at elego.de; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 12:46:54 +1100You are smearing implementation details across multiple files and directories. Up until now, ThreadPThread has been nicely self-contained, and captured all the basic pieces of the thread implementation. Also, how does all of this fit with the ThreadPosix implementation? On 12 Jan 2009, at 12:19, Jay wrote: btw, I don't think it's that hairy, I merely split it into two or three files, and added interfaces so they can reuse code with each other. Movement between files is hard to track though (depending on version control, but with all I've used). The SchedulerPosix implementation moved to ThreadPScheduler.m3.What is shared between it and ThreadPThread/Win32.m3 is ThreadInternal.i3, which maybe should be in ThreadF.i3, though that's exposed outside m3core, and ThreadInternal.i3 includes a variable. I can try again to debug Cygwin pthreads though. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:03:33 +1100> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Jay,> > Can you remind me again why Cygwin was unable to use pthreads? It > seems you have introduced a bunch of hair into the PTHREADS > implementation to deal with broken Cygwin pthreads. As many of us > have already pointed out, Cygwin should be a port that tries as much > as possible to be like a standard POSIX platform (pthread-based) as > opposed to a weird Windows/POSIX hybrid.> > I have a bunch of code that will be going into the PTHREADS base that > I am now at a loss to integrate with the changes you have made.> > Help!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: [M3devel] [M3commit] 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:18:29 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 08:18:29 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> Message-ID: I don't think a development system without C headers is interesting.. Is it really? The transform I apply at times is wherever there is interaction with C code that is described by system-dependent headers, or perhaps even fairly system-independent headers outside the Modula-3 tree, either write wrapper functions for the functionality in the headers (e.g. stat, waitpid), which can be done in a system-independent way, or move the Modula-3<->C transition higher, which is also usually system-independent, e.g. ThreadPThreadC_SetupHandlers. It is either that or clone the headers, which seems like the worse evil. There is always going to be a Modula-3<->C transition, it is just a matter of where it occurs. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?Date: Mon, 12 Jan 2009 12:32:15 +1100 Jay, I really think you are bending over backwards too far just to be able to shoe-horn things into C. I *like* having the transpar of C header files expressed in Modula-3, *particularly* for system calls, where you might even be trying to build on a system that does not have the C header files installed, even though the libraries exist and can be linked to. Fundamentally, I think anytime the Modula-3 code is made less transparent you should think hard about what you are doing. The same with the change of constants to variables. I am getting very nervous that the changes you are making are destroying the clarity of the Modula-3 run-time code. In this particular case, you are wanting to use a Modula-3 parameter passing mechanism on something that is not declared in Modula-3. Seems kind of dubious to me. Also, I really don't like the idea of accessing external variables in C. -- Tony On 12 Jan 2009, at 11:55, Jay wrote: I considered ADDRESS.However I think it still doesn't satisfy. I want to be able to do this: TYPE Foo_t = something;<* EXTERNAL *> VAR Foo1, Foo2:Foo_t;<* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); (* Modula-3, not external *)PROCEDURE x()=BEGIN UseFoo(Foo1); UseFoo(Foo2);END x; AND I want any use of:VAR Foo3:Foo3_t; (* Modula-3, not external *)to error. This is sem_t and sigset_t in particular. Possibly renaming is the thing.They used to be declared in Modula-3, system-dependently, butI moved them to portable C. I could remove the types entirely and change UseFoo to take an address,and declare mask and ackSem to be integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END; That would satisfy but I thought it might be nicer to still provide the namedtypes to refer to the external variables. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?What's wrong with using ADDRESS for references to opaque values? If sigset_t is never instantiated in Modula-3, then why do you need it declared there? 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 01:44, Jay wrote: Is there a way in Modula-3 to declare that a type exists, and there are <*external*> instances of it, without "fully" declaring it, so that no Modula-3 can instantiate it? I have done this for sigset_t and sem_t, but they could erroneously be instantiated by Modula-3 and I'd like to remove that ability to mess up so easily. (* This type is not declared correctly. It is only instantiated in C code. *) sigset_t = RECORD END;(* This type is not declared correctly. It is only instantiated in C code. *) sem_t = RECORD END;In C I believe you can do this, like: typedef struct foo foo_t; extern foo_t foo; void UseFoo(foo_t*); foo_t* GetFoo(void); Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 09:22:13 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 19:22:13 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: I think there is a straightforward fix for old compilers that can't compile LONGINT: define LongRep.T = INTEGER. Most everything should compile from there. That's what I recall doing to upgrade my compiler to handle LONGINT. LONGINT is not used anywhere else in m3core, so nothing depends on it working. On 12 Jan 2009, at 19:02, Jay wrote: > If old compiler can't build m3core, such as if old compiler predates > LONGINT. > You already know this. > Are we "past" such compilers? > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 18:51:08 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > Why do you not build in the following order to get a new compiler? > (You may need to downgrade Compiler.tmpl for use with an old > compiler so that you don't get a mismatch between m3core and libm3, > but otherwise the following sequence should work). > > m3core > libm3 > sysutils > m3middle > m3objfile > m3linker > m3back > m3front > m3quake > cm3 > > On 12 Jan 2009, at 18:25, Jay wrote: > > The compiler uses sysutils. The first pass builds against an old > package store, which might not have sysutils at all, if it is that > old. > > Again, once new m3core is around, no problem. > I could/should have put in the m3core change and just waited on the > sysutils change, rather than go ahead and do the quake stuff, and we > can do that now (or your change that moots it, which I haven't > looked into yet). > > I was browsing the docs and it appears there is an "import_pkg" > directive for like, copying in a package contents, instead of > linking. That might also solve this. I found that relatively late > and never looked into it. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 18:19:55 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Not true. sysutils should be built against the m3core with which it > will be linked. I don't think this is correct. > > On 12 Jan 2009, at 17:58, Jay wrote: > > To bootstrap I believe. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 17:53:02 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Why does sysutils need to be compatible with both old and new > versions of m3core? > > On 12 Jan 2009, at 17:39, Jay wrote: > > ThreadPosix is basically unaffected -- I never provided user threads > on Cygwin. > I guess it got a slight reduction regarding DoesWaitPidYield, but > its SchedulerPosix implementation was unchanged. > > The code in ThreadPosix is similar to but different than > ThreadPThread. > It is possible they could be merged but it wasn't trivial so I left > ThreadPosix alone. > > > You are smearing implementation details across multiple files and > directories > > You really think it is bad to have SchedulerPosix implemented in a > small separate file? > On top of what happens to be common implementation details of > ThreadPThread.m3 and ThreadWin32.m3? > > ThreadPScheduler.m3 is just basically three functions: IOWait, > IOAlertWait, XIOWait > Plus the little internal utility, UTimeFromTime, the one liner > DoesWaitPidYield, and non-trivial functions nested in XIOWait: > TestFDS, CallSelect. > > I mean, you know, an alternative is to copy out very large chunks of > ThreadWin32.m3 and ThreadPThread.m3 and merge them into > ThreadCygwin.m3. That would be worse imho. > > "Directories" hardly. > > Or I can try debugging cygwin pthreads again. > > - Jay > > > CC: jkrell at elego.de; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Mon, 12 Jan 2009 12:46:54 +1100 > > You are smearing implementation details across multiple files and > directories. Up until now, ThreadPThread has been nicely self- > contained, and captured all the basic pieces of the thread > implementation. Also, how does all of this fit with the ThreadPosix > implementation? > > On 12 Jan 2009, at 12:19, Jay wrote: > > btw, I don't think it's that hairy, I merely split it into two or > three files, and added interfaces so they can reuse code with each > other. Movement between files is hard to track though (depending on > version control, but with all I've used). > > The SchedulerPosix implementation moved to ThreadPScheduler.m3. > What is shared between it and ThreadPThread/Win32.m3 is > ThreadInternal.i3, which maybe should be in ThreadF.i3, though > that's exposed outside m3core, and ThreadInternal.i3 includes a > variable. > > I can try again to debug Cygwin pthreads though. > > - Jay > > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:03:33 +1100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay, > > > > Can you remind me again why Cygwin was unable to use pthreads? It > > seems you have introduced a bunch of hair into the PTHREADS > > implementation to deal with broken Cygwin pthreads. As many of us > > have already pointed out, Cygwin should be a port that tries as much > > as possible to be like a standard POSIX platform (pthread-based) as > > opposed to a weird Windows/POSIX hybrid. > > > > I have a bunch of code that will be going into the PTHREADS base > that > > I am now at a loss to integrate with the changes you have made. > > > > Help! > > > > -- Tony > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 09:24:50 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 19:24:50 +1100 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> Message-ID: <54BC9DFC-09FC-4082-9E10-694EAAF6E5EC@cs.purdue.edu> Point taken. We live in a C universe and so need to interact. I do think your work with the headers is useful, and I want it to continue. Especially in simplifying ports. On 12 Jan 2009, at 19:18, Jay wrote: > I don't think a development system without C headers is > interesting.. Is it really? > > The transform I apply at times is wherever there is interaction with > C code that is described by system-dependent headers, or perhaps > even fairly system-independent headers outside the Modula-3 tree, > either write wrapper functions for the functionality in the headers > (e.g. stat, waitpid), which can be done in a system-independent way, > or move the Modula-3<->C transition higher, which is also usually > system-independent, e.g. ThreadPThreadC_SetupHandlers. > > It is either that or clone the headers, which seems like the worse > evil. > > There is always going to be a Modula-3<->C transition, it is just a > matter of where it occurs. > > - Jay > > > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > Date: Mon, 12 Jan 2009 12:32:15 +1100 > > > Jay, I really think you are bending over backwards too far just to > be able to shoe-horn things into C. I *like* having the transpar of > C header files expressed in Modula-3, *particularly* for system > calls, where you might even be trying to build on a system that does > not have the C header files installed, even though the libraries > exist and can be linked to. Fundamentally, I think anytime the > Modula-3 code is made less transparent you should think hard about > what you are doing. The same with the change of constants to > variables. > > I am getting very nervous that the changes you are making are > destroying the clarity of the Modula-3 run-time code. > > In this particular case, you are wanting to use a Modula-3 parameter > passing mechanism on something that is not declared in Modula-3. > Seems kind of dubious to me. Also, I really don't like the idea of > accessing external variables in C. > > -- Tony > > On 12 Jan 2009, at 11:55, Jay wrote: > > I considered ADDRESS. > However I think it still doesn't satisfy. > > I want to be able to do this: > > TYPE Foo_t = something; > <* EXTERNAL *> VAR Foo1, Foo2:Foo_t; > <* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); > > (* Modula-3, not external *) > PROCEDURE x()= > BEGIN > UseFoo(Foo1); > UseFoo(Foo2); > END x; > > AND I want any use of: > VAR Foo3:Foo3_t; (* Modula-3, not external *) > > to error. This is sem_t and sigset_t in particular. > > Possibly renaming is the thing. > They used to be declared in Modula-3, system-dependently, but > I moved them to portable C. > > I could remove the types entirely and change UseFoo to take an > address, > and declare mask and ackSem to be integers or I guess. > <*EXTERNAL> VAR ackSem : RECORD END; > > That would satisfy but I thought it might be nicer to still provide > the named > types to refer to the external variables. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 11:13:00 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > > What's wrong with using ADDRESS for references to opaque values? If > sigset_t is never instantiated in Modula-3, then why do you need it > declared there? > > 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 01:44, Jay wrote: > > Is there a way in Modula-3 to declare that a type exists, and there > are <*external*> instances of it, without "fully" declaring it, so > that no Modula-3 can instantiate it? > > I have done this for sigset_t and sem_t, but they could erroneously > be instantiated by Modula-3 and I'd like to remove that ability to > mess up so easily. > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sigset_t = RECORD END; > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sem_t = RECORD END; > > In C I believe you can do this, like: > typedef struct foo foo_t; > extern foo_t foo; > > void UseFoo(foo_t*); > foo_t* GetFoo(void); > > Thanks, > - Jay > > > > > > > -------------- 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: [M3devel] [M3commit] 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 jay.krell at cornell.edu Mon Jan 12 09:47:17 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 08:47:17 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: <54BC9DFC-09FC-4082-9E10-694EAAF6E5EC@cs.purdue.edu> References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> <54BC9DFC-09FC-4082-9E10-694EAAF6E5EC@cs.purdue.edu> Message-ID: This is what you "have to" chose between. Header cloning or C code (and C headers). CONST or VAR (or functions?) I'm going to likely make the Uerror change tonight. You can still veto it (er, vote against it :) ) Possibly some convuluted C (enum/#undef), or splitting the Modula-3 at boundaries that weren't previously believed "natural". (See how SetupHandlers is ~two lines in Modula-3 and the rest in C; this is partly out of ignorance. I don't know how to write those two lines in C; and laziness, I didn't look into how). Remember I'm still staying away from mainstream platforms, so the value isn't what it might appear to be, but it is "stage setting", and the show might go on. :) Also, the dilemna does get more difficult now, with the little C header cloning that remains. For example, look at Upthreads.i3. Mainly, look at function prototypes. Constants and types are "known problems". Prototypes are gray. They actually tend to be portable. For example: TYPE pid_t = INTEGER; <*EXTERNAL "m3_getpid*> PROCEDURE getpid():pid_t; or leave it alone? getpid is probably the worst example. It is so very portable declared in Modula-3. But still, imagine pid_t might be 16bits or 32 or 64. Writing a wrapper is more portable -- as long as the pid isn't stuff into some record that the system defines. Again, Upthreads.i3. Would you like to see it reduced, or left alone? Only deal with the types and initializers, or also the prototypes? You know, I could write a little portable layer, where all the types are pointers, always null initialized. It would buy /some/ portability, and cost some. Do you like the sem_t change? Partly? Not at all? There is one sem_t in the system. So I moved it to be in C code. Or, as I had it before, declared as the max size/align of all the platforms -- getting that right is the same work as getting it right "the old way", except if you make a mistake, odds are still good of it being ok. Should the line be drawn at generating the remaining headers, rather than eliminating them? Uerror.i3 is easily generated. Good enough? Upthread.i3's types can be generated generally as records with opaque arrays with the right size and alignment. Other stuff can be generated or at least checked. e.g. to check that getpid is declared correctly, you can assign it to a function pointer and see if that compiles. Perf on Uerror arguably doesn't matter. Is it only error handling code?Or do sockets often go down "error" paths, because they are slow and you are waiting for more data? Anyway, point is, I agree for sure this is valuable, but I might be hitting the "tail" of the approach and should switch, I'm not sure. I keep saying that though, and then press further. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 19:24:50 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it? Point taken. We live in a C universe and so need to interact. I do think your work with the headers is useful, and I want it to continue. Especially in simplifying ports. On 12 Jan 2009, at 19:18, Jay wrote: I don't think a development system without C headers is interesting.. Is it really? The transform I apply at times is wherever there is interaction with C code that is described by system-dependent headers, or perhaps even fairly system-independent headers outside the Modula-3 tree, either write wrapper functions for the functionality in the headers (e.g. stat, waitpid), which can be done in a system-independent way, or move the Modula-3<->C transition higher, which is also usually system-independent, e.g. ThreadPThreadC_SetupHandlers. It is either that or clone the headers, which seems like the worse evil. There is always going to be a Modula-3<->C transition, it is just a matter of where it occurs. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?Date: Mon, 12 Jan 2009 12:32:15 +1100 Jay, I really think you are bending over backwards too far just to be able to shoe-horn things into C. I *like* having the transpar of C header files expressed in Modula-3, *particularly* for system calls, where you might even be trying to build on a system that does not have the C header files installed, even though the libraries exist and can be linked to. Fundamentally, I think anytime the Modula-3 code is made less transparent you should think hard about what you are doing. The same with the change of constants to variables. I am getting very nervous that the changes you are making are destroying the clarity of the Modula-3 run-time code. In this particular case, you are wanting to use a Modula-3 parameter passing mechanism on something that is not declared in Modula-3. Seems kind of dubious to me. Also, I really don't like the idea of accessing external variables in C. -- Tony On 12 Jan 2009, at 11:55, Jay wrote: I considered ADDRESS.However I think it still doesn't satisfy. I want to be able to do this: TYPE Foo_t = something;<* EXTERNAL *> VAR Foo1, Foo2:Foo_t;<* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); (* Modula-3, not external *)PROCEDURE x()=BEGIN UseFoo(Foo1); UseFoo(Foo2);END x; AND I want any use of:VAR Foo3:Foo3_t; (* Modula-3, not external *)to error. This is sem_t and sigset_t in particular. Possibly renaming is the thing.They used to be declared in Modula-3, system-dependently, butI moved them to portable C. I could remove the types entirely and change UseFoo to take an address,and declare mask and ackSem to be integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END; That would satisfy but I thought it might be nicer to still provide the namedtypes to refer to the external variables. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?What's wrong with using ADDRESS for references to opaque values? If sigset_t is never instantiated in Modula-3, then why do you need it declared there? 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 01:44, Jay wrote: Is there a way in Modula-3 to declare that a type exists, and there are <*external*> instances of it, without "fully" declaring it, so that no Modula-3 can instantiate it? I have done this for sigset_t and sem_t, but they could erroneously be instantiated by Modula-3 and I'd like to remove that ability to mess up so easily. (* This type is not declared correctly. It is only instantiated in C code. *) sigset_t = RECORD END;(* This type is not declared correctly. It is only instantiated in C code. *) sem_t = RECORD END;In C I believe you can do this, like: typedef struct foo foo_t; extern foo_t foo; void UseFoo(foo_t*); foo_t* GetFoo(void); Thanks, - Jay -------------- 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: [M3devel] [M3commit] 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: [M3devel] [M3commit] 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 mika at async.caltech.edu Mon Jan 12 10:06:30 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 12 Jan 2009 01:06:30 -0800 Subject: [M3devel] Juno (X) networking problem on AMD64_FREEBSD In-Reply-To: Your message of "Sun, 11 Jan 2009 22:02:18 GMT." Message-ID: <200901120906.n0C96Uwn074046@camembert.async.caltech.edu> Jay, I think the problem here is actually in the caller. Why does a caller need "GetHostAddr()"? It is probably doing this for the purpose of calling listen() or some such thing. What the caller probably *really* wants is INADDR_ANY, and not the IP address of some arbitrarily chosen interface on the host. I'm guessing it works on the Mac because the Mac libraries do something complicated when you ask for the host's name (i.e., they somehow generate a hostname that always maps to the IP address of an interface on the computer). Mika Jay writes: >--_b00371fe-730b-4981-9051-a874361296d7_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Do you know the right way? >=20 >PPC_LINUX "just worked"=2C and I can check Solaris and Darwin. >=20 >I don't want to edit /etc/hosts -- I use DHCP. >Though DHCP has been bothering me -- only for some of my machines do names = >resolve=2C so I end using IP addresses=2C which change sometimes=2C and I l= >oop over them running ssh to all of them and "see what I get"=2C not ideal. >=20 > - Jay> To: jay.krell at cornell.edu> Date: Sun=2C 11 Jan 2009 08:02:18 -0800>= > From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3d= >evel] Juno (X) networking problem on AMD64_FREEBSD> > This is a screwy thin= >g in Modula-3. A bug I would call it.> > I've noticed a lot of networking M= >3 programs don't work right unless> the return value of Unix's "hostname" m= >aps to a real IP address via> gethostbyname. I accomplish it in practice by= > adding my hostname> to /etc/hosts.> > This is obviously not the right way = >to fix it... > > Mika> > Jay writes:> >--_9e67232c-a064-417d-879e-227a77e31= >0f9_> >Content-Type: text/plain=3B charset=3D"iso-8859-1"> >Content-Transfe= >r-Encoding: quoted-printable> >> >> >Hi. Unix network programming question.= >.> >AMD64_FREEBSD:> >$DISPLAY is set to point back to Cygwin host.It works = >for PPC_LINUX.> >[jay at fbsdamd64a /cm3/bin]$ ./Juno> >****** runtime error:*= >** Exception "IPError.FatalError" not in RAISES li=3D> >st*** file "../src/= >common/IPError.m3"=3D2C line 27***> >Abort trap: 6 (core dumped)[jay at fbsdam= >d64a /cm3/bin]$> >IP.m3:> >=3D20> >PROCEDURE GetHostAddr(): Address =3D3D V= >AR hname: ARRAY [0..255] OF CHAR=3D3B =3D> > BEGIN LOCK mu DO IF Unix.getho= >stname(ADR(hname[0])=3D2C BYTESIZE(hna=3D> >me)) # 0 THEN IPError.Die ()=3D= >3B END=3D3B VAR h :=3D3D Unetdb.g=3D> >ethostbyname(ADR(hname[0]))=3D3B BEG= >IN IF h =3D3D NIL THEN IPError.Die()=3D> >=3D3B END=3D3B RETURN GetAddress(= >h)=3D3B END=3D3B END=3D3B END GetHos=3D> >tAddr=3D3B> >PROCEDURE GetAddress= > (ent: Unetdb.struct_hostent_star): Address =3D3D VAR ua=3D> >: Uin.struct_= >in_addr=3D3B BEGIN <* ASSERT ent.h_length <=3D3D BYTESIZE(Addr=3D> >ess) *>= > ua :=3D3D LOOPHOLE(ent.h_addr_list=3D2C UNTRACED =3D> >REF UNTRACED REF Ui= >n.struct_in_addr)^^=3D3B RETURN LOOPHOLE(ua.s_addr=3D2C A=3D> >ddress)=3D3B= > END GetAddress=3D3B> >=3D20> >gethostbyname is failing.> >=3D20> >Analogou= >s C code also fails:> >=3D20> >[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c#include= > #include #i=3D> >nclude #include type= >def struct hostent hostent_t=3D3B> >=3D20> >int main(){ char hostname[200]= >=3D3B hostent_t* h=3D3B int i=3D3B> > i =3D3D gethostname(hostname=3D2C 200= >)=3D3B assert(i =3D3D=3D3D 0)=3D3B printf("hostna=3D> >me: %s\n"=3D2C hostn= >ame)=3D3B h =3D3D gethostbyname(hostname)=3D3B herror("foo")=3D3B=3D> > pri= >ntf("%p %d %d\n"=3D2C h=3D2C errno=3D2C h_errno)=3D3B assert(h)=3D3B return= > 0=3D3B}> >=3D20> >herror says "unknown host".> >Stack is:> > at ../src/run= >time/ex_frame/RTExFrame.m3:58#13 0x0000000801a7f2b3 in RTH=3D> >ooks__Raise= > (M3_AJWxb1_ex=3D3DError accessing memory address 0x8000ffffd278: =3D> >Bad= > address.) at ../src/runtime/common/RTHooks.m3:79#14 0x000000080169c8=3D> >= >d3 in IPError__Die () at ../src/common/IPError.m3:27#15 0x0000000801698a3e = >=3D> >in IP__GetHostAddr (M3_BCxjPn__result=3D3DError accessing memory addr= >ess 0x80=3D> >00ffffd338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x00000= >008012133d0=3D> > in XSharedMem__SameHost (M3_AQuuui_trsl=3D3DError accessi= >ng memory address 0=3D> >x8000ffffd4d8: Bad address.) at ../src/xvbt/XShare= >dMem.m3:96#17 0x000000=3D> >0801212ab7 in XSharedMem__InitXClient (M3_AQuuu= >i_v=3D3DError accessing memory=3D> > address 0x8000ffffd648: Bad address.) = >at ../src/xvbt/XSharedMem.m3:29#1=3D> >8 0x0000000801211819 in XExtensions_= >_InitXClient (M3_AQuuui_xclient=3D3DError=3D> > accessing memory address 0x= >8000ffffd7f8: Bad address.) at ../src/xvbt/X=3D> >Extensions.m3:14#19 0x000= >00008012467a4 in XClientF__Connect (M3_Bd56fi_inst=3D> >=3D3D0x1879b=3D2C M= >3_AQuuui_trsl=3D3D0x6) at ../src/xvbt/XClientF.m3:583---Typ=3D> >e = > to continue=3D2C or q to quit---(More stack frames follow=3D> >..= >.)(gdb)> >(* return TRUE if server and client are on same host *)PROCEDURE = >SameHost (=3D> >trsl: XClient.T): BOOLEAN =3D3D VAR display :=3D3D DisplayH= >=3D> >ost(trsl)=3D3B displayAddr: IP.Address=3D3B BEGIN IF display =3D3D NI= >L THE=3D> >N RETURN TRUE=3D3B END=3D3B> > TRY IF NOT IP.GetHostByName(displ= >ay=3D2C displayAddr) THEN RETURN FA=3D> >LSE=3D3B END=3D3B RETURN displayAd= >dr =3D3D IP.GetHostAddr()=3D3B EXCEPT =3D> >| IP.Error =3D3D> RETURN FALSE= >=3D3B END=3D3B END SameHost=3D3B> >=3D20> >Thoughts?> >=3D20> >Perhaps my n= >etwork isn't setup well=3D2C like I should add the local machine =3D> >to /= >etc/hosts.I think this can be made to fail gracefully though.It seems l=3D>= > >ike it has nothing to do with AMD64_FREEBSD=3D2C but could have to do wit= >h Fr=3D> >eeBSD.> >=3D20> >Seems like SocketPosix has nearly the exact same= > code but appearsmore forgi=3D> >ving.. IOError instead of Fatal?> >=3D20> = >>SocketPosix.m3:> >=3D20> >PROCEDURE GetHostAddr (): Address RAISES {OSErro= >r.E} =3D3D VAR host : AR=3D> >RAY [0..255] OF CHAR=3D3B info : Unetdb.struc= >t_hostent_star=3D3B ua : U=3D> >in.struct_in_addr=3D3B BEGIN IF Unix.gethos= >tname (ADR (host[0])=3D2C BYTESI=3D> >ZE (host)) # 0 THEN IOError (Unexpect= >ed)=3D3B END=3D3B> > info :=3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3B = >IF info =3D3D NIL TH=3D> >EN IOError (Unexpected)=3D3B END=3D3B <* ASSERT i= >nfo.h_length <=3D3D BYTESIZE =3D> >(Address) *>> > ua :=3D3D LOOPHOLE(info.= >h_addr_list=3D2C UNTRACED REF UNT=3D> >RACED REF Uin.struct_in_addr)^^=3D3B= > RETURN LOOPHOLE (ua.s_addr=3D2C Address=3D> >)=3D3B END GetHostAddr=3D3B> = >>=3D20> >=3D20> >It is again disappointing to see such code duplication.> >= >=3D20> >=3D20> >I guess SameHost can duplicate the logic to predict the err= >or state and ret=3D> >urn false upon error?> >Duplicating the logic for a t= >hird time. :(> >=3D20> > - Jay=3D> >> >--_9e67232c-a064-417d-879e-227a77e31= >0f9_> >Content-Type: text/html=3B charset=3D"iso-8859-1"> >Content-Transfer= >-Encoding: quoted-printable> >> >> >> >> >> >mmessage'>> >Hi. Unix network programming question..
> >
AMD64_FREEBS= >D:
> >
$DISPLAY is set to point back to Cygwin host.
It works for = >PPC_LINUX=3D> >.
> >
[jay at fbsdamd64a /cm3/bin]$ ./Juno
> >
***<= >BR>*** runtime error:
*** =3D3B =3D3B =3D3B Exception "IPE= >=3D> >rror.FatalError" not in RAISES list
*** =3D3B =3D3B = >=3D3B file "..=3D> >/src/common/IPError.m3"=3D2C line 27
***
> >
A= >bort trap: 6 (core dumped)
[jay at fbsdamd64a /cm3/bin]$
> >
IP.m3:R>> > =3D3B
> >PROCEDURE GetHostAddr(): Address =3D3D
 =3D3B = >VAR hname: ARRAY [0..255] =3D> OF CHAR=3D3B
 =3D3B BEGIN
 =3D= >3B =3D3B =3D3B LOCK mu DO
&nbs=3D> >p=3D3B =3D3B =3D3B&n= >bsp=3D3B =3D3B IF Unix.gethostname(ADR(hname[0])=3D2C B=3D> >YTESIZE(hn= >ame)) # 0 THEN
 =3D3B =3D3B =3D3B =3D3B =3D3B = >=3D> >=3D3B =3D3B IPError.Die ()=3D3B
 =3D3B =3D3B =3D3B= > =3D3B =3D3B E=3D> >ND=3D3B
 =3D3B =3D3B =3D3B = >=3D3B =3D3B VAR h :=3D3D Unetdb.gethost=3D> >byname(ADR(hname[0]))=3D3B= > BEGIN
 =3D3B =3D3B =3D3B =3D3B =3D3B&=3D> >nbsp=3D3= >B =3D3B IF h =3D3D NIL THEN IPError.Die()=3D3B END=3D3B
 =3D3B&n= >bsp=3D> >=3D3B =3D3B =3D3B =3D3B =3D3B =3D3B RETURN Get= >Address(h)=3D3B
&nbs=3D> >p=3D3B =3D3B =3D3B =3D3B =3D3B= > END=3D3B
 =3D3B =3D3B =3D3B END=3D> >=3D3B
 =3D3B EN= >D GetHostAddr=3D3B
> >
PROCEDURE GetAddress (ent: Unetdb.struct_hoste= >nt_star): Address =3D3D
=3D> > =3D3B VAR ua: Uin.struct_in_addr=3D3B= >
 =3D3B BEGIN
 =3D3B =3D> >=3D3B =3D3B <=3D3B* ASSE= >RT ent.h_length <=3D3B=3D3D BYTESIZE(Address) *>=3D3B=3D> >
 =3D= >3B =3D3B =3D3B ua :=3D3D LOOPHOLE(ent.h_addr_list=3D2C
 =3D>= > >=3D3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D= >3B =3D3B =3D3B=3D> > =3D3B =3D3B =3D3B =3D3B = >=3D3B =3D3B =3D3B =3D3B =3D3B UN=3D> >TRACED REF UNTRACED R= >EF Uin.struct_in_addr)^^=3D3B
 =3D3B =3D3B =3D> >=3D3B RETUR= >N LOOPHOLE(ua.s_addr=3D2C Address)=3D3B
 =3D3B END GetAddress=3D3B<= >=3D> >BR>> > =3D3B
> >gethostbyname is failing.
> >
 =3D3B= >
> >Analogous C code also fails:
> > =3D3B
> >
[jay at fbsdamd= >64a /cm3/bin]$ cat ~/5.c
#include <=3D3Bassert.h>=3D3B >R>#inc= >lude <=3D3Bnetdb.h>=3D3B
#include <=3D3Bstdio.h>=3D3B
#includ= >e =3D> ><=3D3Berrno.h>=3D3B
typedef struct hostent hostent_t=3D3B>> > =3D3B
> >int main()
{
 =3D3Bchar hostname[200]=3D3BR> =3D3Bhostent_t* h=3D3B=3D> >
 =3D3Bint i=3D3B
> > =3D3= >Bi =3D3D gethostname(hostname=3D2C 200)=3D3B
 =3D3Bassert(i =3D3D=3D= >3D 0)=3D> >=3D3B
 =3D3Bprintf("hostname: %s\n"=3D2C hostname)=3D3BR> =3D3Bh =3D3D get=3D> >hostbyname(hostname)=3D3B
 =3D3Bherror(= >"foo")=3D3B
 =3D3Bprintf("%p %=3D> >d %d\n"=3D2C h=3D2C errno=3D2C h= >_errno)=3D3B
 =3D3Bassert(h)=3D3B
 =3D3Bret=3D> >urn 0=3D3BR>}
> > =3D3B
> >herror says "unknown host".
> >
Stack is:<= >BR>> > =3D3B =3D3B =3D3B at ../src/runtime/ex_frame/RTExFrame.m= >3:58
#13 =3D> >0x0000000801a7f2b3 in RTHooks__Raise (M3_AJWxb1_ex=3D3DEr= >ror accessing memory=3D> > ad
dress 0x8000ffffd278: Bad address.
)> =3D3B =3D3B =3D3B =3D> >at ../src/runtime/common/RTHooks.m3:7= >9
#14 0x000000080169c8d3 in IPError=3D> >__Die () at ../src/common/IPErr= >or.m3:27
#15 0x0000000801698a3e in IP__Ge=3D> >tHostAddr (M3_BCxjPn__res= ult=3D3DError accessing mem
ory address 0x8000fff=3D> >fd338: Bad addres= >s.
)
 =3D3B =3D3B =3D3B at ../src/POSIX/IP.m3:=3D> >82>#16 0x00000008012133d0 in XSharedMem__SameHost (M3_AQuuui_trsl=3D3DErro=3D= >> >r accessing m
emory address 0x8000ffffd4d8: Bad address.
)
&nbs= >p=3D> >=3D3B =3D3B =3D3B at ../src/xvbt/XSharedMem.m3:96
#17 0x0= >000000801212a=3D> >b7 in XSharedMem__InitXClient (M3_AQuuui_v=3D3DError acc= >essing m
emory add=3D> >ress 0x8000ffffd648: Bad address.
)
 = >=3D3B =3D3B =3D3B at ../sr=3D> >c/xvbt/XSharedMem.m3:29
#18 0x00= >00000801211819 in XExtensions__InitXClie=3D> >nt (M3_AQuuui_xclient=3D3DErr= >or acce
ssing memory address 0x8000ffffd7f8: =3D> >Bad address.
)
= > =3D3B =3D3B =3D3B at ../src/xvbt/XExtensions.m3=3D> >:14
#1= >9 0x00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst=3D3D0x1879=3D> >b= >=3D2C
 =3D3B =3D3B =3D3B M3_AQuuui_trsl=3D3D0x6) at ../src/x= >vbt/XClie=3D> >ntF.m3:583
---Type <=3D3Breturn>=3D3B to continue=3D2= >C or q <=3D3Breturn&g=3D> >t=3D3B to quit---
(More stack frames follow= >...)
(gdb)
> >
(* return TRUE if server and client are on same hos= >t *)
PROCEDURE Sa=3D> >meHost (trsl: XClient.T): BOOLEAN =3D3D
 = >=3D3B VAR
 =3D3B =3D3B&n=3D> >bsp=3D3B display =3D3B =3D= >3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D> >=3D3B = >=3D3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D3B= :=3D3D Di=3D> >splayHost(trsl)=3D3B
 =3D3B =3D3B =3D3B disp= >layAddr: IP.Address=3D3B >R> =3D3B BEGIN
 =3D3B =3D3B&= >nbsp=3D3B IF display =3D3D NIL THEN RETURN=3D> > TRUE=3D3B END=3D3B
> >&= >nbsp=3D3B =3D3B =3D3B TRY
 =3D3B =3D3B =3D3B =3D= >3B =3D3B IF=3D> > NOT IP.GetHostByName(display=3D2C displayAddr) THEN R= >ETURN FALSE=3D3B END=3D3B >R> =3D3B =3D3B =3D3B =3D3B= > =3D3B RETURN displayAddr =3D3D IP.GetHos=3D> >tAddr()=3D3B
 =3D= >3B =3D3B =3D3B EXCEPT
 =3D3B =3D3B =3D3B |=3D> > IP.= >Error =3D3D>=3D3B RETURN FALSE=3D3B
 =3D3B =3D3B =3D3B END= >=3D3B
&=3D> >nbsp=3D3B END SameHost=3D3B
> > =3D3B
> >Thoughts= >?
> > =3D3B
> >
Perhaps my network isn't setup well=3D2C like = >I should add the local mach=3D> >ine to /etc/hosts.
I think this can be = >made to fail gracefully though. >R>It seems like it has nothing to do= > with AMD64_FREEBSD=3D2C but could have t=3D> >o do with FreeBSD.
> >> =3D3B
> >Seems like SocketPosix has nearly the exact same code but= > appears
more f=3D> >orgiving.. IOError instead of Fatal?
> > =3D= >3B
> >
SocketPosix.m3:
> > =3D3B
> >
PROCEDURE GetHostAd= >dr (): Address
 =3D3B RAISES {OSError.E} =3D3D >> =3D3B V= >AR
 =3D3B =3D3B =3D3B host : ARRAY [0..255] OF CHAR=3D3B<=3D= >> >BR> =3D3B =3D3B =3D3B info : Unetdb.struct_hostent_star=3D3B= >
 =3D> >=3D3B =3D3B =3D3B ua =3D3B =3D3B : Uin.struc= >t_in_addr=3D3B
 =3D3B =3D> >BEGIN
 =3D3B =3D3B =3D3B = >IF Unix.gethostname (ADR (host[0])=3D2C BYT=3D> >ESIZE (host)) # 0 THEN
= > =3D3B =3D3B =3D3B =3D3B =3D3B IOError =3D> >(Unexpecte= >d)=3D3B
 =3D3B =3D3B =3D3B END=3D3B
> > =3D3B =3D= >3B =3D3B info :=3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3B<=3D> >BR= >> =3D3B =3D3B =3D3B IF info =3D3D NIL THEN IOError (Unexpected)= >=3D3B EN=3D> >D=3D3B
 =3D3B =3D3B =3D3B <=3D3B* ASSERT inf= >o.h_length <=3D3B=3D3D BYT=3D> >ESIZE (Address) *>=3D3B
> > =3D3= >B =3D3B =3D3B ua :=3D3D LOOPHOLE(info.h_addr_list=3D2C
 =3D3= >B&n=3D> >bsp=3D3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D= >3B =3D3B =3D3B =3D> >=3D3B =3D3B =3D3B =3D3B = >=3D3B =3D3B =3D3B =3D3B UNTRACED REF UN=3D> >TRACED REF Uin.str= >uct_in_addr)^^=3D3B
 =3D3B =3D3B =3D3B RETURN LOOP=3D> >HOLE= > (ua.s_addr=3D2C Address)=3D3B
 =3D3B END GetHostAddr=3D3B
> >&nb= >sp=3D3B
> > =3D3B
> >It is again disappointing to see such code d= >uplication.
> > =3D3B
> > =3D3B
> >I guess =3D3BSameHo= >st can duplicate the logic to predict the error state =3D> >and return fals= >e =3D3Bupon error?
> >Duplicating the logic for a third time. :(
= >> > =3D3B
> >
 =3D3B- Jay

> >=3D> >> >--= >_9e67232c-a064-417d-879e-227a77e310f9_--= > >--_b00371fe-730b-4981-9051-a874361296d7_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Do you know the right way?
> =3B
>PPC_LINUX "just worked"=2C and I can check Solaris and Darwin.
> =3B
>I don't want to edit /etc/hosts -- I use DHCP.
>Though DHCP has been bothering me -- only for some of my machines do names = >resolve=2C so I end using IP addresses=2C which change sometimes=2C and I l= >oop over them running ssh to all of them and "see what I get"=2C not ideal.= >
> =3B
> =3B- Jay


>=3B To: jay.krell at cornell.edu
>=3B Date: S= >un=2C 11 Jan 2009 08:02:18 -0800
>=3B From: mika at async.caltech.edu
= >>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] Juno (X) = >networking problem on AMD64_FREEBSD
>=3B
>=3B This is a screwy t= >hing in Modula-3. A bug I would call it.
>=3B
>=3B I've noticed = >a lot of networking M3 programs don't work right unless
>=3B the retur= >n value of Unix's "hostname" maps to a real IP address via
>=3B gethos= >tbyname. I accomplish it in practice by adding my hostname
>=3B to /et= >c/hosts.
>=3B
>=3B This is obviously not the right way to fix it= >...
>=3B
>=3B Mika
>=3B
>=3B Jay writes:
>=3B &= >gt=3B--_9e67232c-a064-417d-879e-227a77e310f9_
>=3B >=3BContent-Type:= > text/plain=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Enco= >ding: quoted-printable
>=3B >=3B
>=3B >=3B
>=3B >=3BHi= >. Unix network programming question..
>=3B >=3BAMD64_FREEBSD:
>= >=3B >=3B$DISPLAY is set to point back to Cygwin host.It works for PPC_LIN= >UX.
>=3B >=3B[jay at fbsdamd64a /cm3/bin]$ ./Juno
>=3B >=3B*****= >* runtime error:*** Exception "IPError.FatalError" not in RAISES li=3D
&= >gt=3B >=3Bst*** file "../src/common/IPError.m3"=3D2C line 27***
>=3B= > >=3BAbort trap: 6 (core dumped)[jay at fbsdamd64a /cm3/bin]$
>=3B >= >=3BIP.m3:
>=3B >=3B=3D20
>=3B >=3BPROCEDURE GetHostAddr(): Ad= >dress =3D3D VAR hname: ARRAY [0..255] OF CHAR=3D3B =3D
>=3B >=3B BEG= >IN LOCK mu DO IF Unix.gethostname(ADR(hname[0])=3D2C BYTESIZE(hna=3D
>= >=3B >=3Bme)) # 0 THEN IPError.Die ()=3D3B END=3D3B VAR h :=3D3D Unetdb.g= >=3D
>=3B >=3Bethostbyname(ADR(hname[0]))=3D3B BEGIN IF h =3D3D NIL T= >HEN IPError.Die()=3D
>=3B >=3B=3D3B END=3D3B RETURN GetAddress(h)=3D= >3B END=3D3B END=3D3B END GetHos=3D
>=3B >=3BtAddr=3D3B
>=3B >= >=3BPROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Address =3D3D VA= >R ua=3D
>=3B >=3B: Uin.struct_in_addr=3D3B BEGIN <=3B* ASSERT ent.= >h_length <=3B=3D3D BYTESIZE(Addr=3D
>=3B >=3Bess) *>=3B ua :=3D3= >D LOOPHOLE(ent.h_addr_list=3D2C UNTRACED =3D
>=3B >=3BREF UNTRACED R= >EF Uin.struct_in_addr)^^=3D3B RETURN LOOPHOLE(ua.s_addr=3D2C A=3D
>=3B= > >=3Bddress)=3D3B END GetAddress=3D3B
>=3B >=3B=3D20
>=3B >= >=3Bgethostbyname is failing.
>=3B >=3B=3D20
>=3B >=3BAnalogou= >s C code also fails:
>=3B >=3B=3D20
>=3B >=3B[jay at fbsdamd64a = >/cm3/bin]$ cat ~/5.c#include <=3Bassert.h>=3B#include <=3Bnetdb.h>= >=3B#i=3D
>=3B >=3Bnclude <=3Bstdio.h>=3B#include <=3Berrno.h&g= >t=3Btypedef struct hostent hostent_t=3D3B
>=3B >=3B=3D20
>=3B &= >gt=3Bint main(){ char hostname[200]=3D3B hostent_t* h=3D3B int i=3D3B
&g= >t=3B >=3B i =3D3D gethostname(hostname=3D2C 200)=3D3B assert(i =3D3D=3D3D= > 0)=3D3B printf("hostna=3D
>=3B >=3Bme: %s\n"=3D2C hostname)=3D3B h = >=3D3D gethostbyname(hostname)=3D3B herror("foo")=3D3B=3D
>=3B >=3B p= >rintf("%p %d %d\n"=3D2C h=3D2C errno=3D2C h_errno)=3D3B assert(h)=3D3B retu= >rn 0=3D3B}
>=3B >=3B=3D20
>=3B >=3Bherror says "unknown host"= >.
>=3B >=3BStack is:
>=3B >=3B at ../src/runtime/ex_frame/RTE= >xFrame.m3:58#13 0x0000000801a7f2b3 in RTH=3D
>=3B >=3Books__Raise (M= >3_AJWxb1_ex=3D3DError accessing memory address 0x8000ffffd278: =3D
>= >=3B >=3BBad address.) at ../src/runtime/common/RTHooks.m3:79#14 0x0000000= >80169c8=3D
>=3B >=3Bd3 in IPError__Die () at ../src/common/IPError.m= >3:27#15 0x0000000801698a3e =3D
>=3B >=3Bin IP__GetHostAddr (M3_BCxjP= >n__result=3D3DError accessing memory address 0x80=3D
>=3B >=3B00ffff= >d338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x00000008012133d0=3D
&g= >t=3B >=3B in XSharedMem__SameHost (M3_AQuuui_trsl=3D3DError accessing mem= >ory address 0=3D
>=3B >=3Bx8000ffffd4d8: Bad address.) at ../src/xvb= >t/XSharedMem.m3:96#17 0x000000=3D
>=3B >=3B0801212ab7 in XSharedMem_= >_InitXClient (M3_AQuuui_v=3D3DError accessing memory=3D
>=3B >=3B ad= >dress 0x8000ffffd648: Bad address.) at ../src/xvbt/XSharedMem.m3:29#1=3D>>=3B >=3B8 0x0000000801211819 in XExtensions__InitXClient (M3_AQuuui_x= >client=3D3DError=3D
>=3B >=3B accessing memory address 0x8000ffffd7f= >8: Bad address.) at ../src/xvbt/X=3D
>=3B >=3BExtensions.m3:14#19 0x= >00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst=3D
>=3B >=3B= >=3D3D0x1879b=3D2C M3_AQuuui_trsl=3D3D0x6) at ../src/xvbt/XClientF.m3:583---= >Typ=3D
>=3B >=3Be <=3Breturn>=3B to continue=3D2C or q <=3Bret= >urn>=3B to quit---(More stack frames follow=3D
>=3B >=3B...)(gdb)<= >BR>>=3B >=3B(* return TRUE if server and client are on same host *)PROC= >EDURE SameHost (=3D
>=3B >=3Btrsl: XClient.T): BOOLEAN =3D3D VAR dis= >play :=3D3D DisplayH=3D
>=3B >=3Bost(trsl)=3D3B displayAddr: IP.Addr= >ess=3D3B BEGIN IF display =3D3D NIL THE=3D
>=3B >=3BN RETURN TRUE=3D= >3B END=3D3B
>=3B >=3B TRY IF NOT IP.GetHostByName(display=3D2C displ= >ayAddr) THEN RETURN FA=3D
>=3B >=3BLSE=3D3B END=3D3B RETURN displayA= >ddr =3D3D IP.GetHostAddr()=3D3B EXCEPT =3D
>=3B >=3B| IP.Error =3D3D= >>=3B RETURN FALSE=3D3B END=3D3B END SameHost=3D3B
>=3B >=3B=3D20R>>=3B >=3BThoughts?
>=3B >=3B=3D20
>=3B >=3BPerhaps my n= >etwork isn't setup well=3D2C like I should add the local machine =3D
>= >=3B >=3Bto /etc/hosts.I think this can be made to fail gracefully though.= >It seems l=3D
>=3B >=3Bike it has nothing to do with AMD64_FREEBSD= >=3D2C but could have to do with Fr=3D
>=3B >=3BeeBSD.
>=3B >= >=3B=3D20
>=3B >=3BSeems like SocketPosix has nearly the exact same c= >ode but appearsmore forgi=3D
>=3B >=3Bving.. IOError instead of Fata= >l?
>=3B >=3B=3D20
>=3B >=3BSocketPosix.m3:
>=3B >=3B= >=3D20
>=3B >=3BPROCEDURE GetHostAddr (): Address RAISES {OSError.E} = >=3D3D VAR host : AR=3D
>=3B >=3BRAY [0..255] OF CHAR=3D3B info : Une= >tdb.struct_hostent_star=3D3B ua : U=3D
>=3B >=3Bin.struct_in_addr=3D= >3B BEGIN IF Unix.gethostname (ADR (host[0])=3D2C BYTESI=3D
>=3B >=3B= >ZE (host)) # 0 THEN IOError (Unexpected)=3D3B END=3D3B
>=3B >=3B inf= >o :=3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3B IF info =3D3D NIL TH=3D<= >BR>>=3B >=3BEN IOError (Unexpected)=3D3B END=3D3B <=3B* ASSERT info.h= >_length <=3B=3D3D BYTESIZE =3D
>=3B >=3B(Address) *>=3B
>= >=3B >=3B ua :=3D3D LOOPHOLE(info.h_addr_list=3D2C UNTRACED REF UNT=3D
= >>=3B >=3BRACED REF Uin.struct_in_addr)^^=3D3B RETURN LOOPHOLE (ua.s_add= >r=3D2C Address=3D
>=3B >=3B)=3D3B END GetHostAddr=3D3B
>=3B >= >=3B=3D20
>=3B >=3B=3D20
>=3B >=3BIt is again disappointing to= > see such code duplication.
>=3B >=3B=3D20
>=3B >=3B=3D20
= >>=3B >=3BI guess SameHost can duplicate the logic to predict the error = >state and ret=3D
>=3B >=3Burn false upon error?
>=3B >=3BDupl= >icating the logic for a third time. :(
>=3B >=3B=3D20
>=3B >= >=3B - Jay=3D
>=3B >=3B
>=3B >=3B--_9e67232c-a064-417d-879e-22= >7a77e310f9_
>=3B >=3BContent-Type: text/html=3B charset=3D"iso-8859-= >1"
>=3B >=3BContent-Transfer-Encoding: quoted-printable
>=3B &g= >t=3B
>=3B >=3B<=3Bhtml>=3B
>=3B >=3B<=3Bhead>=3B
&= >gt=3B >=3B<=3Bstyle>=3B
>=3B >=3B.hmmessage P
>=3B >=3B= >{
>=3B >=3Bmargin:0px=3D3B
>=3B >=3Bpadding:0px
>=3B >= >=3B}
>=3B >=3Bbody.hmmessage
>=3B >=3B{
>=3B >=3Bfont-= >size: 10pt=3D3B
>=3B >=3Bfont-family:Verdana
>=3B >=3B}
&g= >t=3B >=3B<=3B/style>=3B
>=3B >=3B<=3B/head>=3B
>=3B &= >gt=3B<=3Bbody class=3D3D'hmmessage'>=3B
>=3B >=3BHi. Unix networ= >k programming question..<=3BBR>=3B
>=3B >=3B<=3BBR>=3BAMD64_= >FREEBSD:<=3BBR>=3B
>=3B >=3B<=3BBR>=3B$DISPLAY is set to poi= >nt back to Cygwin host.<=3BBR>=3BIt works for PPC_LINUX=3D
>=3B &g= >t=3B.<=3BBR>=3B
>=3B >=3B<=3BBR>=3B[jay at fbsdamd64a /cm3/bin]= >$ ./Juno<=3BBR>=3B
>=3B >=3B<=3BBR>=3B***<=3BBR>=3B*** r= >untime error:<=3BBR>=3B***&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp= >=3D3B Exception "IPE=3D
>=3B >=3Brror.FatalError" not in RAISES list= ><=3BBR>=3B***&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B file "..= >=3D
>=3B >=3B/src/common/IPError.m3"=3D2C line 27<=3BBR>=3B***&l= >t=3BBR>=3B
>=3B >=3B<=3BBR>=3BAbort trap: 6 (core dumped)<= >=3BBR>=3B[jay at fbsdamd64a /cm3/bin]$<=3BBR>=3B
>=3B >=3B<=3BB= >R>=3BIP.m3:<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B<= >BR>>=3B >=3BPROCEDURE GetHostAddr(): Address =3D3D<=3BBR>=3B&=3B= >nbsp=3D3B VAR hname: ARRAY [0..255] =3D
>=3B OF CHAR=3D3B<=3BBR>= >=3B&=3Bnbsp=3D3B BEGIN<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&= >=3Bnbsp=3D3B LOCK mu DO<=3BBR>=3B&=3Bnbs=3D
>=3B >=3Bp=3D3B&a= >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B IF Unix.geth= >ostname(ADR(hname[0])=3D2C B=3D
>=3B >=3BYTESIZE(hname)) # 0 THEN<= >=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B= >&=3Bnbsp=3D3B&=3Bnbsp=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B IPErro= >r.Die ()=3D3B<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B= >&=3Bnbsp=3D3B&=3Bnbsp=3D3B E=3D
>=3B >=3BND=3D3B<=3BBR>=3B= >&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp= >=3D3B VAR h :=3D3D Unetdb.gethost=3D
>=3B >=3Bbyname(ADR(hname[0]))= >=3D3B BEGIN<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&a= >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3B=3D
>=3B >=3Bnbsp=3D3B&=3Bnb= >sp=3D3B IF h =3D3D NIL THEN IPError.Die()=3D3B END=3D3B<=3BBR>=3B&= >=3Bnbsp=3D3B&=3Bnbsp=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B&=3Bnbsp= >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B RETURN GetAddress(h)= >=3D3B<=3BBR>=3B&=3Bnbs=3D
>=3B >=3Bp=3D3B&=3Bnbsp=3D3B&= >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B END=3D3B<=3BBR>=3B&=3Bn= >bsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B END=3D
>=3B >=3B=3D3B<=3B= >BR>=3B&=3Bnbsp=3D3B END GetHostAddr=3D3B<=3BBR>=3B
>=3B >= >=3B<=3BBR>=3BPROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Ad= >dress =3D3D<=3BBR>=3B=3D
>=3B >=3B&=3Bnbsp=3D3B VAR ua: Uin.s= >truct_in_addr=3D3B<=3BBR>=3B&=3Bnbsp=3D3B BEGIN<=3BBR>=3B&=3B= >nbsp=3D3B&=3Bnbsp=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B &=3Blt=3D3= >B* ASSERT ent.h_length &=3Blt=3D3B=3D3D BYTESIZE(Address) *&=3Bgt=3D3= >B=3D
>=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bn= >bsp=3D3B ua :=3D3D LOOPHOLE(ent.h_addr_list=3D2C<=3BBR>=3B&=3Bnbsp= >=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&a= >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp= >=3D3B&=3Bnbsp=3D3B=3D
>=3B >=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&a= >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp= >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B UN=3D
>=3B >=3BTRACED REF UNTR= ACED REF Uin.struct_in_addr)^^=3D3B<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbs= >p=3D3B&=3Bnbsp=3D
>=3B >=3B=3D3B RETURN LOOPHOLE(ua.s_addr=3D2C A= >ddress)=3D3B<=3BBR>=3B&=3Bnbsp=3D3B END GetAddress=3D3B<=3B=3D
= >>=3B >=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>= >=3B >=3Bgethostbyname is failing.<=3BBR>=3B
>=3B >=3B<=3BBR&= >gt=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BAnalogous C code also f= >ails:<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>= >=3B >=3B<=3BBR>=3B[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c<=3BBR>=3B#= >include &=3Blt=3D3Bassert.h&=3Bgt=3D3B<=3BB=3D
>=3B >=3BR>= >=3B#include &=3Blt=3D3Bnetdb.h&=3Bgt=3D3B<=3BBR>=3B#include &= >=3Blt=3D3Bstdio.h&=3Bgt=3D3B<=3BBR>=3B#include =3D
>=3B >=3B&= >amp=3Blt=3D3Berrno.h&=3Bgt=3D3B<=3BBR>=3Btypedef struct hostent host= >ent_t=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
= >>=3B >=3Bint main()<=3BBR>=3B{<=3BBR>=3B&=3Bnbsp=3D3Bchar ho= >stname[200]=3D3B<=3BBR>=3B&=3Bnbsp=3D3Bhostent_t* h=3D3B=3D
>= >=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3Bint i=3D3B<=3BBR>=3B
>=3B = >>=3B&=3Bnbsp=3D3Bi =3D3D gethostname(hostname=3D2C 200)=3D3B<=3BBR&g= >t=3B&=3Bnbsp=3D3Bassert(i =3D3D=3D3D 0)=3D
>=3B >=3B=3D3B<=3BBR= >>=3B&=3Bnbsp=3D3Bprintf("hostname: %s\n"=3D2C hostname)=3D3B<=3BBR&g= >t=3B&=3Bnbsp=3D3Bh =3D3D get=3D
>=3B >=3Bhostbyname(hostname)=3D3= >B<=3BBR>=3B&=3Bnbsp=3D3Bherror("foo")=3D3B<=3BBR>=3B&=3Bnbsp= >=3D3Bprintf("%p %=3D
>=3B >=3Bd %d\n"=3D2C h=3D2C errno=3D2C h_errno= >)=3D3B<=3BBR>=3B&=3Bnbsp=3D3Bassert(h)=3D3B<=3BBR>=3B&=3Bnbsp= >=3D3Bret=3D
>=3B >=3Burn 0=3D3B<=3BBR>=3B}<=3BBR>=3B
>= >=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3Bherror says "unkno= >wn host".<=3BBR>=3B
>=3B >=3B<=3BBR>=3BStack is:<=3BBR>= >=3B
>=3B >=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B at ../= >src/runtime/ex_frame/RTExFrame.m3:58<=3BBR>=3B#13 =3D
>=3B >=3B0= >x0000000801a7f2b3 in RTHooks__Raise (M3_AJWxb1_ex=3D3DError accessing memor= >y=3D
>=3B >=3B ad<=3BBR>=3Bdress 0x8000ffffd278: Bad address.<= >=3BBR>=3B)<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B = >=3D
>=3B >=3Bat ../src/runtime/common/RTHooks.m3:79<=3BBR>=3B#14= > 0x000000080169c8d3 in IPError=3D
>=3B >=3B__Die () at ../src/common= >/IPError.m3:27<=3BBR>=3B#15 0x0000000801698a3e in IP__Ge=3D
>=3B &= >gt=3BtHostAddr (M3_BCxjPn__result=3D3DError accessing mem<=3BBR>=3Bory = >address 0x8000fff=3D
>=3B >=3Bfd338: Bad address.<=3BBR>=3B)<= >=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B at ../src/POSIX= >/IP.m3:=3D
>=3B >=3B82<=3BBR>=3B#16 0x00000008012133d0 in XShare= >dMem__SameHost (M3_AQuuui_trsl=3D3DErro=3D
>=3B >=3Br accessing m<= >=3BBR>=3Bemory address 0x8000ffffd4d8: Bad address.<=3BBR>=3B)<=3BB= >R>=3B&=3Bnbsp=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B= > at ../src/xvbt/XSharedMem.m3:96<=3BBR>=3B#17 0x0000000801212a=3D
&g= >t=3B >=3Bb7 in XSharedMem__InitXClient (M3_AQuuui_v=3D3DError accessing m= ><=3BBR>=3Bemory add=3D
>=3B >=3Bress 0x8000ffffd648: Bad address= >.<=3BBR>=3B)<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp= >=3D3B at ../sr=3D
>=3B >=3Bc/xvbt/XSharedMem.m3:29<=3BBR>=3B#18 = >0x0000000801211819 in XExtensions__InitXClie=3D
>=3B >=3Bnt (M3_AQuu= >ui_xclient=3D3DError acce<=3BBR>=3Bssing memory address 0x8000ffffd7f8:= > =3D
>=3B >=3BBad address.<=3BBR>=3B)<=3BBR>=3B&=3Bnbsp= >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B at ../src/xvbt/XExtensions.m3=3D
&= >gt=3B >=3B:14<=3BBR>=3B#19 0x00000008012467a4 in XClientF__Connect (M= >3_Bd56fi_inst=3D3D0x1879=3D
>=3B >=3Bb=3D2C<=3BBR>=3B&=3Bnbsp= >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B M3_AQuuui_trsl=3D3D0x6) at ../src/xvb= >t/XClie=3D
>=3B >=3BntF.m3:583<=3BBR>=3B---Type &=3Blt=3D3Bre= >turn&=3Bgt=3D3B to continue=3D2C or q &=3Blt=3D3Breturn&=3Bg=3D>>=3B >=3Bt=3D3B to quit---<=3BBR>=3B(More stack frames follow...)&= >lt=3BBR>=3B(gdb)<=3BBR>=3B
>=3B >=3B<=3BBR>=3B(* return TR= >UE if server and client are on same host *)<=3BBR>=3BPROCEDURE Sa=3D>>=3B >=3BmeHost (trsl: XClient.T): BOOLEAN =3D3D<=3BBR>=3B&=3Bn= >bsp=3D3B VAR<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bn=3D
&g= >t=3B >=3Bbsp=3D3B display&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B= >&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp= >=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&a= >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp= >=3D3B :=3D3D Di=3D
>=3B >=3BsplayHost(trsl)=3D3B<=3BBR>=3B&= >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B displayAddr: IP.Address=3D3B&l= >t=3BB=3D
>=3B >=3BR>=3B&=3Bnbsp=3D3B BEGIN<=3BBR>=3B&=3B= >nbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B IF display =3D3D NIL THEN RETURN= >=3D
>=3B >=3B TRUE=3D3B END=3D3B<=3BBR>=3B
>=3B >=3B&= >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B TRY<=3BBR>=3B&=3Bnbsp= >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B IF=3D= >
>=3B >=3B NOT IP.GetHostByName(display=3D2C displayAddr) THEN RETUR= >N FALSE=3D3B END=3D3B<=3BB=3D
>=3B >=3BR>=3B&=3Bnbsp=3D3B&= >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B RETURN display= >Addr =3D3D IP.GetHos=3D
>=3B >=3BtAddr()=3D3B<=3BBR>=3B&=3Bnb= >sp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B EXCEPT<=3BBR>=3B&=3Bnbsp=3D3= >B&=3Bnbsp=3D3B&=3Bnbsp=3D3B |=3D
>=3B >=3B IP.Error =3D3D&= >=3Bgt=3D3B RETURN FALSE=3D3B<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&= >amp=3Bnbsp=3D3B END=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bnbsp=3D3B = >END SameHost=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>= >=3B
>=3B >=3BThoughts?<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3= >B<=3BBR>=3B
>=3B >=3B<=3BBR>=3BPerhaps my network isn't setu= >p well=3D2C like I should add the local mach=3D
>=3B >=3Bine to /etc= >/hosts.<=3BBR>=3BI think this can be made to fail gracefully though.<= >=3BB=3D
>=3B >=3BR>=3BIt seems like it has nothing to do with AMD6= >4_FREEBSD=3D2C but could have t=3D
>=3B >=3Bo do with FreeBSD.<=3B= >BR>=3B
>=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B
&g= >t=3B >=3BSeems like SocketPosix has nearly the exact same code but appear= >s<=3BBR>=3Bmore f=3D
>=3B >=3Borgiving.. IOError instead of Fata= >l?<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B &= >gt=3B<=3BBR>=3BSocketPosix.m3:<=3BBR>=3B
>=3B >=3B&=3Bnbs= >p=3D3B<=3BBR>=3B
>=3B >=3B<=3BBR>=3BPROCEDURE GetHostAddr ()= >: Address<=3BBR>=3B&=3Bnbsp=3D3B RAISES {OSError.E} =3D3D<=3BBR=3D= >
>=3B >=3B>=3B&=3Bnbsp=3D3B VAR<=3BBR>=3B&=3Bnbsp=3D3B&a= >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B host : ARRAY [0..255] OF CHAR=3D3B<=3B=3D<= >BR>>=3B >=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B in= >fo : Unetdb.struct_hostent_star=3D3B<=3BBR>=3B&=3Bnbsp=3D
>=3B = >>=3B=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B ua&=3Bnbsp=3D3B&=3Bnbsp= >=3D3B : Uin.struct_in_addr=3D3B<=3BBR>=3B&=3Bnbsp=3D3B =3D
>=3B= > >=3BBEGIN<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B = >IF Unix.gethostname (ADR (host[0])=3D2C BYT=3D
>=3B >=3BESIZE (host)= >) # 0 THEN<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&am= >p=3Bnbsp=3D3B&=3Bnbsp=3D3B IOError =3D
>=3B >=3B(Unexpected)=3D3B= ><=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B END=3D3B<= >=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3= >B info :=3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3B<=3B=3D
>=3B = >>=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B IF info =3D3= >D NIL THEN IOError (Unexpected)=3D3B EN=3D
>=3B >=3BD=3D3B<=3BBR&g= >t=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B &=3Blt=3D3B* ASSERT= > info.h_length &=3Blt=3D3B=3D3D BYT=3D
>=3B >=3BESIZE (Address) *= >&=3Bgt=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B&=3Bnbsp=3D= >3B&=3Bnbsp=3D3B ua :=3D3D LOOPHOLE(info.h_addr_list=3D2C<=3BBR>=3B&a= >mp=3Bnbsp=3D3B&=3Bn=3D
>=3B >=3Bbsp=3D3B&=3Bnbsp=3D3B&=3Bnb= >sp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&= >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D
>=3B >=3B=3D3B&=3Bnbsp= >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&= >=3Bnbsp=3D3B&=3Bnbsp=3D3B UNTRACED REF UN=3D
>=3B >=3BTRACED REF = >Uin.struct_in_addr)^^=3D3B<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&am= >p=3Bnbsp=3D3B RETURN LOOP=3D
>=3B >=3BHOLE (ua.s_addr=3D2C Address)= >=3D3B<=3BBR>=3B&=3Bnbsp=3D3B END GetHostAddr=3D3B<=3BBR>=3B
&= >gt=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B= ><=3BBR>=3B
>=3B >=3BIt is again disappointing to see such code d= >uplication.<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BI guess&=3B= >nbsp=3D3BSameHost can duplicate the logic to predict the error state =3D>>=3B >=3Band return false&=3Bnbsp=3D3Bupon error?<=3BBR>=3B
= >>=3B >=3BDuplicating the logic for a third time. :(<=3BBR>=3B
&g= >t=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B<=3BBR>=3B&am= >p=3Bnbsp=3D3B- Jay<=3BBR>=3B<=3BBR>=3B<=3B/body>=3B
>=3B &= >gt=3B<=3B/html>=3B=3D
>=3B >=3B
>=3B >=3B--_9e67232c-a064= >-417d-879e-227a77e310f9_--

>= > >--_b00371fe-730b-4981-9051-a874361296d7_-- From jay.krell at cornell.edu Mon Jan 12 10:12:44 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 09:12:44 +0000 Subject: [M3devel] Juno (X) networking problem on AMD64_FREEBSD In-Reply-To: <200901120906.n0C96Uwn074046@camembert.async.caltech.edu> References: Your message of "Sun, 11 Jan 2009 22:02:18 GMT." <200901120906.n0C96Uwn074046@camembert.async.caltech.edu> Message-ID: PPC_LINUX not PPC_DARWIN. I think. And at one point AMD64_LINUX (same machine as AMD64_FREEBSD, multiboot).I think I tested I386_OPENBSD Juno too and it worked,I don't remember. Oh, but that was in a VM, so different networking setup. This is Trestle startup, seeing if there mightbe shared memory available between the X client and server. If $DISPLAY is set, to specify the server, it wants to comparethat against "current", the client.You know, if I set DISPLAY=:0.0 or localhost:0.0, don't penalize perf,but if it really is remote, then do penalize perf. /Something/ like that. I hardly read the code.. - Jay> To: jay.krell at cornell.edu> Date: Mon, 12 Jan 2009 01:06:30 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Juno (X) networking problem on AMD64_FREEBSD> > Jay,> > I think the problem here is actually in the caller. Why does a> caller need "GetHostAddr()"? It is probably doing this for the> purpose of calling listen() or some such thing. What the caller> probably *really* wants is INADDR_ANY, and not the IP address of> some arbitrarily chosen interface on the host.> > I'm guessing it works on the Mac because the Mac libraries do> something complicated when you ask for the host's name (i.e., they> somehow generate a hostname that always maps to the IP address of> an interface on the computer).> > Mika> > Jay writes:> >--_b00371fe-730b-4981-9051-a874361296d7_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >Do you know the right way?> >=20> >PPC_LINUX "just worked"=2C and I can check Solaris and Darwin.> >=20> >I don't want to edit /etc/hosts -- I use DHCP.> >Though DHCP has been bothering me -- only for some of my machines do names => >resolve=2C so I end using IP addresses=2C which change sometimes=2C and I l=> >oop over them running ssh to all of them and "see what I get"=2C not ideal.> >=20> > - Jay> To: jay.krell at cornell.edu> Date: Sun=2C 11 Jan 2009 08:02:18 -0800>=> > From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3d=> >evel] Juno (X) networking problem on AMD64_FREEBSD> > This is a screwy thin=> >g in Modula-3. A bug I would call it.> > I've noticed a lot of networking M=> >3 programs don't work right unless> the return value of Unix's "hostname" m=> >aps to a real IP address via> gethostbyname. I accomplish it in practice by=> > adding my hostname> to /etc/hosts.> > This is obviously not the right way => >to fix it... > > Mika> > Jay writes:> >--_9e67232c-a064-417d-879e-227a77e31=> >0f9_> >Content-Type: text/plain=3B charset=3D"iso-8859-1"> >Content-Transfe=> >r-Encoding: quoted-printable> >> >> >Hi. Unix network programming question.=> >.> >AMD64_FREEBSD:> >$DISPLAY is set to point back to Cygwin host.It works => >for PPC_LINUX.> >[jay at fbsdamd64a /cm3/bin]$ ./Juno> >****** runtime error:*=> >** Exception "IPError.FatalError" not in RAISES li=3D> >st*** file "../src/=> >common/IPError.m3"=3D2C line 27***> >Abort trap: 6 (core dumped)[jay at fbsdam=> >d64a /cm3/bin]$> >IP.m3:> >=3D20> >PROCEDURE GetHostAddr(): Address =3D3D V=> >AR hname: ARRAY [0..255] OF CHAR=3D3B =3D> > BEGIN LOCK mu DO IF Unix.getho=> >stname(ADR(hname[0])=3D2C BYTESIZE(hna=3D> >me)) # 0 THEN IPError.Die ()=3D=> >3B END=3D3B VAR h :=3D3D Unetdb.g=3D> >ethostbyname(ADR(hname[0]))=3D3B BEG=> >IN IF h =3D3D NIL THEN IPError.Die()=3D> >=3D3B END=3D3B RETURN GetAddress(=> >h)=3D3B END=3D3B END=3D3B END GetHos=3D> >tAddr=3D3B> >PROCEDURE GetAddress=> > (ent: Unetdb.struct_hostent_star): Address =3D3D VAR ua=3D> >: Uin.struct_=> >in_addr=3D3B BEGIN <* ASSERT ent.h_length <=3D3D BYTESIZE(Addr=3D> >ess) *>=> > ua :=3D3D LOOPHOLE(ent.h_addr_list=3D2C UNTRACED =3D> >REF UNTRACED REF Ui=> >n.struct_in_addr)^^=3D3B RETURN LOOPHOLE(ua.s_addr=3D2C A=3D> >ddress)=3D3B=> > END GetAddress=3D3B> >=3D20> >gethostbyname is failing.> >=3D20> >Analogou=> >s C code also fails:> >=3D20> >[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c#include=> > #include #i=3D> >nclude #include type=> >def struct hostent hostent_t=3D3B> >=3D20> >int main(){ char hostname[200]=> >=3D3B hostent_t* h=3D3B int i=3D3B> > i =3D3D gethostname(hostname=3D2C 200=> >)=3D3B assert(i =3D3D=3D3D 0)=3D3B printf("hostna=3D> >me: %s\n"=3D2C hostn=> >ame)=3D3B h =3D3D gethostbyname(hostname)=3D3B herror("foo")=3D3B=3D> > pri=> >ntf("%p %d %d\n"=3D2C h=3D2C errno=3D2C h_errno)=3D3B assert(h)=3D3B return=> > 0=3D3B}> >=3D20> >herror says "unknown host".> >Stack is:> > at ../src/run=> >time/ex_frame/RTExFrame.m3:58#13 0x0000000801a7f2b3 in RTH=3D> >ooks__Raise=> > (M3_AJWxb1_ex=3D3DError accessing memory address 0x8000ffffd278: =3D> >Bad=> > address.) at ../src/runtime/common/RTHooks.m3:79#14 0x000000080169c8=3D> >=> >d3 in IPError__Die () at ../src/common/IPError.m3:27#15 0x0000000801698a3e => >=3D> >in IP__GetHostAddr (M3_BCxjPn__result=3D3DError accessing memory addr=> >ess 0x80=3D> >00ffffd338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x00000=> >008012133d0=3D> > in XSharedMem__SameHost (M3_AQuuui_trsl=3D3DError accessi=> >ng memory address 0=3D> >x8000ffffd4d8: Bad address.) at ../src/xvbt/XShare=> >dMem.m3:96#17 0x000000=3D> >0801212ab7 in XSharedMem__InitXClient (M3_AQuuu=> >i_v=3D3DError accessing memory=3D> > address 0x8000ffffd648: Bad address.) => >at ../src/xvbt/XSharedMem.m3:29#1=3D> >8 0x0000000801211819 in XExtensions_=> >_InitXClient (M3_AQuuui_xclient=3D3DError=3D> > accessing memory address 0x=> >8000ffffd7f8: Bad address.) at ../src/xvbt/X=3D> >Extensions.m3:14#19 0x000=> >00008012467a4 in XClientF__Connect (M3_Bd56fi_inst=3D> >=3D3D0x1879b=3D2C M=> >3_AQuuui_trsl=3D3D0x6) at ../src/xvbt/XClientF.m3:583---Typ=3D> >e => > to continue=3D2C or q to quit---(More stack frames follow=3D> >..=> >.)(gdb)> >(* return TRUE if server and client are on same host *)PROCEDURE => >SameHost (=3D> >trsl: XClient.T): BOOLEAN =3D3D VAR display :=3D3D DisplayH=> >=3D> >ost(trsl)=3D3B displayAddr: IP.Address=3D3B BEGIN IF display =3D3D NI=> >L THE=3D> >N RETURN TRUE=3D3B END=3D3B> > TRY IF NOT IP.GetHostByName(displ=> >ay=3D2C displayAddr) THEN RETURN FA=3D> >LSE=3D3B END=3D3B RETURN displayAd=> >dr =3D3D IP.GetHostAddr()=3D3B EXCEPT =3D> >| IP.Error =3D3D> RETURN FALSE=> >=3D3B END=3D3B END SameHost=3D3B> >=3D20> >Thoughts?> >=3D20> >Perhaps my n=> >etwork isn't setup well=3D2C like I should add the local machine =3D> >to /=> >etc/hosts.I think this can be made to fail gracefully though.It seems l=3D>=> > >ike it has nothing to do with AMD64_FREEBSD=3D2C but could have to do wit=> >h Fr=3D> >eeBSD.> >=3D20> >Seems like SocketPosix has nearly the exact same=> > code but appearsmore forgi=3D> >ving.. IOError instead of Fatal?> >=3D20> => >>SocketPosix.m3:> >=3D20> >PROCEDURE GetHostAddr (): Address RAISES {OSErro=> >r.E} =3D3D VAR host : AR=3D> >RAY [0..255] OF CHAR=3D3B info : Unetdb.struc=> >t_hostent_star=3D3B ua : U=3D> >in.struct_in_addr=3D3B BEGIN IF Unix.gethos=> >tname (ADR (host[0])=3D2C BYTESI=3D> >ZE (host)) # 0 THEN IOError (Unexpect=> >ed)=3D3B END=3D3B> > info :=3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3B => >IF info =3D3D NIL TH=3D> >EN IOError (Unexpected)=3D3B END=3D3B <* ASSERT i=> >nfo.h_length <=3D3D BYTESIZE =3D> >(Address) *>> > ua :=3D3D LOOPHOLE(info.=> >h_addr_list=3D2C UNTRACED REF UNT=3D> >RACED REF Uin.struct_in_addr)^^=3D3B=> > RETURN LOOPHOLE (ua.s_addr=3D2C Address=3D> >)=3D3B END GetHostAddr=3D3B> => >>=3D20> >=3D20> >It is again disappointing to see such code duplication.> >=> >=3D20> >=3D20> >I guess SameHost can duplicate the logic to predict the err=> >or state and ret=3D> >urn false upon error?> >Duplicating the logic for a t=> >hird time. :(> >=3D20> > - Jay=3D> >> >--_9e67232c-a064-417d-879e-227a77e31=> >0f9_> >Content-Type: text/html=3B charset=3D"iso-8859-1"> >Content-Transfer=> >-Encoding: quoted-printable> >> >> >> >> >> > >mmessage'>> >Hi. Unix network programming question..
> >
AMD64_FREEBS=> >D:
> >
$DISPLAY is set to point back to Cygwin host.
It works for => >PPC_LINUX=3D> >.
> >
[jay at fbsdamd64a /cm3/bin]$ ./Juno
> >
***<=> >BR>*** runtime error:
*** =3D3B =3D3B =3D3B Exception "IPE=> >=3D> >rror.FatalError" not in RAISES list
*** =3D3B =3D3B => >=3D3B file "..=3D> >/src/common/IPError.m3"=3D2C line 27
***
> >
A=> >bort trap: 6 (core dumped)
[jay at fbsdamd64a /cm3/bin]$
> >
IP.m3: >R>> > =3D3B
> >PROCEDURE GetHostAddr(): Address =3D3D
 =3D3B => >VAR hname: ARRAY [0..255] =3D> OF CHAR=3D3B
 =3D3B BEGIN
 =3D=> >3B =3D3B =3D3B LOCK mu DO
&nbs=3D> >p=3D3B =3D3B =3D3B&n=> >bsp=3D3B =3D3B IF Unix.gethostname(ADR(hname[0])=3D2C B=3D> >YTESIZE(hn=> >ame)) # 0 THEN
 =3D3B =3D3B =3D3B =3D3B =3D3B => >=3D> >=3D3B =3D3B IPError.Die ()=3D3B
 =3D3B =3D3B =3D3B=> > =3D3B =3D3B E=3D> >ND=3D3B
 =3D3B =3D3B =3D3B => >=3D3B =3D3B VAR h :=3D3D Unetdb.gethost=3D> >byname(ADR(hname[0]))=3D3B=> > BEGIN
 =3D3B =3D3B =3D3B =3D3B =3D3B&=3D> >nbsp=3D3=> >B =3D3B IF h =3D3D NIL THEN IPError.Die()=3D3B END=3D3B
 =3D3B&n=> >bsp=3D> >=3D3B =3D3B =3D3B =3D3B =3D3B =3D3B RETURN Get=> >Address(h)=3D3B
&nbs=3D> >p=3D3B =3D3B =3D3B =3D3B =3D3B=> > END=3D3B
 =3D3B =3D3B =3D3B END=3D> >=3D3B
 =3D3B EN=> >D GetHostAddr=3D3B
> >
PROCEDURE GetAddress (ent: Unetdb.struct_hoste=> >nt_star): Address =3D3D
=3D> > =3D3B VAR ua: Uin.struct_in_addr=3D3B=> >
 =3D3B BEGIN
 =3D3B =3D> >=3D3B =3D3B <=3D3B* ASSE=> >RT ent.h_length <=3D3B=3D3D BYTESIZE(Address) *>=3D3B=3D> >
 =3D=> >3B =3D3B =3D3B ua :=3D3D LOOPHOLE(ent.h_addr_list=3D2C
 =3D>=> > >=3D3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D=> >3B =3D3B =3D3B=3D> > =3D3B =3D3B =3D3B =3D3B => >=3D3B =3D3B =3D3B =3D3B =3D3B UN=3D> >TRACED REF UNTRACED R=> >EF Uin.struct_in_addr)^^=3D3B
 =3D3B =3D3B =3D> >=3D3B RETUR=> >N LOOPHOLE(ua.s_addr=3D2C Address)=3D3B
 =3D3B END GetAddress=3D3B<=> >=3D> >BR>> > =3D3B
> >gethostbyname is failing.
> >
 =3D3B=> >
> >Analogous C code also fails:
> > =3D3B
> >
[jay at fbsdamd=> >64a /cm3/bin]$ cat ~/5.c
#include <=3D3Bassert.h>=3D3B >R>#inc=> >lude <=3D3Bnetdb.h>=3D3B
#include <=3D3Bstdio.h>=3D3B
#includ=> >e =3D> ><=3D3Berrno.h>=3D3B
typedef struct hostent hostent_t=3D3B >>> > =3D3B
> >int main()
{
 =3D3Bchar hostname[200]=3D3B >R> =3D3Bhostent_t* h=3D3B=3D> >
 =3D3Bint i=3D3B
> > =3D3=> >Bi =3D3D gethostname(hostname=3D2C 200)=3D3B
 =3D3Bassert(i =3D3D=3D=> >3D 0)=3D> >=3D3B
 =3D3Bprintf("hostname: %s\n"=3D2C hostname)=3D3B >R> =3D3Bh =3D3D get=3D> >hostbyname(hostname)=3D3B
 =3D3Bherror(=> >"foo")=3D3B
 =3D3Bprintf("%p %=3D> >d %d\n"=3D2C h=3D2C errno=3D2C h=> >_errno)=3D3B
 =3D3Bassert(h)=3D3B
 =3D3Bret=3D> >urn 0=3D3B >R>}
> > =3D3B
> >herror says "unknown host".
> >
Stack is:<=> >BR>> > =3D3B =3D3B =3D3B at ../src/runtime/ex_frame/RTExFrame.m=> >3:58
#13 =3D> >0x0000000801a7f2b3 in RTHooks__Raise (M3_AJWxb1_ex=3D3DEr=> >ror accessing memory=3D> > ad
dress 0x8000ffffd278: Bad address.
) >> =3D3B =3D3B =3D3B =3D> >at ../src/runtime/common/RTHooks.m3:7=> >9
#14 0x000000080169c8d3 in IPError=3D> >__Die () at ../src/common/IPErr=> >or.m3:27
#15 0x0000000801698a3e in IP__Ge=3D> >tHostAddr (M3_BCxjPn__res=> ult=3D3DError accessing mem
ory address 0x8000fff=3D> >fd338: Bad addres=> >s.
)
 =3D3B =3D3B =3D3B at ../src/POSIX/IP.m3:=3D> >82 >>#16 0x00000008012133d0 in XSharedMem__SameHost (M3_AQuuui_trsl=3D3DErro=3D=> >> >r accessing m
emory address 0x8000ffffd4d8: Bad address.
)
&nbs=> >p=3D> >=3D3B =3D3B =3D3B at ../src/xvbt/XSharedMem.m3:96
#17 0x0=> >000000801212a=3D> >b7 in XSharedMem__InitXClient (M3_AQuuui_v=3D3DError acc=> >essing m
emory add=3D> >ress 0x8000ffffd648: Bad address.
)
 => >=3D3B =3D3B =3D3B at ../sr=3D> >c/xvbt/XSharedMem.m3:29
#18 0x00=> >00000801211819 in XExtensions__InitXClie=3D> >nt (M3_AQuuui_xclient=3D3DErr=> >or acce
ssing memory address 0x8000ffffd7f8: =3D> >Bad address.
)
=> > =3D3B =3D3B =3D3B at ../src/xvbt/XExtensions.m3=3D> >:14
#1=> >9 0x00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst=3D3D0x1879=3D> >b=> >=3D2C
 =3D3B =3D3B =3D3B M3_AQuuui_trsl=3D3D0x6) at ../src/x=> >vbt/XClie=3D> >ntF.m3:583
---Type <=3D3Breturn>=3D3B to continue=3D2=> >C or q <=3D3Breturn&g=3D> >t=3D3B to quit---
(More stack frames follow=> >...)
(gdb)
> >
(* return TRUE if server and client are on same hos=> >t *)
PROCEDURE Sa=3D> >meHost (trsl: XClient.T): BOOLEAN =3D3D
 => >=3D3B VAR
 =3D3B =3D3B&n=3D> >bsp=3D3B display =3D3B =3D=> >3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D> >=3D3B => >=3D3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D3B=> :=3D3D Di=3D> >splayHost(trsl)=3D3B
 =3D3B =3D3B =3D3B disp=> >layAddr: IP.Address=3D3B >R> =3D3B BEGIN
 =3D3B =3D3B&=> >nbsp=3D3B IF display =3D3D NIL THEN RETURN=3D> > TRUE=3D3B END=3D3B
> >&=> >nbsp=3D3B =3D3B =3D3B TRY
 =3D3B =3D3B =3D3B =3D=> >3B =3D3B IF=3D> > NOT IP.GetHostByName(display=3D2C displayAddr) THEN R=> >ETURN FALSE=3D3B END=3D3B >R> =3D3B =3D3B =3D3B =3D3B=> > =3D3B RETURN displayAddr =3D3D IP.GetHos=3D> >tAddr()=3D3B
 =3D=> >3B =3D3B =3D3B EXCEPT
 =3D3B =3D3B =3D3B |=3D> > IP.=> >Error =3D3D>=3D3B RETURN FALSE=3D3B
 =3D3B =3D3B =3D3B END=> >=3D3B
&=3D> >nbsp=3D3B END SameHost=3D3B
> > =3D3B
> >Thoughts=> >?
> > =3D3B
> >
Perhaps my network isn't setup well=3D2C like => >I should add the local mach=3D> >ine to /etc/hosts.
I think this can be => >made to fail gracefully though. >R>It seems like it has nothing to do=> > with AMD64_FREEBSD=3D2C but could have t=3D> >o do with FreeBSD.
> > >> =3D3B
> >Seems like SocketPosix has nearly the exact same code but=> > appears
more f=3D> >orgiving.. IOError instead of Fatal?
> > =3D=> >3B
> >
SocketPosix.m3:
> > =3D3B
> >
PROCEDURE GetHostAd=> >dr (): Address
 =3D3B RAISES {OSError.E} =3D3D >> =3D3B V=> >AR
 =3D3B =3D3B =3D3B host : ARRAY [0..255] OF CHAR=3D3B<=3D=> >> >BR> =3D3B =3D3B =3D3B info : Unetdb.struct_hostent_star=3D3B=> >
 =3D> >=3D3B =3D3B =3D3B ua =3D3B =3D3B : Uin.struc=> >t_in_addr=3D3B
 =3D3B =3D> >BEGIN
 =3D3B =3D3B =3D3B => >IF Unix.gethostname (ADR (host[0])=3D2C BYT=3D> >ESIZE (host)) # 0 THEN
=> > =3D3B =3D3B =3D3B =3D3B =3D3B IOError =3D> >(Unexpecte=> >d)=3D3B
 =3D3B =3D3B =3D3B END=3D3B
> > =3D3B =3D=> >3B =3D3B info :=3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3B<=3D> >BR=> >> =3D3B =3D3B =3D3B IF info =3D3D NIL THEN IOError (Unexpected)=> >=3D3B EN=3D> >D=3D3B
 =3D3B =3D3B =3D3B <=3D3B* ASSERT inf=> >o.h_length <=3D3B=3D3D BYT=3D> >ESIZE (Address) *>=3D3B
> > =3D3=> >B =3D3B =3D3B ua :=3D3D LOOPHOLE(info.h_addr_list=3D2C
 =3D3=> >B&n=3D> >bsp=3D3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D=> >3B =3D3B =3D3B =3D> >=3D3B =3D3B =3D3B =3D3B => >=3D3B =3D3B =3D3B =3D3B UNTRACED REF UN=3D> >TRACED REF Uin.str=> >uct_in_addr)^^=3D3B
 =3D3B =3D3B =3D3B RETURN LOOP=3D> >HOLE=> > (ua.s_addr=3D2C Address)=3D3B
 =3D3B END GetHostAddr=3D3B
> >&nb=> >sp=3D3B
> > =3D3B
> >It is again disappointing to see such code d=> >uplication.
> > =3D3B
> > =3D3B
> >I guess =3D3BSameHo=> >st can duplicate the logic to predict the error state =3D> >and return fals=> >e =3D3Bupon error?
> >Duplicating the logic for a third time. :(
=> >> > =3D3B
> >
 =3D3B- Jay

> >=3D> >> >--=> >_9e67232c-a064-417d-879e-227a77e310f9_--=> >> >--_b00371fe-730b-4981-9051-a874361296d7_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >> >Do you know the right way?
> > =3B
> >PPC_LINUX "just worked"=2C and I can check Solaris and Darwin.
> > =3B
> >I don't want to edit /etc/hosts -- I use DHCP.
> >Though DHCP has been bothering me -- only for some of my machines do names => >resolve=2C so I end using IP addresses=2C which change sometimes=2C and I l=> >oop over them running ssh to all of them and "see what I get"=2C not ideal.=> >
> > =3B
> > =3B- Jay


>=3B To: jay.krell at cornell.edu
>=3B Date: S=> >un=2C 11 Jan 2009 08:02:18 -0800
>=3B From: mika at async.caltech.edu
=> >>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] Juno (X) => >networking problem on AMD64_FREEBSD
>=3B
>=3B This is a screwy t=> >hing in Modula-3. A bug I would call it.
>=3B
>=3B I've noticed => >a lot of networking M3 programs don't work right unless
>=3B the retur=> >n value of Unix's "hostname" maps to a real IP address via
>=3B gethos=> >tbyname. I accomplish it in practice by adding my hostname
>=3B to /et=> >c/hosts.
>=3B
>=3B This is obviously not the right way to fix it=> >...
>=3B
>=3B Mika
>=3B
>=3B Jay writes:
>=3B &=> >gt=3B--_9e67232c-a064-417d-879e-227a77e310f9_
>=3B >=3BContent-Type:=> > text/plain=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Enco=> >ding: quoted-printable
>=3B >=3B
>=3B >=3B
>=3B >=3BHi=> >. Unix network programming question..
>=3B >=3BAMD64_FREEBSD:
>=> >=3B >=3B$DISPLAY is set to point back to Cygwin host.It works for PPC_LIN=> >UX.
>=3B >=3B[jay at fbsdamd64a /cm3/bin]$ ./Juno
>=3B >=3B*****=> >* runtime error:*** Exception "IPError.FatalError" not in RAISES li=3D
&=> >gt=3B >=3Bst*** file "../src/common/IPError.m3"=3D2C line 27***
>=3B=> > >=3BAbort trap: 6 (core dumped)[jay at fbsdamd64a /cm3/bin]$
>=3B >=> >=3BIP.m3:
>=3B >=3B=3D20
>=3B >=3BPROCEDURE GetHostAddr(): Ad=> >dress =3D3D VAR hname: ARRAY [0..255] OF CHAR=3D3B =3D
>=3B >=3B BEG=> >IN LOCK mu DO IF Unix.gethostname(ADR(hname[0])=3D2C BYTESIZE(hna=3D
>=> >=3B >=3Bme)) # 0 THEN IPError.Die ()=3D3B END=3D3B VAR h :=3D3D Unetdb.g=> >=3D
>=3B >=3Bethostbyname(ADR(hname[0]))=3D3B BEGIN IF h =3D3D NIL T=> >HEN IPError.Die()=3D
>=3B >=3B=3D3B END=3D3B RETURN GetAddress(h)=3D=> >3B END=3D3B END=3D3B END GetHos=3D
>=3B >=3BtAddr=3D3B
>=3B >=> >=3BPROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Address =3D3D VA=> >R ua=3D
>=3B >=3B: Uin.struct_in_addr=3D3B BEGIN <=3B* ASSERT ent.=> >h_length <=3B=3D3D BYTESIZE(Addr=3D
>=3B >=3Bess) *>=3B ua :=3D3=> >D LOOPHOLE(ent.h_addr_list=3D2C UNTRACED =3D
>=3B >=3BREF UNTRACED R=> >EF Uin.struct_in_addr)^^=3D3B RETURN LOOPHOLE(ua.s_addr=3D2C A=3D
>=3B=> > >=3Bddress)=3D3B END GetAddress=3D3B
>=3B >=3B=3D20
>=3B >=> >=3Bgethostbyname is failing.
>=3B >=3B=3D20
>=3B >=3BAnalogou=> >s C code also fails:
>=3B >=3B=3D20
>=3B >=3B[jay at fbsdamd64a => >/cm3/bin]$ cat ~/5.c#include <=3Bassert.h>=3B#include <=3Bnetdb.h>=> >=3B#i=3D
>=3B >=3Bnclude <=3Bstdio.h>=3B#include <=3Berrno.h&g=> >t=3Btypedef struct hostent hostent_t=3D3B
>=3B >=3B=3D20
>=3B &=> >gt=3Bint main(){ char hostname[200]=3D3B hostent_t* h=3D3B int i=3D3B
&g=> >t=3B >=3B i =3D3D gethostname(hostname=3D2C 200)=3D3B assert(i =3D3D=3D3D=> > 0)=3D3B printf("hostna=3D
>=3B >=3Bme: %s\n"=3D2C hostname)=3D3B h => >=3D3D gethostbyname(hostname)=3D3B herror("foo")=3D3B=3D
>=3B >=3B p=> >rintf("%p %d %d\n"=3D2C h=3D2C errno=3D2C h_errno)=3D3B assert(h)=3D3B retu=> >rn 0=3D3B}
>=3B >=3B=3D20
>=3B >=3Bherror says "unknown host"=> >.
>=3B >=3BStack is:
>=3B >=3B at ../src/runtime/ex_frame/RTE=> >xFrame.m3:58#13 0x0000000801a7f2b3 in RTH=3D
>=3B >=3Books__Raise (M=> >3_AJWxb1_ex=3D3DError accessing memory address 0x8000ffffd278: =3D
>=> >=3B >=3BBad address.) at ../src/runtime/common/RTHooks.m3:79#14 0x0000000=> >80169c8=3D
>=3B >=3Bd3 in IPError__Die () at ../src/common/IPError.m=> >3:27#15 0x0000000801698a3e =3D
>=3B >=3Bin IP__GetHostAddr (M3_BCxjP=> >n__result=3D3DError accessing memory address 0x80=3D
>=3B >=3B00ffff=> >d338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x00000008012133d0=3D
&g=> >t=3B >=3B in XSharedMem__SameHost (M3_AQuuui_trsl=3D3DError accessing mem=> >ory address 0=3D
>=3B >=3Bx8000ffffd4d8: Bad address.) at ../src/xvb=> >t/XSharedMem.m3:96#17 0x000000=3D
>=3B >=3B0801212ab7 in XSharedMem_=> >_InitXClient (M3_AQuuui_v=3D3DError accessing memory=3D
>=3B >=3B ad=> >dress 0x8000ffffd648: Bad address.) at ../src/xvbt/XSharedMem.m3:29#1=3D >>>=3B >=3B8 0x0000000801211819 in XExtensions__InitXClient (M3_AQuuui_x=> >client=3D3DError=3D
>=3B >=3B accessing memory address 0x8000ffffd7f=> >8: Bad address.) at ../src/xvbt/X=3D
>=3B >=3BExtensions.m3:14#19 0x=> >00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst=3D
>=3B >=3B=> >=3D3D0x1879b=3D2C M3_AQuuui_trsl=3D3D0x6) at ../src/xvbt/XClientF.m3:583---=> >Typ=3D
>=3B >=3Be <=3Breturn>=3B to continue=3D2C or q <=3Bret=> >urn>=3B to quit---(More stack frames follow=3D
>=3B >=3B...)(gdb)<=> >BR>>=3B >=3B(* return TRUE if server and client are on same host *)PROC=> >EDURE SameHost (=3D
>=3B >=3Btrsl: XClient.T): BOOLEAN =3D3D VAR dis=> >play :=3D3D DisplayH=3D
>=3B >=3Bost(trsl)=3D3B displayAddr: IP.Addr=> >ess=3D3B BEGIN IF display =3D3D NIL THE=3D
>=3B >=3BN RETURN TRUE=3D=> >3B END=3D3B
>=3B >=3B TRY IF NOT IP.GetHostByName(display=3D2C displ=> >ayAddr) THEN RETURN FA=3D
>=3B >=3BLSE=3D3B END=3D3B RETURN displayA=> >ddr =3D3D IP.GetHostAddr()=3D3B EXCEPT =3D
>=3B >=3B| IP.Error =3D3D=> >>=3B RETURN FALSE=3D3B END=3D3B END SameHost=3D3B
>=3B >=3B=3D20 >R>>=3B >=3BThoughts?
>=3B >=3B=3D20
>=3B >=3BPerhaps my n=> >etwork isn't setup well=3D2C like I should add the local machine =3D
>=> >=3B >=3Bto /etc/hosts.I think this can be made to fail gracefully though.=> >It seems l=3D
>=3B >=3Bike it has nothing to do with AMD64_FREEBSD=> >=3D2C but could have to do with Fr=3D
>=3B >=3BeeBSD.
>=3B >=> >=3B=3D20
>=3B >=3BSeems like SocketPosix has nearly the exact same c=> >ode but appearsmore forgi=3D
>=3B >=3Bving.. IOError instead of Fata=> >l?
>=3B >=3B=3D20
>=3B >=3BSocketPosix.m3:
>=3B >=3B=> >=3D20
>=3B >=3BPROCEDURE GetHostAddr (): Address RAISES {OSError.E} => >=3D3D VAR host : AR=3D
>=3B >=3BRAY [0..255] OF CHAR=3D3B info : Une=> >tdb.struct_hostent_star=3D3B ua : U=3D
>=3B >=3Bin.struct_in_addr=3D=> >3B BEGIN IF Unix.gethostname (ADR (host[0])=3D2C BYTESI=3D
>=3B >=3B=> >ZE (host)) # 0 THEN IOError (Unexpected)=3D3B END=3D3B
>=3B >=3B inf=> >o :=3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3B IF info =3D3D NIL TH=3D<=> >BR>>=3B >=3BEN IOError (Unexpected)=3D3B END=3D3B <=3B* ASSERT info.h=> >_length <=3B=3D3D BYTESIZE =3D
>=3B >=3B(Address) *>=3B
>=> >=3B >=3B ua :=3D3D LOOPHOLE(info.h_addr_list=3D2C UNTRACED REF UNT=3D
=> >>=3B >=3BRACED REF Uin.struct_in_addr)^^=3D3B RETURN LOOPHOLE (ua.s_add=> >r=3D2C Address=3D
>=3B >=3B)=3D3B END GetHostAddr=3D3B
>=3B >=> >=3B=3D20
>=3B >=3B=3D20
>=3B >=3BIt is again disappointing to=> > see such code duplication.
>=3B >=3B=3D20
>=3B >=3B=3D20
=> >>=3B >=3BI guess SameHost can duplicate the logic to predict the error => >state and ret=3D
>=3B >=3Burn false upon error?
>=3B >=3BDupl=> >icating the logic for a third time. :(
>=3B >=3B=3D20
>=3B >=> >=3B - Jay=3D
>=3B >=3B
>=3B >=3B--_9e67232c-a064-417d-879e-22=> >7a77e310f9_
>=3B >=3BContent-Type: text/html=3B charset=3D"iso-8859-=> >1"
>=3B >=3BContent-Transfer-Encoding: quoted-printable
>=3B &g=> >t=3B
>=3B >=3B<=3Bhtml>=3B
>=3B >=3B<=3Bhead>=3B
&=> >gt=3B >=3B<=3Bstyle>=3B
>=3B >=3B.hmmessage P
>=3B >=3B=> >{
>=3B >=3Bmargin:0px=3D3B
>=3B >=3Bpadding:0px
>=3B >=> >=3B}
>=3B >=3Bbody.hmmessage
>=3B >=3B{
>=3B >=3Bfont-=> >size: 10pt=3D3B
>=3B >=3Bfont-family:Verdana
>=3B >=3B}
&g=> >t=3B >=3B<=3B/style>=3B
>=3B >=3B<=3B/head>=3B
>=3B &=> >gt=3B<=3Bbody class=3D3D'hmmessage'>=3B
>=3B >=3BHi. Unix networ=> >k programming question..<=3BBR>=3B
>=3B >=3B<=3BBR>=3BAMD64_=> >FREEBSD:<=3BBR>=3B
>=3B >=3B<=3BBR>=3B$DISPLAY is set to poi=> >nt back to Cygwin host.<=3BBR>=3BIt works for PPC_LINUX=3D
>=3B &g=> >t=3B.<=3BBR>=3B
>=3B >=3B<=3BBR>=3B[jay at fbsdamd64a /cm3/bin]=> >$ ./Juno<=3BBR>=3B
>=3B >=3B<=3BBR>=3B***<=3BBR>=3B*** r=> >untime error:<=3BBR>=3B***&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=> >=3D3B Exception "IPE=3D
>=3B >=3Brror.FatalError" not in RAISES list=> ><=3BBR>=3B***&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B file "..=> >=3D
>=3B >=3B/src/common/IPError.m3"=3D2C line 27<=3BBR>=3B***&l=> >t=3BBR>=3B
>=3B >=3B<=3BBR>=3BAbort trap: 6 (core dumped)<=> >=3BBR>=3B[jay at fbsdamd64a /cm3/bin]$<=3BBR>=3B
>=3B >=3B<=3BB=> >R>=3BIP.m3:<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B<=> >BR>>=3B >=3BPROCEDURE GetHostAddr(): Address =3D3D<=3BBR>=3B&=3B=> >nbsp=3D3B VAR hname: ARRAY [0..255] =3D
>=3B OF CHAR=3D3B<=3BBR>=> >=3B&=3Bnbsp=3D3B BEGIN<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=> >=3Bnbsp=3D3B LOCK mu DO<=3BBR>=3B&=3Bnbs=3D
>=3B >=3Bp=3D3B&a=> >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B IF Unix.geth=> >ostname(ADR(hname[0])=3D2C B=3D
>=3B >=3BYTESIZE(hname)) # 0 THEN<=> >=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B=> >&=3Bnbsp=3D3B&=3Bnbsp=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B IPErro=> >r.Die ()=3D3B<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B=> >&=3Bnbsp=3D3B&=3Bnbsp=3D3B E=3D
>=3B >=3BND=3D3B<=3BBR>=3B=> >&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=> >=3D3B VAR h :=3D3D Unetdb.gethost=3D
>=3B >=3Bbyname(ADR(hname[0]))=> >=3D3B BEGIN<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&a=> >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3B=3D
>=3B >=3Bnbsp=3D3B&=3Bnb=> >sp=3D3B IF h =3D3D NIL THEN IPError.Die()=3D3B END=3D3B<=3BBR>=3B&=> >=3Bnbsp=3D3B&=3Bnbsp=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B&=3Bnbsp=> >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B RETURN GetAddress(h)=> >=3D3B<=3BBR>=3B&=3Bnbs=3D
>=3B >=3Bp=3D3B&=3Bnbsp=3D3B&=> >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B END=3D3B<=3BBR>=3B&=3Bn=> >bsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B END=3D
>=3B >=3B=3D3B<=3B=> >BR>=3B&=3Bnbsp=3D3B END GetHostAddr=3D3B<=3BBR>=3B
>=3B >=> >=3B<=3BBR>=3BPROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Ad=> >dress =3D3D<=3BBR>=3B=3D
>=3B >=3B&=3Bnbsp=3D3B VAR ua: Uin.s=> >truct_in_addr=3D3B<=3BBR>=3B&=3Bnbsp=3D3B BEGIN<=3BBR>=3B&=3B=> >nbsp=3D3B&=3Bnbsp=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B &=3Blt=3D3=> >B* ASSERT ent.h_length &=3Blt=3D3B=3D3D BYTESIZE(Address) *&=3Bgt=3D3=> >B=3D
>=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bn=> >bsp=3D3B ua :=3D3D LOOPHOLE(ent.h_addr_list=3D2C<=3BBR>=3B&=3Bnbsp=> >=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&a=> >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=> >=3D3B&=3Bnbsp=3D3B=3D
>=3B >=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&a=> >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=> >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B UN=3D
>=3B >=3BTRACED REF UNTR=> ACED REF Uin.struct_in_addr)^^=3D3B<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbs=> >p=3D3B&=3Bnbsp=3D
>=3B >=3B=3D3B RETURN LOOPHOLE(ua.s_addr=3D2C A=> >ddress)=3D3B<=3BBR>=3B&=3Bnbsp=3D3B END GetAddress=3D3B<=3B=3D
=> >>=3B >=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=> >=3B >=3Bgethostbyname is failing.<=3BBR>=3B
>=3B >=3B<=3BBR&=> >gt=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BAnalogous C code also f=> >ails:<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=> >=3B >=3B<=3BBR>=3B[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c<=3BBR>=3B#=> >include &=3Blt=3D3Bassert.h&=3Bgt=3D3B<=3BB=3D
>=3B >=3BR>=> >=3B#include &=3Blt=3D3Bnetdb.h&=3Bgt=3D3B<=3BBR>=3B#include &=> >=3Blt=3D3Bstdio.h&=3Bgt=3D3B<=3BBR>=3B#include =3D
>=3B >=3B&=> >amp=3Blt=3D3Berrno.h&=3Bgt=3D3B<=3BBR>=3Btypedef struct hostent host=> >ent_t=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
=> >>=3B >=3Bint main()<=3BBR>=3B{<=3BBR>=3B&=3Bnbsp=3D3Bchar ho=> >stname[200]=3D3B<=3BBR>=3B&=3Bnbsp=3D3Bhostent_t* h=3D3B=3D
>=> >=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3Bint i=3D3B<=3BBR>=3B
>=3B => >>=3B&=3Bnbsp=3D3Bi =3D3D gethostname(hostname=3D2C 200)=3D3B<=3BBR&g=> >t=3B&=3Bnbsp=3D3Bassert(i =3D3D=3D3D 0)=3D
>=3B >=3B=3D3B<=3BBR=> >>=3B&=3Bnbsp=3D3Bprintf("hostname: %s\n"=3D2C hostname)=3D3B<=3BBR&g=> >t=3B&=3Bnbsp=3D3Bh =3D3D get=3D
>=3B >=3Bhostbyname(hostname)=3D3=> >B<=3BBR>=3B&=3Bnbsp=3D3Bherror("foo")=3D3B<=3BBR>=3B&=3Bnbsp=> >=3D3Bprintf("%p %=3D
>=3B >=3Bd %d\n"=3D2C h=3D2C errno=3D2C h_errno=> >)=3D3B<=3BBR>=3B&=3Bnbsp=3D3Bassert(h)=3D3B<=3BBR>=3B&=3Bnbsp=> >=3D3Bret=3D
>=3B >=3Burn 0=3D3B<=3BBR>=3B}<=3BBR>=3B
>=> >=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3Bherror says "unkno=> >wn host".<=3BBR>=3B
>=3B >=3B<=3BBR>=3BStack is:<=3BBR>=> >=3B
>=3B >=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B at ../=> >src/runtime/ex_frame/RTExFrame.m3:58<=3BBR>=3B#13 =3D
>=3B >=3B0=> >x0000000801a7f2b3 in RTHooks__Raise (M3_AJWxb1_ex=3D3DError accessing memor=> >y=3D
>=3B >=3B ad<=3BBR>=3Bdress 0x8000ffffd278: Bad address.<=> >=3BBR>=3B)<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B => >=3D
>=3B >=3Bat ../src/runtime/common/RTHooks.m3:79<=3BBR>=3B#14=> > 0x000000080169c8d3 in IPError=3D
>=3B >=3B__Die () at ../src/common=> >/IPError.m3:27<=3BBR>=3B#15 0x0000000801698a3e in IP__Ge=3D
>=3B &=> >gt=3BtHostAddr (M3_BCxjPn__result=3D3DError accessing mem<=3BBR>=3Bory => >address 0x8000fff=3D
>=3B >=3Bfd338: Bad address.<=3BBR>=3B)<=> >=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B at ../src/POSIX=> >/IP.m3:=3D
>=3B >=3B82<=3BBR>=3B#16 0x00000008012133d0 in XShare=> >dMem__SameHost (M3_AQuuui_trsl=3D3DErro=3D
>=3B >=3Br accessing m<=> >=3BBR>=3Bemory address 0x8000ffffd4d8: Bad address.<=3BBR>=3B)<=3BB=> >R>=3B&=3Bnbsp=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B=> > at ../src/xvbt/XSharedMem.m3:96<=3BBR>=3B#17 0x0000000801212a=3D
&g=> >t=3B >=3Bb7 in XSharedMem__InitXClient (M3_AQuuui_v=3D3DError accessing m=> ><=3BBR>=3Bemory add=3D
>=3B >=3Bress 0x8000ffffd648: Bad address=> >.<=3BBR>=3B)<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=> >=3D3B at ../sr=3D
>=3B >=3Bc/xvbt/XSharedMem.m3:29<=3BBR>=3B#18 => >0x0000000801211819 in XExtensions__InitXClie=3D
>=3B >=3Bnt (M3_AQuu=> >ui_xclient=3D3DError acce<=3BBR>=3Bssing memory address 0x8000ffffd7f8:=> > =3D
>=3B >=3BBad address.<=3BBR>=3B)<=3BBR>=3B&=3Bnbsp=> >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B at ../src/xvbt/XExtensions.m3=3D
&=> >gt=3B >=3B:14<=3BBR>=3B#19 0x00000008012467a4 in XClientF__Connect (M=> >3_Bd56fi_inst=3D3D0x1879=3D
>=3B >=3Bb=3D2C<=3BBR>=3B&=3Bnbsp=> >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B M3_AQuuui_trsl=3D3D0x6) at ../src/xvb=> >t/XClie=3D
>=3B >=3BntF.m3:583<=3BBR>=3B---Type &=3Blt=3D3Bre=> >turn&=3Bgt=3D3B to continue=3D2C or q &=3Blt=3D3Breturn&=3Bg=3D >>>=3B >=3Bt=3D3B to quit---<=3BBR>=3B(More stack frames follow...)&=> >lt=3BBR>=3B(gdb)<=3BBR>=3B
>=3B >=3B<=3BBR>=3B(* return TR=> >UE if server and client are on same host *)<=3BBR>=3BPROCEDURE Sa=3D >>>=3B >=3BmeHost (trsl: XClient.T): BOOLEAN =3D3D<=3BBR>=3B&=3Bn=> >bsp=3D3B VAR<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bn=3D
&g=> >t=3B >=3Bbsp=3D3B display&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B=> >&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=> >=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&a=> >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=> >=3D3B :=3D3D Di=3D
>=3B >=3BsplayHost(trsl)=3D3B<=3BBR>=3B&=> >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B displayAddr: IP.Address=3D3B&l=> >t=3BB=3D
>=3B >=3BR>=3B&=3Bnbsp=3D3B BEGIN<=3BBR>=3B&=3B=> >nbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B IF display =3D3D NIL THEN RETURN=> >=3D
>=3B >=3B TRUE=3D3B END=3D3B<=3BBR>=3B
>=3B >=3B&=> >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B TRY<=3BBR>=3B&=3Bnbsp=> >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B IF=3D=> >
>=3B >=3B NOT IP.GetHostByName(display=3D2C displayAddr) THEN RETUR=> >N FALSE=3D3B END=3D3B<=3BB=3D
>=3B >=3BR>=3B&=3Bnbsp=3D3B&=> >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B RETURN display=> >Addr =3D3D IP.GetHos=3D
>=3B >=3BtAddr()=3D3B<=3BBR>=3B&=3Bnb=> >sp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B EXCEPT<=3BBR>=3B&=3Bnbsp=3D3=> >B&=3Bnbsp=3D3B&=3Bnbsp=3D3B |=3D
>=3B >=3B IP.Error =3D3D&=> >=3Bgt=3D3B RETURN FALSE=3D3B<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=> >amp=3Bnbsp=3D3B END=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bnbsp=3D3B => >END SameHost=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=> >=3B
>=3B >=3BThoughts?<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3=> >B<=3BBR>=3B
>=3B >=3B<=3BBR>=3BPerhaps my network isn't setu=> >p well=3D2C like I should add the local mach=3D
>=3B >=3Bine to /etc=> >/hosts.<=3BBR>=3BI think this can be made to fail gracefully though.<=> >=3BB=3D
>=3B >=3BR>=3BIt seems like it has nothing to do with AMD6=> >4_FREEBSD=3D2C but could have t=3D
>=3B >=3Bo do with FreeBSD.<=3B=> >BR>=3B
>=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B
&g=> >t=3B >=3BSeems like SocketPosix has nearly the exact same code but appear=> >s<=3BBR>=3Bmore f=3D
>=3B >=3Borgiving.. IOError instead of Fata=> >l?<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B &=> >gt=3B<=3BBR>=3BSocketPosix.m3:<=3BBR>=3B
>=3B >=3B&=3Bnbs=> >p=3D3B<=3BBR>=3B
>=3B >=3B<=3BBR>=3BPROCEDURE GetHostAddr ()=> >: Address<=3BBR>=3B&=3Bnbsp=3D3B RAISES {OSError.E} =3D3D<=3BBR=3D=> >
>=3B >=3B>=3B&=3Bnbsp=3D3B VAR<=3BBR>=3B&=3Bnbsp=3D3B&a=> >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B host : ARRAY [0..255] OF CHAR=3D3B<=3B=3D<=> >BR>>=3B >=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B in=> >fo : Unetdb.struct_hostent_star=3D3B<=3BBR>=3B&=3Bnbsp=3D
>=3B => >>=3B=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B ua&=3Bnbsp=3D3B&=3Bnbsp=> >=3D3B : Uin.struct_in_addr=3D3B<=3BBR>=3B&=3Bnbsp=3D3B =3D
>=3B=> > >=3BBEGIN<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B => >IF Unix.gethostname (ADR (host[0])=3D2C BYT=3D
>=3B >=3BESIZE (host)=> >) # 0 THEN<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&am=> >p=3Bnbsp=3D3B&=3Bnbsp=3D3B IOError =3D
>=3B >=3B(Unexpected)=3D3B=> ><=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B END=3D3B<=> >=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3=> >B info :=3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3B<=3B=3D
>=3B => >>=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B IF info =3D3=> >D NIL THEN IOError (Unexpected)=3D3B EN=3D
>=3B >=3BD=3D3B<=3BBR&g=> >t=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B &=3Blt=3D3B* ASSERT=> > info.h_length &=3Blt=3D3B=3D3D BYT=3D
>=3B >=3BESIZE (Address) *=> >&=3Bgt=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B&=3Bnbsp=3D=> >3B&=3Bnbsp=3D3B ua :=3D3D LOOPHOLE(info.h_addr_list=3D2C<=3BBR>=3B&a=> >mp=3Bnbsp=3D3B&=3Bn=3D
>=3B >=3Bbsp=3D3B&=3Bnbsp=3D3B&=3Bnb=> >sp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=> >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D
>=3B >=3B=3D3B&=3Bnbsp=> >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=> >=3Bnbsp=3D3B&=3Bnbsp=3D3B UNTRACED REF UN=3D
>=3B >=3BTRACED REF => >Uin.struct_in_addr)^^=3D3B<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&am=> >p=3Bnbsp=3D3B RETURN LOOP=3D
>=3B >=3BHOLE (ua.s_addr=3D2C Address)=> >=3D3B<=3BBR>=3B&=3Bnbsp=3D3B END GetHostAddr=3D3B<=3BBR>=3B
&=> >gt=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B=> ><=3BBR>=3B
>=3B >=3BIt is again disappointing to see such code d=> >uplication.<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B >>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BI guess&=3B=> >nbsp=3D3BSameHost can duplicate the logic to predict the error state =3D >>>=3B >=3Band return false&=3Bnbsp=3D3Bupon error?<=3BBR>=3B
=> >>=3B >=3BDuplicating the logic for a third time. :(<=3BBR>=3B
&g=> >t=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B<=3BBR>=3B&am=> >p=3Bnbsp=3D3B- Jay<=3BBR>=3B<=3BBR>=3B<=3B/body>=3B
>=3B &=> >gt=3B<=3B/html>=3B=3D
>=3B >=3B
>=3B >=3B--_9e67232c-a064=> >-417d-879e-227a77e310f9_--

> >=> >> >--_b00371fe-730b-4981-9051-a874361296d7_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 10:31:13 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 20:31:13 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20090112092033.2748010D5FD1@birch.elegosoft.com> References: <20090112092033.2748010D5FD1@birch.elegosoft.com> Message-ID: Jay, I have to call it quits on this tonight. As you can see, I've reverted the clients of SchedulerPosix.WaitProcess to do the re- packing based on the original definitions in Uexec. We need to do a more wholesale check of the clients of Process.Wait and System.Wait to see who 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. I think we can make this much cleaner if we can get rid of the re-packing. I am still concerned that there is needless splitting of the threads files. Perhaps ThreadPWait.m3 and ThreadPScheduler.m3 can be merged. I still don't like either of those names, but we should avoid SchedulerPosix.m3 since ThreadPosix.m3 also exports SchedulerPosix. It would really be much nicer if you could get CygWin to run using PTHREAD instead of the weird WIN32 hybrid. I'm hoping I can get back to more productive pursuits tomorrow... today has been pretty much destroyed as a result of these commits... The productive things are improving concurrency in the garbage collector -- I'd like to be able to do collection in parallel... ;-) On 12 Jan 2009, at 10:20, Antony Hosking wrote: > 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 mika at async.caltech.edu Mon Jan 12 10:34:24 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 12 Jan 2009 01:34:24 -0800 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: Your message of "Mon, 12 Jan 2009 08:47:17 GMT." Message-ID: <200901120934.n0C9YOs8074851@camembert.async.caltech.edu> You present it as a true tragic Dilemma. But isn't there a Third Way---to wit, can't you "Ask the Computer" to do the work for you? Generate the code somehow... Parsing the C headers is an obvious way but there may be others that are simpler, such as writing a Modula-3 program to generate the cloned M3 headers, sorry, interfaces. If I had to do this I would use my Scheme interpreter that's coded in Modula-3 to write a Scheme program to generate the headers. This program could pull whatever tricks are deemed necessary and suitable, down to the point of generating and compiling and running C programs as necessary (or parsing C code, or reading tea leaves). But the end result would be a set of interfaces written in "Pure Modula-3". The process of running the header generator would also have very few dependencies on anything outside the M3 distribution. Mika Jay writes: >--_6117a048-9185-4c03-badb-ef8f93402268_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >This is what you "have to" chose between. >Header cloning or C code (and C headers). >=20 >CONST or VAR (or functions?) >=20 >I'm going to likely make the Uerror change tonight. >You can still veto it (er=2C vote against it :) ) >=20 >Possibly some convuluted C (enum/#undef)=2C or splitting the Modula-3 >at boundaries that weren't previously believed "natural". >(See how SetupHandlers is ~two lines in Modula-3 and the rest in C=3B >this is partly out of ignorance. I don't know how to write those >two lines in C=3B and laziness=2C I didn't look into how). >=20 >=20 >=20 >Remember I'm still staying away from mainstream platforms=2C >so the value isn't what it might appear to be=2C but it is "stage setting"= >=2C >and the show might go on. :) >=20 >=20 >Also=2C the dilemna does get more difficult now=2C with the little C header= > cloning that remains. >=20 >For example=2C look at Upthreads.i3. >Mainly=2C look at function prototypes. >Constants and types are "known problems". >Prototypes are gray. They actually tend to be portable. >=20 >For example: >=20 >TYPE pid_t =3D INTEGER=3B ><*EXTERNAL "m3_getpid*> PROCEDURE getpid():pid_t=3B >=20 >or leave it alone? >getpid is probably the worst example. >It is so very portable declared in Modula-3. >But still=2C imagine pid_t might be 16bits or 32 or 64. >Writing a wrapper is more portable -- as long as the pid isn't stuff into s= >ome record that the system defines. >=20 >=20 >Again=2C Upthreads.i3. >Would you like to see it reduced=2C or left alone? >Only deal with the types and initializers=2C or also the prototypes? >You know=2C I could write a little portable layer=2C where all the types ar= >e pointers=2C always null initialized. >It would buy /some/ portability=2C and cost some. >=20 >=20 >Do you like the sem_t change? Partly? Not at all? >There is one sem_t in the system. So I moved it to be in C code. >Or=2C as I had it before=2C declared as the max size/align of all the platf= >orms -- getting that right is the same work as getting it right "the old wa= >y"=2C except if you make a mistake=2C odds are still good of it being ok. >=20 >=20 >Should the line be drawn at generating the remaining headers=2C rather than= > eliminating them? >Uerror.i3 is easily generated. Good enough? >=20 >Upthread.i3's types can be generated generally as records with opaque array= >s with the right size and alignment. >=20 >Other stuff can be generated or at least checked. >e.g. to check that getpid is declared correctly=2C you can assign it to a f= >unction pointer and see if that compiles. >=20 >Perf on Uerror arguably doesn't matter. >Is it only error handling code?Or do sockets often go down "error" paths=2C= > because they are slow and you are waiting for more data? >=20 >Anyway=2C point is=2C I agree for sure this is valuable=2C but I might be h= >itting the "tail" of the approach and should switch=2C I'm not sure. I keep= > saying that though=2C and then press further. >=20 >=20 > - Jay > > > >From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon=2C 12 Jan 200= >9 19:24:50 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a= > type's existance but not enough to instantiate it? > > >Point taken. We live in a C universe and so need to interact. I do think = >your work with the headers is useful=2C and I want it to continue. Especia= >lly in simplifying ports. > > >On 12 Jan 2009=2C at 19:18=2C Jay wrote: > >I don't think a development system without C headers is interesting.. Is it= > really? The transform I apply at times is wherever there is interaction wi= >th C code that is described by system-dependent headers=2C or perhaps even = >fairly system-independent headers outside the Modula-3 tree=2C either write= > wrapper functions for the functionality in the headers (e.g. stat=2C waitp= >id)=2C which can be done in a system-independent way=2C or move the Modula-= >3<->C transition higher=2C which is also usually system-independent=2C e.g.= > ThreadPThreadC_SetupHandlers. It is either that or clone the headers=2C wh= >ich seems like the worse evil. There is always going to be a Modula-3<->C t= >ransition=2C it is just a matter of where it occurs. - Jay > >CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.e= >duSubject: Re: [M3devel] declaring a type's existance but not enough to ins= >tantiate it?Date: Mon=2C 12 Jan 2009 12:32:15 +1100 > > >Jay=2C I really think you are bending over backwards too far just to be abl= >e to shoe-horn things into C. I *like* having the transpar of C header fil= >es expressed in Modula-3=2C *particularly* for system calls=2C where you mi= >ght even be trying to build on a system that does not have the C header fil= >es installed=2C even though the libraries exist and can be linked to. Fund= >amentally=2C I think anytime the Modula-3 code is made less transparent you= > should think hard about what you are doing. The same with the change of c= >onstants to variables. > >I am getting very nervous that the changes you are making are destroying th= >e clarity of the Modula-3 run-time code. > >In this particular case=2C you are wanting to use a Modula-3 parameter pass= >ing mechanism on something that is not declared in Modula-3. Seems kind of= > dubious to me. Also=2C I really don't like the idea of accessing external= > variables in C. > >-- Tony > >On 12 Jan 2009=2C at 11:55=2C Jay wrote: > >I considered ADDRESS.However I think it still doesn't satisfy. I want to be= > able to do this: TYPE Foo_t =3D something=3B<* EXTERNAL *> VAR Foo1=2C Foo= >2:Foo_t=3B<* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t)= >=3B (* Modula-3=2C not external *)PROCEDURE x()=3DBEGIN UseFoo(Foo1)=3B U= >seFoo(Foo2)=3BEND x=3B AND I want any use of:VAR Foo3:Foo3_t=3B (* Modula-3= >=2C not external *)to error. This is sem_t and sigset_t in particular. Poss= >ibly renaming is the thing.They used to be declared in Modula-3=2C system-d= >ependently=2C butI moved them to portable C. I could remove the types entir= >ely and change UseFoo to take an address=2Cand declare mask and ackSem to b= >e integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END=3B That would sat= >isfy but I thought it might be nicer to still provide the namedtypes to ref= >er to the external variables. - Jay > >From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon=2C 12 Jan 200= >9 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a= > type's existance but not enough to instantiate it?What's wrong with using = >ADDRESS for references to opaque values? If sigset_t is never instantiated= > in Modula-3=2C then why do you need it declared there? > > > >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=2C at 01:44=2C Jay wrote: > >Is there a way in Modula-3 to declare that a type exists=2C and there are <= >*external*> instances of it=2C without "fully" declaring it=2C so that no M= >odula-3 can instantiate it? I have done this for sigset_t and sem_t=2C but = >they could erroneously be instantiated by Modula-3 and I'd like to remove t= >hat ability to mess up so easily. (* This type is not declared correctly. I= >t is only instantiated in C code. *) sigset_t =3D RECORD END=3B(* This typ= >e is not declared correctly. It is only instantiated in C code. *) sem_t = >=3D RECORD END=3BIn C I believe you can do this=2C like: typedef struct fo= >o foo_t=3B extern foo_t foo=3B void UseFoo(foo_t*)=3B foo_t* GetFoo= >(void)=3B Thanks=2C - Jay= > >--_6117a048-9185-4c03-badb-ef8f93402268_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >This is what you "have to" chose between.
>Header cloning or C code (and C headers).
> =3B
>CONST or VAR (or functions?)
> =3B
>I'm going to likely make the Uerror change tonight.
>You can still veto it (er=2C vote against it :) )
> =3B
>Possibly some convuluted C (enum/#undef)=2C or splitting the Modula-3
>at boundaries that weren't previously believed "natural".
>(See how SetupHandlers is ~two lines in Modula-3 and the rest in C=3B
>this is partly out of ignorance. I don't know how to write those
>two lines in C=3B and laziness=2C I didn't look into how).
> =3B
> =3B
> =3B
>Remember I'm still staying away from mainstream platforms=2C
>so the value isn't what it might appear to be=2C but it is "stage setting"= >=2C
>and the show might go on. :)
> =3B
> =3B
>Also=2C the dilemna does get more difficult now=2C with the little C header= > cloning that remains.
> =3B
>For example=2C look at Upthreads.i3.
>Mainly=2C look at function prototypes.
>Constants and types are "known problems".
>Prototypes are gray. They actually tend to be portable.
> =3B
>For example:
> =3B
>TYPE pid_t =3D INTEGER=3B
><=3B*EXTERNAL "m3_getpid*>=3B PROCEDURE getpid():pid_t=3B
> =3B
>or leave it alone?
>getpid is probably the worst example.
>It is so very portable declared in Modula-3.
>But still=2C imagine pid_t might be 16bits or 32 or 64.
>Writing a wrapper is more portable -- as long as the pid isn't stuff into s= >ome record that the system defines.
> =3B
> =3B
>Again=2C Upthreads.i3.
>Would you like to see it reduced=2C or left alone?
>Only deal with the types and initializers=2C or also the prototypes?
>You know=2C I could write a little portable layer=2C where all the types ar= >e pointers=2C always null initialized.
>It would buy /some/ portability=2C and cost some.
> =3B
> =3B
>Do you like the sem_t change? Partly? Not at all?
>There is one sem_t in the system. So I moved it to be in C code.
>Or=2C as I had it before=2C declared as the max size/align of all the platf= >orms -- getting that right is the same work as getting it right "the old wa= >y"=2C except if you make a mistake=2C odds are still good of it being ok.R> > =3B
> =3B
>Should the line be drawn at generating the remaining headers=2C rather than= > eliminating them?
>Uerror.i3 is easily generated. Good enough?
> =3B
>Upthread.i3's types can be generated generally as records with opaque array= >s with the right size and alignment.
> =3B
>Other stuff can be generated or at least checked.
>e.g. to check that getpid is declared correctly=2C you can assign it to a f= >unction pointer and see if that compiles.
> =3B
>Perf on Uerror arguably doesn't matter.
>Is it only error handling code?
Or do sockets often go down "error" path= >s=2C because they are slow and you are waiting for more data?
> =3B
>Anyway=2C point is=2C I agree for sure this is valuable=2C but I might be h= >itting the "tail" of the approach and should switch=2C I'm not sure. I keep= > saying that though=2C and then press further.
> =3B
> =3B
> =3B- Jay

> >

>From: hosking at cs.purdue.edu
To: jay.krell at cornell.edu
Date: Mon=2C 12= > Jan 2009 19:24:50 +1100
CC: m3devel at elegosoft.com
Subject: Re: [M3de= >vel] declaring a type's existance but not enough to instantiate it?

= >
>
12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-IND= >ENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPS= >E: separate"> >
e=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B C= >OLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-S= >PACING: normal=3B BORDER-COLLAPSE: separate">pan style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: n= >one=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B = >LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate">-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRAN= >SFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: no= >rmal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate">EC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B T= >EXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-S= >PACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate">class=3DEC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvet= >ica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B= > WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate= >">x Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT= >: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: = >separate">ONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEX= >T-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-CO= >LLAPSE: separate">0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0= >)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B B= >ORDER-COLLAPSE: separate"> >
Point taken.  =3BWe live in a C universe and so need to interact. = > =3BI do think your work with the headers is useful=2C and I want it to= > continue.  =3BEspecially in simplifying ports.
>

V>
>
>
On 12 Jan 2009=2C at 19:18=2C Jay wrote:

erchange-newline> >
FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B T= >EXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-= >COLLAPSE: separate"> >
>I don't think a development system without C headers is interesting.. Is i= >t really?
 =3B
The transform I apply at times is wherever there i= >s interaction with C code that is described by system-dependent headers=2C = >or perhaps even fairly system-independent headers outside the Modula-3 tree= >=2C either write wrapper functions for the functionality in the headers (e.= >g. stat=2C waitpid)=2C which =3Bcan be done in a system-independent way= >=2C =3Bor move the Modula-3<=3B->=3BC transition higher=2C which is= > also usually system-independent=2C e.g. ThreadPThreadC_SetupHandlers.
&= >nbsp=3B
It is either that or clone the headers=2C which seems like the w= >orse evil.
 =3B
There is always going to be a Modula-3<=3B->= >=3BC transition=2C it is just a matter of where it occurs.
 =3B
&= >nbsp=3B- Jay

>
>
CC: =3Blto:m3devel at elegosoft.com">m3devel at elegosoft.com
From:EC_Apple-converted-space> =3B.edu">hosking at cs.purdue.edu
To:e> =3Bjay.krell at cornell= >.edu
Subject: Re: [M3devel] declaring a type's existance but not eno= >ugh to instantiate it?
Date: Mon=2C 12 Jan 2009 12:32:15 +1100

R>
T: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-= >INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLL= >APSE: separate"> >
tyle=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none= >=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LET= >TER-SPACING: normal=3B BORDER-COLLAPSE: separate">-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRAN= >SFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: no= >rmal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate">EC_EC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica= >=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WH= >ITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate"><= >SPAN class=3DEC_EC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12p= >x Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT= >: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: = >separate">=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)= >=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BO= >RDER-COLLAPSE: separate">-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb= >(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: n= >ormal=3B BORDER-COLLAPSE: separate">yle=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B= > COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER= >-SPACING: normal=3B BORDER-COLLAPSE: separate">yle-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFO= >RM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: norma= >l=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate"> >
Jay=2C I really think you are bending over backwards too far just to b= >e able to shoe-horn things into C.  =3BI *like* having the transpar of = >C header files expressed in Modula-3=2C *particularly* for system calls=2C = >where you might even be trying to build on a system that does not have the = >C header files installed=2C even though the libraries exist and can be link= >ed to.  =3BFundamentally=2C I think anytime the Modula-3 code is made l= >ess transparent you should think hard about what you are doing.  =3BThe= > same with the change of constants to variables.
>

>
I am getting very nervous that the changes you are making are destroyi= >ng the clarity of the Modula-3 run-time code.
>

>
In this particular case=2C you are wanting to use a Modula-3 parameter= > passing mechanism on something that is not declared in Modula-3.  =3BS= >eems kind of dubious to me.  =3BAlso=2C I really don't like the idea of= > accessing external variables in C.
>

>
-- Tony
<= >/DIV>

>
>
On 12 Jan 2009=2C at 11:55=2C Jay wrote:

interchange-newline> >
=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)= >=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BO= >RDER-COLLAPSE: separate"> >
na">I considered ADDRESS.
However I think it still doesn't satisfy.
&= >nbsp=3B
I want to be able to do this:
 =3B
TYPE =3BFoo_t = >=3D something=3B
<=3B* EXTERNAL *>=3B VAR Foo1=2C Foo2:Foo_t=3B
&= >lt=3B* EXTERNAL *>=3B PROCEDURE =3BUseFoo(READONLY (* or VAR *) foo:F= >oo_t)=3B
 =3B
(* Modula-3=2C not external *)
PROCEDURE x()=3D<= >BR>BEGIN
 =3B UseFoo(Foo1)=3B
 =3B UseFoo(Foo2)=3B
END x= >=3B
 =3B
AND I want any use of:
VAR Foo3:Foo3_t=3B (* Modula-3= >=2C not external *)

to error. This is sem_t and sigset_t in particul= >ar.
 =3B
Possibly renaming is the thing.
They used to be decla= >red in Modula-3=2C system-dependently=2C but
I moved them to portable C.= >
 =3B
I could remove the types entirely and change UseFoo to take= > an address=2C
and declare mask and ackSem to be integers or I guess.><=3B*EXTERNAL>=3B VAR ackSem =3B: RECORD END=3B
 =3B
Tha= >t would satisfy but I thought it might be nicer to still provide the named<= >BR>types to refer to the external variables.
 =3B
 =3B- JayR>
>
>
From: =3B=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu
To:ss=3DEC_EC_Apple-converted-space> =3B@cornell.edu">jay.krell at cornell.edu
Date: Mon=2C 12 Jan 2009 11:13:0= >0 +1100
CC: =3Bref=3D"mailto:m3devel at elegosoft.com">m3devel at elegosoft.com
Subject: = >Re: [M3devel] declaring a type's existance but not enough to instantiate it= >?

What's wrong with using ADDRESS for references to opaque values? &= >nbsp=3BIf sigset_t is never instantiated in Modula-3=2C then why do you nee= >d it declared there?
>

>
FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TE= >XT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-C= >OLLAPSE: separate"> >
n style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: non= >e=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LE= >TTER-SPACING: normal=3B BORDER-COLLAPSE: separate">pple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-= >TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE= >: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate">s=3DEC_EC_EC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helv= >etica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px= >=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separ= >ate">FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TE= >XT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-C= >OLLAPSE: separate">ACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0= >=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: nor= >mal=3B BORDER-COLLAPSE: separate">tyle=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none= >=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LET= >TER-SPACING: normal=3B BORDER-COLLAPSE: separate">ple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-T= >RANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE:= > normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate">=3DEC_EC_EC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helve= >tica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px= >=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separ= >ate"> >
EC_EC_EC_Apple-style-span face=3D"Gill Sans">tyle-span style=3D"COLOR: rgb(0=2C0=2C255)=3B FONT-FAMILY: 'Gill Sans'">AN class=3DEC_EC_EC_Apple-style-span style=3D"COLOR: rgb(0=2C0=2C255)=3B FO= >NT-FAMILY: 'Gill Sans'">Antony Hoskingss=3DEC_EC_EC_Apple-style-span face=3D"Gill Sans">ple-style-span style=3D"FONT-FAMILY: 'Gill Sans'">ple-style-span style=3D"FONT-FAMILY: 'Gill Sans'">-converted-space> =3B|= > =3B=3D"FONT-FAMILY: 'Gill Sans'">=3D"FONT-FAMILY: 'Gill Sans'">Associate Professor=3DEC_EC_EC_Apple-style-span style=3D"FONT-FAMILY: 'Gill Sans'">=3DEC_EC_EC_Apple-style-span style=3D"FONT-FAMILY: 'Gill Sans'"> =3B| C= >omputer Science | Purdue University
>
ass=3DEC_EC_EC_Apple-style-span style=3D"FONT-FAMILY: GillSans-Light">305 N= >. University Street | West Lafayette | IN 47907 | USA
>
00ff>5)=3B FONT-FAMILY: 'Gill Sans'">le=3D"COLOR: rgb(0=2C0=2C255)=3B FONT-FAMILY: 'Gill Sans'">OfficePAN>PAN class=3DEC_EC_EC_Apple-style-span style=3D"FONT-FAMILY: GillSans-Light"= >>ht"> =3B+1 765 494 6001 |&nbs= >p=3Be=3D"Gill Sans" color=3D#0000ff>le=3D"COLOR: rgb(0=2C0=2C255)=3B FONT-FAMILY: 'Gill Sans'">_EC_EC_Apple-style-span style=3D"COLOR: rgb(0=2C0=2C255)=3B FONT-FAMILY: 'G= >ill Sans'">Mobilean face=3DGillSans-Light>ONT-FAMILY: GillSans-Light">=3D"FONT-FAMILY: GillSans-Light">= > =3B+1 765 427 5484
>

s=3DEC_EC_EC_khtml-block-placeholder>
AN>
AN>

>
>
On 12 Jan 2009=2C at 01:44=2C Jay wrote:

le-interchange-newline> >
0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0= >)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B B= >ORDER-COLLAPSE: separate"> >
rdana">Is there a way in Modula-3 to declare that =3Ba type exists=2C a= >nd there are <=3B*external*>=3B instances of it=2C without "fully" decl= >aring it=2C so that no Modula-3 can instantiate it?
 =3B
I have d= >one this for sigset_t and sem_t=2C but they could erroneously be instantiat= >ed by Modula-3 and I'd like to remove that ability to mess up so easily.> =3B
(* This type is not declared correctly. It is only instantiate= >d in C code. *)
 =3B sigset_t =3D RECORD END=3B

(* This type = >is not declared correctly. It is only instantiated in C code. *)
 = >=3B sem_t =3D RECORD END=3B

In C I believe you can do this=2C like:<= >BR> =3B =3Btypedef struct foo foo_t=3B =3BC_Apple-converted-space> =3B
 =3B =3Bextern foo_t foo= >=3B =3B =3B
= > =3B
 =3Bvoid UseFoo(foo_t*)=3Berted-space> =3B
 =3B foo_t* GetFoo(void)=3B=3DEC_EC_EC_Apple-converted-space> =3B
 =3B
Thanks=2C<= >BR> =3B- Jay




<= >/DIV>
= >

V>
>= > >--_6117a048-9185-4c03-badb-ef8f93402268_-- From mika at async.caltech.edu Mon Jan 12 10:37:42 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 12 Jan 2009 01:37:42 -0800 Subject: [M3devel] Juno (X) networking problem on AMD64_FREEBSD In-Reply-To: Your message of "Mon, 12 Jan 2009 09:12:44 GMT." Message-ID: <200901120937.n0C9bgR5074988@camembert.async.caltech.edu> netobjd has similar problems. Hmm, yes, in both cases it is somehow related to listening on a port. In your X case it also sounds wrong. It should just check hname[0] against the DISPLAY env var. It doesn't need GetHostAddress. Mika Jay writes: >--_b0c10337-0e1c-414e-aae5-e611dcd4be8a_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >PPC_LINUX not PPC_DARWIN. >I think. >And at one point AMD64_LINUX (same machine as AMD64_FREEBSD=2C multiboot).I= > think I tested I386_OPENBSD Juno too and it worked=2CI don't remember. Oh= >=2C but that was in a VM=2C so different networking setup. >This is Trestle startup=2C seeing if there mightbe shared memory available = >between the X client and server. >If $DISPLAY is set=2C to specify the server=2C it wants to comparethat agai= >nst "current"=2C the client.You know=2C if I set DISPLAY=3D:0.0 or localhos= >t:0.0=2C don't penalize perf=2Cbut if it really is remote=2C then do penali= >ze perf. >/Something/ like that. >I hardly read the code.. > - Jay> To: jay.krell at cornell.edu> Date: Mon=2C 12 Jan 2009 01:06:30 -0800>= > From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3d= >evel] Juno (X) networking problem on AMD64_FREEBSD> > Jay=2C> > I think the= > problem here is actually in the caller. Why does a> caller need "GetHostAd= >dr()"? It is probably doing this for the> purpose of calling listen() or so= >me such thing. What the caller> probably *really* wants is INADDR_ANY=2C an= >d not the IP address of> some arbitrarily chosen interface on the host.> > = >I'm guessing it works on the Mac because the Mac libraries do> something co= >mplicated when you ask for the host's name (i.e.=2C they> somehow generate = >a hostname that always maps to the IP address of> an interface on the compu= >ter).> > Mika> > Jay writes:> >--_b00371fe-730b-4981-9051-a874361296d7_> >C= >ontent-Type: text/plain=3B charset=3D"iso-8859-1"> >Content-Transfer-Encodi= >ng: quoted-printable> >> >> >Do you know the right way?> >=3D20> >PPC_LINUX= > "just worked"=3D2C and I can check Solaris and Darwin.> >=3D20> >I don't w= >ant to edit /etc/hosts -- I use DHCP.> >Though DHCP has been bothering me -= >- only for some of my machines do names =3D> >resolve=3D2C so I end using I= >P addresses=3D2C which change sometimes=3D2C and I l=3D> >oop over them run= >ning ssh to all of them and "see what I get"=3D2C not ideal.> >=3D20> > - J= >ay> To: jay.krell at cornell.edu> Date: Sun=3D2C 11 Jan 2009 08:02:18 -0800>= >=3D> > From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re= >: [M3d=3D> >evel] Juno (X) networking problem on AMD64_FREEBSD> > This is a= > screwy thin=3D> >g in Modula-3. A bug I would call it.> > I've noticed a l= >ot of networking M=3D> >3 programs don't work right unless> the return valu= >e of Unix's "hostname" m=3D> >aps to a real IP address via> gethostbyname. = >I accomplish it in practice by=3D> > adding my hostname> to /etc/hosts.> > = >This is obviously not the right way =3D> >to fix it... > > Mika> > Jay writ= >es:> >--_9e67232c-a064-417d-879e-227a77e31=3D> >0f9_> >Content-Type: text/p= >lain=3D3B charset=3D3D"iso-8859-1"> >Content-Transfe=3D> >r-Encoding: quote= >d-printable> >> >> >Hi. Unix network programming question.=3D> >.> >AMD64_F= >REEBSD:> >$DISPLAY is set to point back to Cygwin host.It works =3D> >for P= >PC_LINUX.> >[jay at fbsdamd64a /cm3/bin]$ ./Juno> >****** runtime error:*=3D> = >>** Exception "IPError.FatalError" not in RAISES li=3D3D> >st*** file "../s= >rc/=3D> >common/IPError.m3"=3D3D2C line 27***> >Abort trap: 6 (core dumped)= >[jay at fbsdam=3D> >d64a /cm3/bin]$> >IP.m3:> >=3D3D20> >PROCEDURE GetHostAddr= >(): Address =3D3D3D V=3D> >AR hname: ARRAY [0..255] OF CHAR=3D3D3B =3D3D> >= > BEGIN LOCK mu DO IF Unix.getho=3D> >stname(ADR(hname[0])=3D3D2C BYTESIZE(h= >na=3D3D> >me)) # 0 THEN IPError.Die ()=3D3D=3D> >3B END=3D3D3B VAR h :=3D3D= >3D Unetdb.g=3D3D> >ethostbyname(ADR(hname[0]))=3D3D3B BEG=3D> >IN IF h =3D3= >D3D NIL THEN IPError.Die()=3D3D> >=3D3D3B END=3D3D3B RETURN GetAddress(=3D>= > >h)=3D3D3B END=3D3D3B END=3D3D3B END GetHos=3D3D> >tAddr=3D3D3B> >PROCEDUR= >E GetAddress=3D> > (ent: Unetdb.struct_hostent_star): Address =3D3D3D VAR u= >a=3D3D> >: Uin.struct_=3D> >in_addr=3D3D3B BEGIN <* ASSERT ent.h_length <= >=3D3D3D BYTESIZE(Addr=3D3D> >ess) *>=3D> > ua :=3D3D3D LOOPHOLE(ent.h_addr_= >list=3D3D2C UNTRACED =3D3D> >REF UNTRACED REF Ui=3D> >n.struct_in_addr)^^= >=3D3D3B RETURN LOOPHOLE(ua.s_addr=3D3D2C A=3D3D> >ddress)=3D3D3B=3D> > END = >GetAddress=3D3D3B> >=3D3D20> >gethostbyname is failing.> >=3D3D20> >Analogo= >u=3D> >s C code also fails:> >=3D3D20> >[jay at fbsdamd64a /cm3/bin]$ cat ~/5.= >c#include=3D> > #include #i=3D3D> >nclude #incl= >ude type=3D> >def struct hostent hostent_t=3D3D3B> >=3D3D20> >int = >main(){ char hostname[200]=3D> >=3D3D3B hostent_t* h=3D3D3B int i=3D3D3B> >= > i =3D3D3D gethostname(hostname=3D3D2C 200=3D> >)=3D3D3B assert(i =3D3D3D= >=3D3D3D 0)=3D3D3B printf("hostna=3D3D> >me: %s\n"=3D3D2C hostn=3D> >ame)=3D= >3D3B h =3D3D3D gethostbyname(hostname)=3D3D3B herror("foo")=3D3D3B=3D3D> > = >pri=3D> >ntf("%p %d %d\n"=3D3D2C h=3D3D2C errno=3D3D2C h_errno)=3D3D3B asse= >rt(h)=3D3D3B return=3D> > 0=3D3D3B}> >=3D3D20> >herror says "unknown host".= >> >Stack is:> > at ../src/run=3D> >time/ex_frame/RTExFrame.m3:58#13 0x00000= >00801a7f2b3 in RTH=3D3D> >ooks__Raise=3D> > (M3_AJWxb1_ex=3D3D3DError acces= >sing memory address 0x8000ffffd278: =3D3D> >Bad=3D> > address.) at ../src/r= >untime/common/RTHooks.m3:79#14 0x000000080169c8=3D3D> >=3D> >d3 in IPError_= >_Die () at ../src/common/IPError.m3:27#15 0x0000000801698a3e =3D> >=3D3D> >= >in IP__GetHostAddr (M3_BCxjPn__result=3D3D3DError accessing memory addr=3D>= > >ess 0x80=3D3D> >00ffffd338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x0= >0000=3D> >008012133d0=3D3D> > in XSharedMem__SameHost (M3_AQuuui_trsl=3D3D3= >DError accessi=3D> >ng memory address 0=3D3D> >x8000ffffd4d8: Bad address.)= > at ../src/xvbt/XShare=3D> >dMem.m3:96#17 0x000000=3D3D> >0801212ab7 in XSh= >aredMem__InitXClient (M3_AQuuu=3D> >i_v=3D3D3DError accessing memory=3D3D> = >> address 0x8000ffffd648: Bad address.) =3D> >at ../src/xvbt/XSharedMem.m3:= >29#1=3D3D> >8 0x0000000801211819 in XExtensions_=3D> >_InitXClient (M3_AQuu= >ui_xclient=3D3D3DError=3D3D> > accessing memory address 0x=3D> >8000ffffd7f= >8: Bad address.) at ../src/xvbt/X=3D3D> >Extensions.m3:14#19 0x000=3D> >000= >08012467a4 in XClientF__Connect (M3_Bd56fi_inst=3D3D> >=3D3D3D0x1879b=3D3D2= >C M=3D> >3_AQuuui_trsl=3D3D3D0x6) at ../src/xvbt/XClientF.m3:583---Typ=3D3D= >> >e =3D> > to continue=3D3D2C or q to quit---(More stack = >frames follow=3D3D> >..=3D> >.)(gdb)> >(* return TRUE if server and client = >are on same host *)PROCEDURE =3D> >SameHost (=3D3D> >trsl: XClient.T): BOOL= >EAN =3D3D3D VAR display :=3D3D3D DisplayH=3D> >=3D3D> >ost(trsl)=3D3D3B dis= >playAddr: IP.Address=3D3D3B BEGIN IF display =3D3D3D NI=3D> >L THE=3D3D> >N= > RETURN TRUE=3D3D3B END=3D3D3B> > TRY IF NOT IP.GetHostByName(displ=3D> >ay= >=3D3D2C displayAddr) THEN RETURN FA=3D3D> >LSE=3D3D3B END=3D3D3B RETURN dis= >playAd=3D> >dr =3D3D3D IP.GetHostAddr()=3D3D3B EXCEPT =3D3D> >| IP.Error = >=3D3D3D> RETURN FALSE=3D> >=3D3D3B END=3D3D3B END SameHost=3D3D3B> >=3D3D20= >> >Thoughts?> >=3D3D20> >Perhaps my n=3D> >etwork isn't setup well=3D3D2C l= >ike I should add the local machine =3D3D> >to /=3D> >etc/hosts.I think this= > can be made to fail gracefully though.It seems l=3D3D>=3D> > >ike it has n= >othing to do with AMD64_FREEBSD=3D3D2C but could have to do wit=3D> >h Fr= >=3D3D> >eeBSD.> >=3D3D20> >Seems like SocketPosix has nearly the exact same= >=3D> > code but appearsmore forgi=3D3D> >ving.. IOError instead of Fatal?> = >>=3D3D20> =3D> >>SocketPosix.m3:> >=3D3D20> >PROCEDURE GetHostAddr (): Addr= >ess RAISES {OSErro=3D> >r.E} =3D3D3D VAR host : AR=3D3D> >RAY [0..255] OF C= >HAR=3D3D3B info : Unetdb.struc=3D> >t_hostent_star=3D3D3B ua : U=3D3D> >in.= >struct_in_addr=3D3D3B BEGIN IF Unix.gethos=3D> >tname (ADR (host[0])=3D3D2C= > BYTESI=3D3D> >ZE (host)) # 0 THEN IOError (Unexpect=3D> >ed)=3D3D3B END=3D= >3D3B> > info :=3D3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3D3B =3D> >IF = >info =3D3D3D NIL TH=3D3D> >EN IOError (Unexpected)=3D3D3B END=3D3D3B <* ASS= >ERT i=3D> >nfo.h_length <=3D3D3D BYTESIZE =3D3D> >(Address) *>> > ua :=3D3D= >3D LOOPHOLE(info.=3D> >h_addr_list=3D3D2C UNTRACED REF UNT=3D3D> >RACED REF= > Uin.struct_in_addr)^^=3D3D3B=3D> > RETURN LOOPHOLE (ua.s_addr=3D3D2C Addre= >ss=3D3D> >)=3D3D3B END GetHostAddr=3D3D3B> =3D> >>=3D3D20> >=3D3D20> >It is= > again disappointing to see such code duplication.> >=3D> >=3D3D20> >=3D3D2= >0> >I guess SameHost can duplicate the logic to predict the err=3D> >or sta= >te and ret=3D3D> >urn false upon error?> >Duplicating the logic for a t=3D>= > >hird time. :(> >=3D3D20> > - Jay=3D3D> >> >--_9e67232c-a064-417d-879e-227= >a77e31=3D> >0f9_> >Content-Type: text/html=3D3B charset=3D3D"iso-8859-1"> >= >Content-Transfer=3D> >-Encoding: quoted-printable> >> >> >> >tyle>> >.hmmessage P> =3D> >>{> >margin:0px=3D3D3B> >padding:0px> >}> >body= >.hmmessage> >{> >font-size: 10=3D> >pt=3D3D3B> >font-family:Verdana> >}> ><= >/style>> >> > >mmessage'>> >Hi. Unix network= > programming question..
> >
AMD64_FREEBS=3D> >D:
> >
$DISPLAY i= >s set to point back to Cygwin host.
It works for =3D> >PPC_LINUX=3D3D> >= >.
> >
[jay at fbsdamd64a /cm3/bin]$ ./Juno
> >
***<=3D> >BR>*** ru= >ntime error:
*** =3D3D3B =3D3D3B =3D3D3B Exception "IPE=3D> = >>=3D3D> >rror.FatalError" not in RAISES list
*** =3D3D3B =3D3D3B= > =3D> >=3D3D3B file "..=3D3D> >/src/common/IPError.m3"=3D3D2C line 27R>***
> >
A=3D> >bort trap: 6 (core dumped)
[jay at fbsdamd64a /cm3/b= >in]$
> >
IP.m3: >R>> > =3D3D3B
> >PROCEDURE GetHostAddr(= >): Address =3D3D3D
 =3D3D3B =3D> >VAR hname: ARRAY [0..255] =3D3D> O= >F CHAR=3D3D3B
 =3D3D3B BEGIN
 =3D3D=3D> >3B =3D3D3B = >=3D3D3B LOCK mu DO
&nbs=3D3D> >p=3D3D3B =3D3D3B =3D3D3B&n=3D> >b= >sp=3D3D3B =3D3D3B IF Unix.gethostname(ADR(hname[0])=3D3D2C B=3D3D> >YTE= >SIZE(hn=3D> >ame)) # 0 THEN
 =3D3D3B =3D3D3B =3D3D3B =3D= >3D3B =3D3D3B =3D> >=3D3D> >=3D3D3B =3D3D3B IPError.Die ()=3D3D3= >B
 =3D3D3B =3D3D3B =3D3D3B=3D> > =3D3D3B =3D3D3B E= >=3D3D> >ND=3D3D3B
 =3D3D3B =3D3D3B =3D3D3B =3D> >=3D3D3B= > =3D3D3B VAR h :=3D3D3D Unetdb.gethost=3D3D> >byname(ADR(hname[0]))=3D3= >D3B=3D> > BEGIN
 =3D3D3B =3D3D3B =3D3D3B =3D3D3B =3D= >3D3B&=3D3D> >nbsp=3D3D3=3D> >B =3D3D3B IF h =3D3D3D NIL THEN IPError.Di= >e()=3D3D3B END=3D3D3B
 =3D3D3B&n=3D> >bsp=3D3D> >=3D3D3B =3D3D3B= > =3D3D3B =3D3D3B =3D3D3B =3D3D3B RETURN Get=3D> >Address(h)= >=3D3D3B
&nbs=3D3D> >p=3D3D3B =3D3D3B =3D3D3B =3D3D3B =3D= >3D3B=3D> > END=3D3D3B
 =3D3D3B =3D3D3B =3D3D3B END=3D3D> >= >=3D3D3B
 =3D3D3B EN=3D> >D GetHostAddr=3D3D3B
> >
PROCEDURE Ge= >tAddress (ent: Unetdb.struct_hoste=3D> >nt_star): Address =3D3D3D
=3D3D>= > > =3D3D3B VAR ua: Uin.struct_in_addr=3D3D3B=3D> >
 =3D3D3B BEGI= >N
 =3D3D3B =3D3D> >=3D3D3B =3D3D3B <=3D3D3B* ASSE=3D> >RT = >ent.h_length <=3D3D3B=3D3D3D BYTESIZE(Address) *>=3D3D3B=3D3D> >
&nb= >sp=3D3D=3D> >3B =3D3D3B =3D3D3B ua :=3D3D3D LOOPHOLE(ent.h_addr_lis= >t=3D3D2C
 =3D3D>=3D> > >=3D3D3B =3D3D3B =3D3D3B =3D3D3B&= >nbsp=3D3D3B =3D3D3B =3D3D3B =3D3D=3D> >3B =3D3D3B =3D3D= >3B=3D3D> > =3D3D3B =3D3D3B =3D3D3B =3D3D3B =3D> >=3D3D3= >B =3D3D3B =3D3D3B =3D3D3B =3D3D3B UN=3D3D> >TRACED REF UNTR= >ACED R=3D> >EF Uin.struct_in_addr)^^=3D3D3B
 =3D3D3B =3D3D3B&nbs= >p=3D3D> >=3D3D3B RETUR=3D> >N LOOPHOLE(ua.s_addr=3D3D2C Address)=3D3D3B
= > =3D3D3B END GetAddress=3D3D3B<=3D> >=3D3D> >BR>> > =3D3D3B
> >g= >ethostbyname is failing.
> >
 =3D3D3B=3D> >
> >Analogous C cod= >e also fails:
> > =3D3D3B
> >
[jay at fbsdamd=3D> >64a /cm3/bin]$= > cat ~/5.c
#include <=3D3D3Bassert.h>=3D3D3B >R>#inc=3D> >lu= >de <=3D3D3Bnetdb.h>=3D3D3B
#include <=3D3D3Bstdio.h>=3D3D3B
#= >includ=3D> >e =3D3D> ><=3D3D3Berrno.h>=3D3D3B
typedef struct hostent= > hostent_t=3D3D3B >>> > =3D3D3B
> >int main()
{
 = >=3D3D3Bchar hostname[200]=3D3D3B >R> =3D3D3Bhostent_t* h=3D3D3B= >=3D3D> >
 =3D3D3Bint i=3D3D3B
> > =3D3D3=3D> >Bi =3D3D3D geth= >ostname(hostname=3D3D2C 200)=3D3D3B
 =3D3D3Bassert(i =3D3D3D=3D3D=3D= >> >3D 0)=3D3D> >=3D3D3B
 =3D3D3Bprintf("hostname: %s\n"=3D3D2C hostn= >ame)=3D3D3B >R> =3D3D3Bh =3D3D3D get=3D3D> >hostbyname(hostname)= >=3D3D3B
 =3D3D3Bherror(=3D> >"foo")=3D3D3B
 =3D3D3Bprintf("%p= > %=3D3D> >d %d\n"=3D3D2C h=3D3D2C errno=3D3D2C h=3D> >_errno)=3D3D3B
&nb= >sp=3D3D3Bassert(h)=3D3D3B
 =3D3D3Bret=3D3D> >urn 0=3D3D3B >R>}= >
> > =3D3D3B
> >herror says "unknown host".
> >
Stack is:<= >=3D> >BR>> > =3D3D3B =3D3D3B =3D3D3B at ../src/runtime/ex_frame= >/RTExFrame.m=3D> >3:58
#13 =3D3D> >0x0000000801a7f2b3 in RTHooks__Raise = >(M3_AJWxb1_ex=3D3D3DEr=3D> >ror accessing memory=3D3D> > ad
dress 0x8000= >ffffd278: Bad address.
) >> =3D3D3B =3D3D3B =3D3D3B = >=3D3D> >at ../src/runtime/common/RTHooks.m3:7=3D> >9
#14 0x000000080169c= >8d3 in IPError=3D3D> >__Die () at ../src/common/IPErr=3D> >or.m3:27
#15 = >0x0000000801698a3e in IP__Ge=3D3D> >tHostAddr (M3_BCxjPn__res=3D> ult=3D3D3= >DError accessing mem
ory address 0x8000fff=3D3D> >fd338: Bad addres=3D> = >>s.
)
 =3D3D3B =3D3D3B =3D3D3B at ../src/POSIX/IP.m3:=3D3= >D> >82 >>#16 0x00000008012133d0 in XSharedMem__SameHost (M3_AQuuui_t= >rsl=3D3D3DErro=3D3D=3D> >> >r accessing m
emory address 0x8000ffffd4d8: = >Bad address.
)
&nbs=3D> >p=3D3D> >=3D3D3B =3D3D3B =3D3D3B at = >../src/xvbt/XSharedMem.m3:96
#17 0x0=3D> >000000801212a=3D3D> >b7 in XSh= >aredMem__InitXClient (M3_AQuuui_v=3D3D3DError acc=3D> >essing m
emory ad= >d=3D3D> >ress 0x8000ffffd648: Bad address.
)
 =3D> >=3D3D3B = >=3D3D3B =3D3D3B at ../sr=3D3D> >c/xvbt/XSharedMem.m3:29
#18 0x00=3D>= > >00000801211819 in XExtensions__InitXClie=3D3D> >nt (M3_AQuuui_xclient=3D3= >D3DErr=3D> >or acce
ssing memory address 0x8000ffffd7f8: =3D3D> >Bad add= >ress.
)
=3D> > =3D3D3B =3D3D3B =3D3D3B at ../src/xvbt/XEx= >tensions.m3=3D3D> >:14
#1=3D> >9 0x00000008012467a4 in XClientF__Connect= > (M3_Bd56fi_inst=3D3D3D0x1879=3D3D> >b=3D> >=3D3D2C
 =3D3D3B =3D= >3D3B =3D3D3B M3_AQuuui_trsl=3D3D3D0x6) at ../src/x=3D> >vbt/XClie=3D3D>= > >ntF.m3:583
---Type <=3D3D3Breturn>=3D3D3B to continue=3D3D2=3D> >C= > or q <=3D3D3Breturn&g=3D3D> >t=3D3D3B to quit---
(More stack frames f= >ollow=3D> >...)
(gdb)
> >
(* return TRUE if server and client are = >on same hos=3D> >t *)
PROCEDURE Sa=3D3D> >meHost (trsl: XClient.T): BOOL= >EAN =3D3D3D
 =3D> >=3D3D3B VAR
 =3D3D3B =3D3D3B&n=3D3D> >= >bsp=3D3D3B display =3D3D3B =3D3D=3D> >3B =3D3D3B =3D3D3B&nb= >sp=3D3D3B =3D3D3B =3D3D3B =3D3D> >=3D3D3B =3D> >=3D3D3B&nbs= >p=3D3D3B =3D3D3B =3D3D3B =3D3D3B =3D3D3B =3D3D3B = >=3D3D3B=3D> :=3D3D3D Di=3D3D> >splayHost(trsl)=3D3D3B
 =3D3D3B = >=3D3D3B =3D3D3B disp=3D> >layAddr: IP.Address=3D3D3B >R> = >=3D3D3B BEGIN
 =3D3D3B =3D3D3B&=3D> >nbsp=3D3D3B IF display =3D3= >D3D NIL THEN RETURN=3D3D> > TRUE=3D3D3B END=3D3D3B
> >&=3D> >nbsp=3D3D3B= > =3D3D3B =3D3D3B TRY
 =3D3D3B =3D3D3B =3D3D3B = >=3D3D=3D> >3B =3D3D3B IF=3D3D> > NOT IP.GetHostByName(display=3D3D2C di= >splayAddr) THEN R=3D> >ETURN FALSE=3D3D3B END=3D3D3B >R> =3D3D3= >B =3D3D3B =3D3D3B =3D3D3B=3D> > =3D3D3B RETURN displayAddr = >=3D3D3D IP.GetHos=3D3D> >tAddr()=3D3D3B
 =3D3D=3D> >3B =3D3D3B&n= >bsp=3D3D3B EXCEPT
 =3D3D3B =3D3D3B =3D3D3B |=3D3D> > IP.=3D>= > >Error =3D3D3D>=3D3D3B RETURN FALSE=3D3D3B
 =3D3D3B =3D3D3B&n= >bsp=3D3D3B END=3D> >=3D3D3B
&=3D3D> >nbsp=3D3D3B END SameHost=3D3D3B
= >> > =3D3D3B
> >Thoughts=3D> >?
> > =3D3D3B
> >
Perhaps = >my network isn't setup well=3D3D2C like =3D> >I should add the local mach= >=3D3D> >ine to /etc/hosts.
I think this can be =3D> >made to fail gracef= >ully though. >R>It seems like it has nothing to do=3D> > with AMD64= >_FREEBSD=3D3D2C but could have t=3D3D> >o do with FreeBSD.
> > >>= > =3D3D3B
> >Seems like SocketPosix has nearly the exact same code bu= >t=3D> > appears
more f=3D3D> >orgiving.. IOError instead of Fatal?
> = >> =3D3D=3D> >3B
> >
SocketPosix.m3:
> > =3D3D3B
> >
= >PROCEDURE GetHostAd=3D> >dr (): Address
 =3D3D3B RAISES {OSError.E} = >=3D3D3D >> =3D3D3B V=3D> >AR
 =3D3D3B =3D3D3B = >=3D3D3B host : ARRAY [0..255] OF CHAR=3D3D3B<=3D3D=3D> >> >BR> =3D3D3B&= >nbsp=3D3D3B =3D3D3B info : Unetdb.struct_hostent_star=3D3D3B=3D> >
&= >nbsp=3D3D> >=3D3D3B =3D3D3B =3D3D3B ua =3D3D3B =3D3D3B : Ui= >n.struc=3D> >t_in_addr=3D3D3B
 =3D3D3B =3D3D> >BEGIN
 =3D3D3B= > =3D3D3B =3D3D3B =3D> >IF Unix.gethostname (ADR (host[0])=3D3D2C BY= >T=3D3D> >ESIZE (host)) # 0 THEN
=3D> > =3D3D3B =3D3D3B =3D3D= >3B =3D3D3B =3D3D3B IOError =3D3D> >(Unexpecte=3D> >d)=3D3D3B
&nb= >sp=3D3D3B =3D3D3B =3D3D3B END=3D3D3B
> > =3D3D3B =3D3D= >=3D> >3B =3D3D3B info :=3D3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3= >D3B<=3D3D> >BR=3D> >> =3D3D3B =3D3D3B =3D3D3B IF info =3D3D3D N= >IL THEN IOError (Unexpected)=3D> >=3D3D3B EN=3D3D> >D=3D3D3B
 =3D3D3= >B =3D3D3B =3D3D3B <=3D3D3B* ASSERT inf=3D> >o.h_length <=3D3D3B= >=3D3D3D BYT=3D3D> >ESIZE (Address) *>=3D3D3B
> > =3D3D3=3D> >B&nbs= >p=3D3D3B =3D3D3B ua :=3D3D3D LOOPHOLE(info.h_addr_list=3D3D2C
 = >=3D3D3=3D> >B&n=3D3D> >bsp=3D3D3B =3D3D3B =3D3D3B =3D3D3B = >=3D3D3B =3D3D3B =3D3D=3D> >3B =3D3D3B =3D3D3B =3D3D> >= >=3D3D3B =3D3D3B =3D3D3B =3D3D3B =3D> >=3D3D3B =3D3D3B&n= >bsp=3D3D3B =3D3D3B UNTRACED REF UN=3D3D> >TRACED REF Uin.str=3D> >uct_i= >n_addr)^^=3D3D3B
 =3D3D3B =3D3D3B =3D3D3B RETURN LOOP=3D3D> = >>HOLE=3D> > (ua.s_addr=3D3D2C Address)=3D3D3B
 =3D3D3B END GetHostAd= >dr=3D3D3B
> >&nb=3D> >sp=3D3D3B
> > =3D3D3B
> >It is again dis= >appointing to see such code d=3D> >uplication.
> > =3D3D3B
> >&nb= >sp=3D3D3B
> >I guess =3D3D3BSameHo=3D> >st can duplicate the logic t= >o predict the error state =3D3D> >and return fals=3D> >e =3D3D3Bupon er= >ror?
> >Duplicating the logic for a third time. :(
=3D> >> > =3D3= >D3B
> >
 =3D3D3B- Jay

> >=3D3D> >> >--=3D> >= >_9e67232c-a064-417d-879e-227a77e310f9_--=3D> >> >--_b00371fe-730b-4981-9051= >-a874361296d7_> >Content-Type: text/html=3B charset=3D"iso-8859-1"> >Conten= >t-Transfer-Encoding: quoted-printable> >> >> >> >> >> >ass=3D3D'hmmessage'>> >Do you know the right way?
> > =3D3B
> >PP= >C_LINUX "just worked"=3D2C and I can check Solaris and Darwin.
> > = >=3D3B
> >I don't want to edit /etc/hosts -- I use DHCP.
> >Though DHC= >P has been bothering me -- only for some of my machines do names =3D> >reso= >lve=3D2C so I end using IP addresses=3D2C which change sometimes=3D2C and I= > l=3D> >oop over them running ssh to all of them and "see what I get"=3D2C = >not ideal.=3D> >
> > =3D3B
> > =3D3B- Jay


>=3D3B= > To: jay.krell at cornell.edu
>=3D3B Date: S=3D> >un=3D2C 11 Jan 2009 08:= >02:18 -0800
>=3D3B From: mika at async.caltech.edu
=3D> >>=3D3B CC: = >m3devel at elegosoft.com
>=3D3B Subject: Re: [M3devel] Juno (X) =3D> >net= >working problem on AMD64_FREEBSD
>=3D3B
>=3D3B This is a screwy = >t=3D> >hing in Modula-3. A bug I would call it.
>=3D3B
>=3D3B I'= >ve noticed =3D> >a lot of networking M3 programs don't work right unless>>=3D3B the retur=3D> >n value of Unix's "hostname" maps to a real IP add= >ress via
>=3D3B gethos=3D> >tbyname. I accomplish it in practice by ad= >ding my hostname
>=3D3B to /et=3D> >c/hosts.
>=3D3B
>=3D3B = >This is obviously not the right way to fix it=3D> >...
>=3D3B
>= >=3D3B Mika
>=3D3B
>=3D3B Jay writes:
>=3D3B &=3D> >gt=3D3B-= >-_9e67232c-a064-417d-879e-227a77e310f9_
>=3D3B >=3D3BContent-Type:= >=3D> > text/plain=3D3B charset=3D3D"iso-8859-1"
>=3D3B >=3D3BContent= >-Transfer-Enco=3D> >ding: quoted-printable
>=3D3B >=3D3B
>=3D3B= > >=3D3B
>=3D3B >=3D3BHi=3D> >. Unix network programming question..= >
>=3D3B >=3D3BAMD64_FREEBSD:
>=3D> >=3D3B >=3D3B$DISPLAY is s= >et to point back to Cygwin host.It works for PPC_LIN=3D> >UX.
>=3D3B &= >gt=3D3B[jay at fbsdamd64a /cm3/bin]$ ./Juno
>=3D3B >=3D3B*****=3D> >* r= >untime error:*** Exception "IPError.FatalError" not in RAISES li=3D3D
&= >=3D> >gt=3D3B >=3D3Bst*** file "../src/common/IPError.m3"=3D3D2C line 27*= >**
>=3D3B=3D> > >=3D3BAbort trap: 6 (core dumped)[jay at fbsdamd64a /cm= >3/bin]$
>=3D3B >=3D> >=3D3BIP.m3:
>=3D3B >=3D3B=3D3D20
>= >=3D3B >=3D3BPROCEDURE GetHostAddr(): Ad=3D> >dress =3D3D3D VAR hname: ARR= >AY [0..255] OF CHAR=3D3D3B =3D3D
>=3D3B >=3D3B BEG=3D> >IN LOCK mu D= >O IF Unix.gethostname(ADR(hname[0])=3D3D2C BYTESIZE(hna=3D3D
>=3D> >= >=3D3B >=3D3Bme)) # 0 THEN IPError.Die ()=3D3D3B END=3D3D3B VAR h :=3D3D3D= > Unetdb.g=3D> >=3D3D
>=3D3B >=3D3Bethostbyname(ADR(hname[0]))=3D3D3B= > BEGIN IF h =3D3D3D NIL T=3D> >HEN IPError.Die()=3D3D
>=3D3B >=3D3B= >=3D3D3B END=3D3D3B RETURN GetAddress(h)=3D3D=3D> >3B END=3D3D3B END=3D3D3B = >END GetHos=3D3D
>=3D3B >=3D3BtAddr=3D3D3B
>=3D3B >=3D> >=3D3B= >PROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Address =3D3D3D VA= >=3D> >R ua=3D3D
>=3D3B >=3D3B: Uin.struct_in_addr=3D3D3B BEGIN <= >=3D3B* ASSERT ent.=3D> >h_length <=3D3B=3D3D3D BYTESIZE(Addr=3D3D
>= >=3D3B >=3D3Bess) *>=3D3B ua :=3D3D3=3D> >D LOOPHOLE(ent.h_addr_list=3D3= >D2C UNTRACED =3D3D
>=3D3B >=3D3BREF UNTRACED R=3D> >EF Uin.struct_in= >_addr)^^=3D3D3B RETURN LOOPHOLE(ua.s_addr=3D3D2C A=3D3D
>=3D3B=3D> > &= >gt=3D3Bddress)=3D3D3B END GetAddress=3D3D3B
>=3D3B >=3D3B=3D3D20
= >>=3D3B >=3D> >=3D3Bgethostbyname is failing.
>=3D3B >=3D3B=3D3D2= >0
>=3D3B >=3D3BAnalogou=3D> >s C code also fails:
>=3D3B >=3D= >3B=3D3D20
>=3D3B >=3D3B[jay at fbsdamd64a =3D> >/cm3/bin]$ cat ~/5.c#in= >clude <=3D3Bassert.h>=3D3B#include <=3D3Bnetdb.h>=3D> >=3D3B#i=3D3D= >
>=3D3B >=3D3Bnclude <=3D3Bstdio.h>=3D3B#include <=3D3Berrno.h= >&g=3D> >t=3D3Btypedef struct hostent hostent_t=3D3D3B
>=3D3B >=3D3B= >=3D3D20
>=3D3B &=3D> >gt=3D3Bint main(){ char hostname[200]=3D3D3B hos= >tent_t* h=3D3D3B int i=3D3D3B
&g=3D> >t=3D3B >=3D3B i =3D3D3D gethostn= >ame(hostname=3D3D2C 200)=3D3D3B assert(i =3D3D3D=3D3D3D=3D> > 0)=3D3D3B pri= >ntf("hostna=3D3D
>=3D3B >=3D3Bme: %s\n"=3D3D2C hostname)=3D3D3B h = >=3D> >=3D3D3D gethostbyname(hostname)=3D3D3B herror("foo")=3D3D3B=3D3D
&= >gt=3D3B >=3D3B p=3D> >rintf("%p %d %d\n"=3D3D2C h=3D3D2C errno=3D3D2C h_e= >rrno)=3D3D3B assert(h)=3D3D3B retu=3D> >rn 0=3D3D3B}
>=3D3B >=3D3B= >=3D3D20
>=3D3B >=3D3Bherror says "unknown host"=3D> >.
>=3D3B &= >gt=3D3BStack is:
>=3D3B >=3D3B at ../src/runtime/ex_frame/RTE=3D> >x= >Frame.m3:58#13 0x0000000801a7f2b3 in RTH=3D3D
>=3D3B >=3D3Books__Rai= >se (M=3D> >3_AJWxb1_ex=3D3D3DError accessing memory address 0x8000ffffd278:= > =3D3D
>=3D> >=3D3B >=3D3BBad address.) at ../src/runtime/common/RTH= >ooks.m3:79#14 0x0000000=3D> >80169c8=3D3D
>=3D3B >=3D3Bd3 in IPError= >__Die () at ../src/common/IPError.m=3D> >3:27#15 0x0000000801698a3e =3D3DR>>=3D3B >=3D3Bin IP__GetHostAddr (M3_BCxjP=3D> >n__result=3D3D3DError = >accessing memory address 0x80=3D3D
>=3D3B >=3D3B00ffff=3D> >d338: Ba= >d address.) at ../src/POSIX/IP.m3:82#16 0x00000008012133d0=3D3D
&g=3D> >= >t=3D3B >=3D3B in XSharedMem__SameHost (M3_AQuuui_trsl=3D3D3DError accessi= >ng mem=3D> >ory address 0=3D3D
>=3D3B >=3D3Bx8000ffffd4d8: Bad addre= >ss.) at ../src/xvb=3D> >t/XSharedMem.m3:96#17 0x000000=3D3D
>=3D3B >= >=3D3B0801212ab7 in XSharedMem_=3D> >_InitXClient (M3_AQuuui_v=3D3D3DError a= >ccessing memory=3D3D
>=3D3B >=3D3B ad=3D> >dress 0x8000ffffd648: Bad= > address.) at ../src/xvbt/XSharedMem.m3:29#1=3D3D >>>=3D3B >=3D3= >B8 0x0000000801211819 in XExtensions__InitXClient (M3_AQuuui_x=3D> >client= >=3D3D3DError=3D3D
>=3D3B >=3D3B accessing memory address 0x8000ffffd= >7f=3D> >8: Bad address.) at ../src/xvbt/X=3D3D
>=3D3B >=3D3BExtensio= >ns.m3:14#19 0x=3D> >00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst= >=3D3D
>=3D3B >=3D3B=3D> >=3D3D3D0x1879b=3D3D2C M3_AQuuui_trsl=3D3D3D= >0x6) at ../src/xvbt/XClientF.m3:583---=3D> >Typ=3D3D
>=3D3B >=3D3Be = ><=3D3Breturn>=3D3B to continue=3D3D2C or q <=3D3Bret=3D> >urn>=3D3B= > to quit---(More stack frames follow=3D3D
>=3D3B >=3D3B...)(gdb)<=3D= >> >BR>>=3D3B >=3D3B(* return TRUE if server and client are on same host= > *)PROC=3D> >EDURE SameHost (=3D3D
>=3D3B >=3D3Btrsl: XClient.T): BO= >OLEAN =3D3D3D VAR dis=3D> >play :=3D3D3D DisplayH=3D3D
>=3D3B >=3D3B= >ost(trsl)=3D3D3B displayAddr: IP.Addr=3D> >ess=3D3D3B BEGIN IF display =3D3= >D3D NIL THE=3D3D
>=3D3B >=3D3BN RETURN TRUE=3D3D=3D> >3B END=3D3D3B<= >BR>>=3D3B >=3D3B TRY IF NOT IP.GetHostByName(display=3D3D2C displ=3D> >= >ayAddr) THEN RETURN FA=3D3D
>=3D3B >=3D3BLSE=3D3D3B END=3D3D3B RETUR= >N displayA=3D> >ddr =3D3D3D IP.GetHostAddr()=3D3D3B EXCEPT =3D3D
>=3D3= >B >=3D3B| IP.Error =3D3D3D=3D> >>=3D3B RETURN FALSE=3D3D3B END=3D3D3B E= >ND SameHost=3D3D3B
>=3D3B >=3D3B=3D3D20 >R>>=3D3B >=3D3BTh= >oughts?
>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3BPerhaps my n=3D> >e= >twork isn't setup well=3D3D2C like I should add the local machine =3D3D
= >>=3D> >=3D3B >=3D3Bto /etc/hosts.I think this can be made to fail grace= >fully though.=3D> >It seems l=3D3D
>=3D3B >=3D3Bike it has nothing t= >o do with AMD64_FREEBSD=3D> >=3D3D2C but could have to do with Fr=3D3D
&= >gt=3D3B >=3D3BeeBSD.
>=3D3B >=3D> >=3D3B=3D3D20
>=3D3B >=3D= >3BSeems like SocketPosix has nearly the exact same c=3D> >ode but appearsmo= >re forgi=3D3D
>=3D3B >=3D3Bving.. IOError instead of Fata=3D> >l?>>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3BSocketPosix.m3:
>=3D3B &= >gt=3D3B=3D> >=3D3D20
>=3D3B >=3D3BPROCEDURE GetHostAddr (): Address = >RAISES {OSError.E} =3D> >=3D3D3D VAR host : AR=3D3D
>=3D3B >=3D3BRAY= > [0..255] OF CHAR=3D3D3B info : Une=3D> >tdb.struct_hostent_star=3D3D3B ua = >: U=3D3D
>=3D3B >=3D3Bin.struct_in_addr=3D3D=3D> >3B BEGIN IF Unix.g= >ethostname (ADR (host[0])=3D3D2C BYTESI=3D3D
>=3D3B >=3D3B=3D> >ZE (= >host)) # 0 THEN IOError (Unexpected)=3D3D3B END=3D3D3B
>=3D3B >=3D3B= > inf=3D> >o :=3D3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3D3B IF info = >=3D3D3D NIL TH=3D3D<=3D> >BR>>=3D3B >=3D3BEN IOError (Unexpected)=3D3D3= >B END=3D3D3B <=3D3B* ASSERT info.h=3D> >_length <=3D3B=3D3D3D BYTESIZE = >=3D3D
>=3D3B >=3D3B(Address) *>=3D3B
>=3D> >=3D3B >=3D3B ua= > :=3D3D3D LOOPHOLE(info.h_addr_list=3D3D2C UNTRACED REF UNT=3D3D
=3D> >&= >gt=3D3B >=3D3BRACED REF Uin.struct_in_addr)^^=3D3D3B RETURN LOOPHOLE (ua.= >s_add=3D> >r=3D3D2C Address=3D3D
>=3D3B >=3D3B)=3D3D3B END GetHostAd= >dr=3D3D3B
>=3D3B >=3D> >=3D3B=3D3D20
>=3D3B >=3D3B=3D3D20
= >>=3D3B >=3D3BIt is again disappointing to=3D> > see such code duplicati= >on.
>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B=3D3D20
=3D> >>=3D= >3B >=3D3BI guess SameHost can duplicate the logic to predict the error = >=3D> >state and ret=3D3D
>=3D3B >=3D3Burn false upon error?
>= >=3D3B >=3D3BDupl=3D> >icating the logic for a third time. :(
>=3D3B = >>=3D3B=3D3D20
>=3D3B >=3D> >=3D3B - Jay=3D3D
>=3D3B >=3D3B<= >BR>>=3D3B >=3D3B--_9e67232c-a064-417d-879e-22=3D> >7a77e310f9_
>= >=3D3B >=3D3BContent-Type: text/html=3D3B charset=3D3D"iso-8859-=3D> >1"R>>=3D3B >=3D3BContent-Transfer-Encoding: quoted-printable
>=3D3B = >&g=3D> >t=3D3B
>=3D3B >=3D3B<=3D3Bhtml>=3D3B
>=3D3B >=3D3= >B<=3D3Bhead>=3D3B
&=3D> >gt=3D3B >=3D3B<=3D3Bstyle>=3D3B
&g= >t=3D3B >=3D3B.hmmessage P
>=3D3B >=3D3B=3D> >{
>=3D3B >=3D3= >Bmargin:0px=3D3D3B
>=3D3B >=3D3Bpadding:0px
>=3D3B >=3D> >=3D= >3B}
>=3D3B >=3D3Bbody.hmmessage
>=3D3B >=3D3B{
>=3D3B &g= >t=3D3Bfont-=3D> >size: 10pt=3D3D3B
>=3D3B >=3D3Bfont-family:Verdana<= >BR>>=3D3B >=3D3B}
&g=3D> >t=3D3B >=3D3B<=3D3B/style>=3D3B
&= >gt=3D3B >=3D3B<=3D3B/head>=3D3B
>=3D3B &=3D> >gt=3D3B<=3D3Bbod= >y class=3D3D3D'hmmessage'>=3D3B
>=3D3B >=3D3BHi. Unix networ=3D> >= >k programming question..<=3D3BBR>=3D3B
>=3D3B >=3D3B<=3D3BBR&g= >t=3D3BAMD64_=3D> >FREEBSD:<=3D3BBR>=3D3B
>=3D3B >=3D3B<=3D3BBR= >>=3D3B$DISPLAY is set to poi=3D> >nt back to Cygwin host.<=3D3BBR>=3D= >3BIt works for PPC_LINUX=3D3D
>=3D3B &g=3D> >t=3D3B.<=3D3BBR>=3D3B= >
>=3D3B >=3D3B<=3D3BBR>=3D3B[jay at fbsdamd64a /cm3/bin]=3D> >$ ./J= >uno<=3D3BBR>=3D3B
>=3D3B >=3D3B<=3D3BBR>=3D3B***<=3D3BBR&g= >t=3D3B*** r=3D> >untime error:<=3D3BBR>=3D3B***&=3D3Bnbsp=3D3D3B&= >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D> >=3D3D3B Exception "IPE=3D3D
>=3D3B = >>=3D3Brror.FatalError" not in RAISES list=3D> ><=3D3BBR>=3D3B***&= >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B file "..=3D> >=3D3= >D
>=3D3B >=3D3B/src/common/IPError.m3"=3D3D2C line 27<=3D3BBR>= >=3D3B***&l=3D> >t=3D3BBR>=3D3B
>=3D3B >=3D3B<=3D3BBR>=3D3BAbor= >t trap: 6 (core dumped)<=3D> >=3D3BBR>=3D3B[jay at fbsdamd64a /cm3/bin]$&l= >t=3D3BBR>=3D3B
>=3D3B >=3D3B<=3D3BB=3D> >R>=3D3BIP.m3:<=3D3B= >BR>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B<=3D> = >>BR>>=3D3B >=3D3BPROCEDURE GetHostAddr(): Address =3D3D3D<=3D3BBR>= >=3D3B&=3D3B=3D> >nbsp=3D3D3B VAR hname: ARRAY [0..255] =3D3D
>=3D3B= > OF CHAR=3D3D3B<=3D3BBR>=3D> >=3D3B&=3D3Bnbsp=3D3D3B BEGIN<=3D3BBR= >>=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D> >=3D3Bnbsp=3D3D3B = >LOCK mu DO<=3D3BBR>=3D3B&=3D3Bnbs=3D3D
>=3D3B >=3D3Bp=3D3D3B&= >a=3D> >mp=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bn= >bsp=3D3D3B IF Unix.geth=3D> >ostname(ADR(hname[0])=3D3D2C B=3D3D
>=3D3= >B >=3D3BYTESIZE(hname)) # 0 THEN<=3D> >=3D3BBR>=3D3B&=3D3Bnbsp=3D3= >D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B=3D> >&= >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D
>=3D3B >=3D3B=3D3D3B&=3D3Bnbsp= >=3D3D3B IPErro=3D> >r.Die ()=3D3D3B<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B&a= >mp=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B=3D> >&=3D3Bnbsp=3D3D3B&=3D3Bnb= >sp=3D3D3B E=3D3D
>=3D3B >=3D3BND=3D3D3B<=3D3BBR>=3D3B=3D> >&= >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3= >B&=3D3Bnbsp=3D> >=3D3D3B VAR h :=3D3D3D Unetdb.gethost=3D3D
>=3D3B = >>=3D3Bbyname(ADR(hname[0]))=3D> >=3D3D3B BEGIN<=3D3BBR>=3D3B&=3D3B= >nbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&a=3D> >mp=3D3Bnbsp=3D3D= >3B&=3D3Bnbsp=3D3D3B&=3D3B=3D3D
>=3D3B >=3D3Bnbsp=3D3D3B&=3D= >3Bnb=3D> >sp=3D3D3B IF h =3D3D3D NIL THEN IPError.Die()=3D3D3B END=3D3D3B&l= >t=3D3BBR>=3D3B&=3D> >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D
>=3D3B &g= >t=3D3B=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D> >=3D3D3B&=3D3Bnbsp=3D= >3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B RETURN GetAddress(h)=3D> >=3D3= >D3B<=3D3BBR>=3D3B&=3D3Bnbs=3D3D
>=3D3B >=3D3Bp=3D3D3B&=3D3= >Bnbsp=3D3D3B&=3D> >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3= >D3B END=3D3D3B<=3D3BBR>=3D3B&=3D3Bn=3D> >bsp=3D3D3B&=3D3Bnbsp=3D3= >D3B&=3D3Bnbsp=3D3D3B END=3D3D
>=3D3B >=3D3B=3D3D3B<=3D3B=3D> >B= >R>=3D3B&=3D3Bnbsp=3D3D3B END GetHostAddr=3D3D3B<=3D3BBR>=3D3B
&= >gt=3D3B >=3D> >=3D3B<=3D3BBR>=3D3BPROCEDURE GetAddress (ent: Unetdb.s= >truct_hostent_star): Ad=3D> >dress =3D3D3D<=3D3BBR>=3D3B=3D3D
>=3D= >3B >=3D3B&=3D3Bnbsp=3D3D3B VAR ua: Uin.s=3D> >truct_in_addr=3D3D3B<= >=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B BEGIN<=3D3BBR>=3D3B&=3D3B=3D> >n= >bsp=3D3D3B&=3D3Bnbsp=3D3D
>=3D3B >=3D3B=3D3D3B&=3D3Bnbsp=3D3D3= >B &=3D3Blt=3D3D3=3D> >B* ASSERT ent.h_length &=3D3Blt=3D3D3B=3D3D3D B= >YTESIZE(Address) *&=3D3Bgt=3D3D3=3D> >B=3D3D
>=3D3B >=3D3B<=3D3= >BBR>=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bn=3D> >bsp=3D3D= >3B ua :=3D3D3D LOOPHOLE(ent.h_addr_list=3D3D2C<=3D3BBR>=3D3B&=3D3Bnb= >sp=3D> >=3D3D
>=3D3B >=3D3B=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp= >=3D3D3B&=3D3Bnbsp=3D3D3B&a=3D> >mp=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&a= >mp=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D> >=3D3D3B&=3D3Bnb= >sp=3D3D3B=3D3D
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B= >&a=3D> >mp=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3B= >nbsp=3D3D3B&=3D3Bnbsp=3D> >=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D= >3B UN=3D3D
>=3D3B >=3D3BTRACED REF UNTR=3D> ACED REF Uin.struct_in_a= >ddr)^^=3D3D3B<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbs=3D> >p=3D3D= >3B&=3D3Bnbsp=3D3D
>=3D3B >=3D3B=3D3D3B RETURN LOOPHOLE(ua.s_addr= >=3D3D2C A=3D> >ddress)=3D3D3B<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B END Get= >Address=3D3D3B<=3D3B=3D3D
=3D> >>=3D3B >=3D3BBR>=3D3B
>=3D3= >B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
>=3D> >=3D3B >=3D3B= >gethostbyname is failing.<=3D3BBR>=3D3B
>=3D3B >=3D3B<=3D3BBR&= >=3D> >gt=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
>=3D3B >=3D3BAna= >logous C code also f=3D> >ails:<=3D3BBR>=3D3B
>=3D3B >=3D3B&= >=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
>=3D> >=3D3B >=3D3B<=3D3BBR>= >=3D3B[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c<=3D3BBR>=3D3B#=3D> >include &= >amp=3D3Blt=3D3D3Bassert.h&=3D3Bgt=3D3D3B<=3D3BB=3D3D
>=3D3B >= >=3D3BR>=3D> >=3D3B#include &=3D3Blt=3D3D3Bnetdb.h&=3D3Bgt=3D3D3B<= >=3D3BBR>=3D3B#include &=3D> >=3D3Blt=3D3D3Bstdio.h&=3D3Bgt=3D3D3B&l= >t=3D3BBR>=3D3B#include =3D3D
>=3D3B >=3D3B&=3D> >amp=3D3Blt=3D3D3B= >errno.h&=3D3Bgt=3D3D3B<=3D3BBR>=3D3Btypedef struct hostent host=3D> = >>ent_t=3D3D3B<=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<= >=3D3BBR>=3D3B
=3D> >>=3D3B >=3D3Bint main()<=3D3BBR>=3D3B{<= >=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3Bchar ho=3D> >stname[200]=3D3D3B<=3D3BB= >R>=3D3B&=3D3Bnbsp=3D3D3Bhostent_t* h=3D3D3B=3D3D
>=3D> >=3D3B >= >=3D3B<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3Bint i=3D3D3B<=3D3BBR>=3D3BR>>=3D3B =3D> >>=3D3B&=3D3Bnbsp=3D3D3Bi =3D3D3D gethostname(hostname= >=3D3D2C 200)=3D3D3B<=3D3BBR&g=3D> >t=3D3B&=3D3Bnbsp=3D3D3Bassert(i =3D= >3D3D=3D3D3D 0)=3D3D
>=3D3B >=3D3B=3D3D3B<=3D3BBR=3D> >>=3D3B&= >=3D3Bnbsp=3D3D3Bprintf("hostname: %s\n"=3D3D2C hostname)=3D3D3B<=3D3BBR&g= >=3D> >t=3D3B&=3D3Bnbsp=3D3D3Bh =3D3D3D get=3D3D
>=3D3B >=3D3Bhost= >byname(hostname)=3D3D3=3D> >B<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3Bherror("= >foo")=3D3D3B<=3D3BBR>=3D3B&=3D3Bnbsp=3D> >=3D3D3Bprintf("%p %=3D3DR>>=3D3B >=3D3Bd %d\n"=3D3D2C h=3D3D2C errno=3D3D2C h_errno=3D> >)=3D3D= >3B<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3Bassert(h)=3D3D3B<=3D3BBR>=3D3B&= >amp=3D3Bnbsp=3D> >=3D3D3Bret=3D3D
>=3D3B >=3D3Burn 0=3D3D3B<=3D3BB= >R>=3D3B}<=3D3BBR>=3D3B
>=3D> >=3D3B >=3D3B&=3D3Bnbsp=3D3D3B= ><=3D3BBR>=3D3B
>=3D3B >=3D3Bherror says "unkno=3D> >wn host".<= >=3D3BBR>=3D3B
>=3D3B >=3D3B<=3D3BBR>=3D3BStack is:<=3D3BBR&g= >t=3D> >=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&a= >mp=3D3Bnbsp=3D3D3B at ../=3D> >src/runtime/ex_frame/RTExFrame.m3:58<=3D3B= >BR>=3D3B#13 =3D3D
>=3D3B >=3D3B0=3D> >x0000000801a7f2b3 in RTHooks= >__Raise (M3_AJWxb1_ex=3D3D3DError accessing memor=3D> >y=3D3D
>=3D3B &= >gt=3D3B ad<=3D3BBR>=3D3Bdress 0x8000ffffd278: Bad address.<=3D> >=3D3= >BBR>=3D3B)<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&= >=3D3Bnbsp=3D3D3B =3D> >=3D3D
>=3D3B >=3D3Bat ../src/runtime/common/R= >THooks.m3:79<=3D3BBR>=3D3B#14=3D> > 0x000000080169c8d3 in IPError=3D3D<= >BR>>=3D3B >=3D3B__Die () at ../src/common=3D> >/IPError.m3:27<=3D3BBR= >>=3D3B#15 0x0000000801698a3e in IP__Ge=3D3D
>=3D3B &=3D> >gt=3D3BtHo= >stAddr (M3_BCxjPn__result=3D3D3DError accessing mem<=3D3BBR>=3D3Bory = >=3D> >address 0x8000fff=3D3D
>=3D3B >=3D3Bfd338: Bad address.<=3D3= >BBR>=3D3B)<=3D> >=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3= >B&=3D3Bnbsp=3D3D3B at ../src/POSIX=3D> >/IP.m3:=3D3D
>=3D3B >=3D3= >B82<=3D3BBR>=3D3B#16 0x00000008012133d0 in XShare=3D> >dMem__SameHost (= >M3_AQuuui_trsl=3D3D3DErro=3D3D
>=3D3B >=3D3Br accessing m<=3D> >= >=3D3BBR>=3D3Bemory address 0x8000ffffd4d8: Bad address.<=3D3BBR>=3D3B= >)<=3D3BB=3D> >R>=3D3B&=3D3Bnbsp=3D3D
>=3D3B >=3D3B=3D3D3B&= >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B=3D> > at ../src/xvbt/XSharedMem.m3:96&= >lt=3D3BBR>=3D3B#17 0x0000000801212a=3D3D
&g=3D> >t=3D3B >=3D3Bb7 in = >XSharedMem__InitXClient (M3_AQuuui_v=3D3D3DError accessing m=3D> ><=3D3BB= >R>=3D3Bemory add=3D3D
>=3D3B >=3D3Bress 0x8000ffffd648: Bad addres= >s=3D> >.<=3D3BBR>=3D3B)<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bn= >bsp=3D3D3B&=3D3Bnbsp=3D> >=3D3D3B at ../sr=3D3D
>=3D3B >=3D3Bc/xv= >bt/XSharedMem.m3:29<=3D3BBR>=3D3B#18 =3D> >0x0000000801211819 in XExten= >sions__InitXClie=3D3D
>=3D3B >=3D3Bnt (M3_AQuu=3D> >ui_xclient=3D3D3= >DError acce<=3D3BBR>=3D3Bssing memory address 0x8000ffffd7f8:=3D> > =3D= >3D
>=3D3B >=3D3BBad address.<=3D3BBR>=3D3B)<=3D3BBR>=3D3B&am= >p=3D3Bnbsp=3D> >=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B at ../src/x= >vbt/XExtensions.m3=3D3D
&=3D> >gt=3D3B >=3D3B:14<=3D3BBR>=3D3B#19 = >0x00000008012467a4 in XClientF__Connect (M=3D> >3_Bd56fi_inst=3D3D3D0x1879= >=3D3D
>=3D3B >=3D3Bb=3D3D2C<=3D3BBR>=3D3B&=3D3Bnbsp=3D> >=3D3= >D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B M3_AQuuui_trsl=3D3D3D0x6) at ..= >/src/xvb=3D> >t/XClie=3D3D
>=3D3B >=3D3BntF.m3:583<=3D3BBR>=3D3B= >---Type &=3D3Blt=3D3D3Bre=3D> >turn&=3D3Bgt=3D3D3B to continue=3D3D2C= > or q &=3D3Blt=3D3D3Breturn&=3D3Bg=3D3D >>>=3D3B >=3D3Bt= >=3D3D3B to quit---<=3D3BBR>=3D3B(More stack frames follow...)&=3D> >lt= >=3D3BBR>=3D3B(gdb)<=3D3BBR>=3D3B
>=3D3B >=3D3B<=3D3BBR>=3D= >3B(* return TR=3D> >UE if server and client are on same host *)<=3D3BBR&g= >t=3D3BPROCEDURE Sa=3D3D >>>=3D3B >=3D3BmeHost (trsl: XClient.T):= > BOOLEAN =3D3D3D<=3D3BBR>=3D3B&=3D3Bn=3D> >bsp=3D3D3B VAR<=3D3BBR&= >gt=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bn=3D3D
&g=3D> >t= >=3D3B >=3D3Bbsp=3D3D3B display&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&am= >p=3D3Bnbsp=3D3D3B=3D> >&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbs= >p=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D> >=3D3D
>=3D3B >=3D3B= >=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&a=3D> >= >mp=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3= >D3B&=3D3Bnbsp=3D> >=3D3D3B :=3D3D3D Di=3D3D
>=3D3B >=3D3BsplayHos= >t(trsl)=3D3D3B<=3D3BBR>=3D3B&=3D> >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3= >D3B&=3D3Bnbsp=3D3D3B displayAddr: IP.Address=3D3D3B&l=3D> >t=3D3BB=3D3D<= >BR>>=3D3B >=3D3BR>=3D3B&=3D3Bnbsp=3D3D3B BEGIN<=3D3BBR>=3D3B&a= >mp=3D3B=3D> >nbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B IF display= > =3D3D3D NIL THEN RETURN=3D> >=3D3D
>=3D3B >=3D3B TRUE=3D3D3B END=3D= >3D3B<=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D> >=3D3Bnbsp=3D3D3B&= >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B TRY<=3D3BBR>=3D3B&=3D3Bnbsp=3D>= > >=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&= >=3D3Bnbsp=3D3D3B IF=3D3D=3D> >
>=3D3B >=3D3B NOT IP.GetHostByName(di= >splay=3D3D2C displayAddr) THEN RETUR=3D> >N FALSE=3D3D3B END=3D3D3B<=3D3B= >B=3D3D
>=3D3B >=3D3BR>=3D3B&=3D3Bnbsp=3D3D3B&=3D> >=3D3Bnbsp= >=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B RETURN = >display=3D> >Addr =3D3D3D IP.GetHos=3D3D
>=3D3B >=3D3BtAddr()=3D3D3B= ><=3D3BBR>=3D3B&=3D3Bnb=3D> >sp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnb= >sp=3D3D3B EXCEPT<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3=3D> >B&=3D3Bnbsp= >=3D3D3B&=3D3Bnbsp=3D3D3B |=3D3D
>=3D3B >=3D3B IP.Error =3D3D3D&am= >p=3D> >=3D3Bgt=3D3D3B RETURN FALSE=3D3D3B<=3D3BBR>=3D3B&=3D3Bnbsp=3D= >3D3B&=3D3Bnbsp=3D3D3B&=3D> >amp=3D3Bnbsp=3D3D3B END=3D3D3B<=3D3BBR>= >=3D3B&=3D3B=3D3D
>=3D3B >=3D3Bnbsp=3D3D3B =3D> >END SameHost=3D3D= >3B<=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>= >=3D> >=3D3B
>=3D3B >=3D3BThoughts?<=3D3BBR>=3D3B
>=3D3B >= >=3D3B&=3D3Bnbsp=3D3D3=3D> >B<=3D3BBR>=3D3B
>=3D3B >=3D3B<= >=3D3BBR>=3D3BPerhaps my network isn't setu=3D> >p well=3D3D2C like I shou= >ld add the local mach=3D3D
>=3D3B >=3D3Bine to /etc=3D> >/hosts.<= >=3D3BBR>=3D3BI think this can be made to fail gracefully though.<=3D> >= >=3D3BB=3D3D
>=3D3B >=3D3BR>=3D3BIt seems like it has nothing to do= > with AMD6=3D> >4_FREEBSD=3D3D2C but could have t=3D3D
>=3D3B >=3D3B= >o do with FreeBSD.<=3D3B=3D> >BR>=3D3B
>=3D3B >=3D3B<=3D3BBR&g= >t=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
&g=3D> >t=3D3B >=3D3BSeem= >s like SocketPosix has nearly the exact same code but appear=3D> >s<=3D3B= >BR>=3D3Bmore f=3D3D
>=3D3B >=3D3Borgiving.. IOError instead of Fat= >a=3D> >l?<=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3= >BBR>=3D3B
>=3D3B &=3D> >gt=3D3B<=3D3BBR>=3D3BSocketPosix.m3:<= >=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D3Bnbs=3D> >p=3D3D3B<=3D3BBR>= >=3D3B
>=3D3B >=3D3B<=3D3BBR>=3D3BPROCEDURE GetHostAddr ()=3D> >:= > Address<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B RAISES {OSError.E} =3D3D3D&l= >t=3D3BBR=3D3D=3D> >
>=3D3B >=3D3B>=3D3B&=3D3Bnbsp=3D3D3B VAR<= >=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B&a=3D> >mp=3D3Bnbsp=3D3D3B&=3D3Bnbsp= >=3D3D3B host : ARRAY [0..255] OF CHAR=3D3D3B<=3D3B=3D3D<=3D> >BR>>=3D3B= > >=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D= >3D3B in=3D> >fo : Unetdb.struct_hostent_star=3D3D3B<=3D3BBR>=3D3B&= >=3D3Bnbsp=3D3D
>=3D3B =3D> >>=3D3B=3D3D3B&=3D3Bnbsp=3D3D3B&=3D= >3Bnbsp=3D3D3B ua&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D> >=3D3D3B : Uin.struct= >_in_addr=3D3D3B<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B =3D3D
>=3D3B=3D>= > > >=3D3BBEGIN<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&= >amp=3D3Bnbsp=3D3D3B =3D> >IF Unix.gethostname (ADR (host[0])=3D3D2C BYT=3D3= >D
>=3D3B >=3D3BESIZE (host)=3D> >) # 0 THEN<=3D3BBR>=3D3B&=3D= >3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&am=3D> >p=3D3Bnbsp=3D= >3D3B&=3D3Bnbsp=3D3D3B IOError =3D3D
>=3D3B >=3D3B(Unexpected)=3D3= >D3B=3D> ><=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3= >Bnbsp=3D3D3B END=3D3D3B<=3D> >=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D= >3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3=3D> >B info :=3D3D3D U= >netdb.gethostbyname (ADR (host[0]))=3D3D3B<=3D3B=3D3D
>=3D3B =3D> >&= >gt=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D= >3B IF info =3D3D3=3D> >D NIL THEN IOError (Unexpected)=3D3D3B EN=3D3D
&g= >t=3D3B >=3D3BD=3D3D3B<=3D3BBR&g=3D> >t=3D3B&=3D3Bnbsp=3D3D3B&=3D3= >Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B &=3D3Blt=3D3D3B* ASSERT=3D> > info.h_le= >ngth &=3D3Blt=3D3D3B=3D3D3D BYT=3D3D
>=3D3B >=3D3BESIZE (Address)= > *=3D> >&=3D3Bgt=3D3D3B<=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D3Bn= >bsp=3D3D3B&=3D3Bnbsp=3D3D=3D> >3B&=3D3Bnbsp=3D3D3B ua :=3D3D3D LOOPHO= >LE(info.h_addr_list=3D3D2C<=3D3BBR>=3D3B&a=3D> >mp=3D3Bnbsp=3D3D3B&= >=3D3Bn=3D3D
>=3D3B >=3D3Bbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnb= >=3D> >sp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B= >&=3D3Bnbsp=3D3D3B&=3D> >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3B= >nbsp=3D3D
>=3D3B >=3D3B=3D3D3B&=3D3Bnbsp=3D> >=3D3D3B&=3D3Bnbs= >p=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D= >> >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B UNTRACED REF UN=3D3D
>=3D3B &g= >t=3D3BTRACED REF =3D> >Uin.struct_in_addr)^^=3D3D3B<=3D3BBR>=3D3B&= >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&am=3D> >p=3D3Bnbsp=3D3D3B RETURN LOOP= >=3D3D
>=3D3B >=3D3BHOLE (ua.s_addr=3D3D2C Address)=3D> >=3D3D3B<= >=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B END GetHostAddr=3D3D3B<=3D3BBR>=3D3= >B
&=3D> >gt=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
>= >=3D3B >=3D3B&=3D3Bnbsp=3D3D3B=3D> ><=3D3BBR>=3D3B
>=3D3B >= >=3D3BIt is again disappointing to see such code d=3D> >uplication.<=3D3BB= >R>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B= > >>>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
>=3D3B >= >=3D3BI guess&=3D3B=3D> >nbsp=3D3D3BSameHost can duplicate the logic to p= >redict the error state =3D3D >>>=3D3B >=3D3Band return false&= >=3D3Bnbsp=3D3D3Bupon error?<=3D3BBR>=3D3B
=3D> >>=3D3B >=3D3BDup= >licating the logic for a third time. :(<=3D3BBR>=3D3B
&g=3D> >t=3D3B= > >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
>=3D3B >=3D3B<=3D3= >BBR>=3D3B&am=3D> >p=3D3Bnbsp=3D3D3B- Jay<=3D3BBR>=3D3B<=3D3BBR>= >=3D3B<=3D3B/body>=3D3B
>=3D3B &=3D> >gt=3D3B<=3D3B/html>=3D3B= >=3D3D
>=3D3B >=3D3B
>=3D3B >=3D3B--_9e67232c-a064=3D> >-417d-= >879e-227a77e310f9_--

> >=3D> >> >--_b00371fe-730b-4981= >-9051-a874361296d7_--= > >--_b0c10337-0e1c-414e-aae5-e611dcd4be8a_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >PPC_LINUX not PPC_DARWIN.
>I think.
>And at one point AMD64_LINUX (same machine as AMD64_FREEBSD=2C multiboot).<= >BR>I think I tested I386_OPENBSD Juno too and it worked=2C
I don't remem= >ber. Oh=2C but that was in a VM=2C so different networking setup.
>
This is Trestle startup=2C seeing if there might
be shared memory av= >ailable between the X client and server.
>
If $DISPLAY is set=2C to specify the server=2C it wants to compare
t= >hat against "current"=2C the client.
You know=2C if I set DISPLAY=3D:0.0= > or localhost:0.0=2C don't penalize perf=2C
but if it really is remote= >=2C then do penalize perf.
>
/Something/ like that.
>I hardly read the code..
>
 =3B- Jay

>=3B To: jay.krell at cornell.edu
>=3B Date: M= >on=2C 12 Jan 2009 01:06:30 -0800
>=3B From: mika at async.caltech.edu
= >>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] Juno (X) = >networking problem on AMD64_FREEBSD
>=3B
>=3B Jay=2C
>=3B <= >BR>>=3B I think the problem here is actually in the caller. Why does a>>=3B caller need "GetHostAddr()"? It is probably doing this for the
&= >gt=3B purpose of calling listen() or some such thing. What the caller
&g= >t=3B probably *really* wants is INADDR_ANY=2C and not the IP address of
= >>=3B some arbitrarily chosen interface on the host.
>=3B
>=3B = >I'm guessing it works on the Mac because the Mac libraries do
>=3B som= >ething complicated when you ask for the host's name (i.e.=2C they
>=3B= > somehow generate a hostname that always maps to the IP address of
>= >=3B an interface on the computer).
>=3B
>=3B Mika
>=3B
= >>=3B Jay writes:
>=3B >=3B--_b00371fe-730b-4981-9051-a874361296d7_= >
>=3B >=3BContent-Type: text/plain=3B charset=3D"iso-8859-1"
>= >=3B >=3BContent-Transfer-Encoding: quoted-printable
>=3B >=3B
&= >gt=3B >=3B
>=3B >=3BDo you know the right way?
>=3B >=3B=3D= >20
>=3B >=3BPPC_LINUX "just worked"=3D2C and I can check Solaris and= > Darwin.
>=3B >=3B=3D20
>=3B >=3BI don't want to edit /etc/ho= >sts -- I use DHCP.
>=3B >=3BThough DHCP has been bothering me -- onl= >y for some of my machines do names =3D
>=3B >=3Bresolve=3D2C so I en= >d using IP addresses=3D2C which change sometimes=3D2C and I l=3D
>=3B = >>=3Boop over them running ssh to all of them and "see what I get"=3D2C no= >t ideal.
>=3B >=3B=3D20
>=3B >=3B - Jay>=3B To: jay.krell at c= >ornell.edu>=3B Date: Sun=3D2C 11 Jan 2009 08:02:18 -0800>=3B=3D
>= >=3B >=3B From: mika at async.caltech.edu>=3B CC: m3devel at elegosoft.com>= >=3B Subject: Re: [M3d=3D
>=3B >=3Bevel] Juno (X) networking problem = >on AMD64_FREEBSD>=3B >=3B This is a screwy thin=3D
>=3B >=3Bg in= > Modula-3. A bug I would call it.>=3B >=3B I've noticed a lot of networ= >king M=3D
>=3B >=3B3 programs don't work right unless>=3B the retu= >rn value of Unix's "hostname" m=3D
>=3B >=3Baps to a real IP address= > via>=3B gethostbyname. I accomplish it in practice by=3D
>=3B >= >=3B adding my hostname>=3B to /etc/hosts.>=3B >=3B This is obviously = >not the right way =3D
>=3B >=3Bto fix it... >=3B >=3B Mika>=3B= > >=3B Jay writes:>=3B >=3B--_9e67232c-a064-417d-879e-227a77e31=3D
= >>=3B >=3B0f9_>=3B >=3BContent-Type: text/plain=3D3B charset=3D3D"is= >o-8859-1">=3B >=3BContent-Transfe=3D
>=3B >=3Br-Encoding: quoted= >-printable>=3B >=3B>=3B >=3B>=3B >=3BHi. Unix network programmi= >ng question.=3D
>=3B >=3B.>=3B >=3BAMD64_FREEBSD:>=3B >=3B$D= >ISPLAY is set to point back to Cygwin host.It works =3D
>=3B >=3Bfor= > PPC_LINUX.>=3B >=3B[jay at fbsdamd64a /cm3/bin]$ ./Juno>=3B >=3B*****= >* runtime error:*=3D
>=3B >=3B** Exception "IPError.FatalError" not = >in RAISES li=3D3D>=3B >=3Bst*** file "../src/=3D
>=3B >=3Bcommon= >/IPError.m3"=3D3D2C line 27***>=3B >=3BAbort trap: 6 (core dumped)[jay@= >fbsdam=3D
>=3B >=3Bd64a /cm3/bin]$>=3B >=3BIP.m3:>=3B >=3B= >=3D3D20>=3B >=3BPROCEDURE GetHostAddr(): Address =3D3D3D V=3D
>=3B= > >=3BAR hname: ARRAY [0..255] OF CHAR=3D3D3B =3D3D>=3B >=3B BEGIN LOC= >K mu DO IF Unix.getho=3D
>=3B >=3Bstname(ADR(hname[0])=3D3D2C BYTESI= >ZE(hna=3D3D>=3B >=3Bme)) # 0 THEN IPError.Die ()=3D3D=3D
>=3B >= >=3B3B END=3D3D3B VAR h :=3D3D3D Unetdb.g=3D3D>=3B >=3Bethostbyname(ADR(= >hname[0]))=3D3D3B BEG=3D
>=3B >=3BIN IF h =3D3D3D NIL THEN IPError.D= >ie()=3D3D>=3B >=3B=3D3D3B END=3D3D3B RETURN GetAddress(=3D
>=3B &g= >t=3Bh)=3D3D3B END=3D3D3B END=3D3D3B END GetHos=3D3D>=3B >=3BtAddr=3D3D3= >B>=3B >=3BPROCEDURE GetAddress=3D
>=3B >=3B (ent: Unetdb.struct_= >hostent_star): Address =3D3D3D VAR ua=3D3D>=3B >=3B: Uin.struct_=3D
= >>=3B >=3Bin_addr=3D3D3B BEGIN <=3B* ASSERT ent.h_length <=3B=3D3D3D= > BYTESIZE(Addr=3D3D>=3B >=3Bess) *>=3B=3D
>=3B >=3B ua :=3D3D3= >D LOOPHOLE(ent.h_addr_list=3D3D2C UNTRACED =3D3D>=3B >=3BREF UNTRACED R= >EF Ui=3D
>=3B >=3Bn.struct_in_addr)^^=3D3D3B RETURN LOOPHOLE(ua.s_ad= >dr=3D3D2C A=3D3D>=3B >=3Bddress)=3D3D3B=3D
>=3B >=3B END GetAddr= >ess=3D3D3B>=3B >=3B=3D3D20>=3B >=3Bgethostbyname is failing.>=3B = >>=3B=3D3D20>=3B >=3BAnalogou=3D
>=3B >=3Bs C code also fails:&= >gt=3B >=3B=3D3D20>=3B >=3B[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c#includ= >e=3D
>=3B >=3B <=3Bassert.h>=3B#include <=3Bnetdb.h>=3B#i=3D= >3D>=3B >=3Bnclude <=3Bstdio.h>=3B#include <=3Berrno.h>=3Btype= >=3D
>=3B >=3Bdef struct hostent hostent_t=3D3D3B>=3B >=3B=3D3D20= >>=3B >=3Bint main(){ char hostname[200]=3D
>=3B >=3B=3D3D3B host= >ent_t* h=3D3D3B int i=3D3D3B>=3B >=3B i =3D3D3D gethostname(hostname=3D= >3D2C 200=3D
>=3B >=3B)=3D3D3B assert(i =3D3D3D=3D3D3D 0)=3D3D3B prin= >tf("hostna=3D3D>=3B >=3Bme: %s\n"=3D3D2C hostn=3D
>=3B >=3Bame)= >=3D3D3B h =3D3D3D gethostbyname(hostname)=3D3D3B herror("foo")=3D3D3B=3D3D&= >gt=3B >=3B pri=3D
>=3B >=3Bntf("%p %d %d\n"=3D3D2C h=3D3D2C errno= >=3D3D2C h_errno)=3D3D3B assert(h)=3D3D3B return=3D
>=3B >=3B 0=3D3D3= >B}>=3B >=3B=3D3D20>=3B >=3Bherror says "unknown host".>=3B >=3B= >Stack is:>=3B >=3B at ../src/run=3D
>=3B >=3Btime/ex_frame/RTExF= >rame.m3:58#13 0x0000000801a7f2b3 in RTH=3D3D>=3B >=3Books__Raise=3D
= >>=3B >=3B (M3_AJWxb1_ex=3D3D3DError accessing memory address 0x8000ffff= >d278: =3D3D>=3B >=3BBad=3D
>=3B >=3B address.) at ../src/runtime= >/common/RTHooks.m3:79#14 0x000000080169c8=3D3D>=3B >=3B=3D
>=3B &g= >t=3Bd3 in IPError__Die () at ../src/common/IPError.m3:27#15 0x0000000801698= >a3e =3D
>=3B >=3B=3D3D>=3B >=3Bin IP__GetHostAddr (M3_BCxjPn__re= >sult=3D3D3DError accessing memory addr=3D
>=3B >=3Bess 0x80=3D3D>= >=3B >=3B00ffffd338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x00000=3D<= >BR>>=3B >=3B008012133d0=3D3D>=3B >=3B in XSharedMem__SameHost (M3_A= >Quuui_trsl=3D3D3DError accessi=3D
>=3B >=3Bng memory address 0=3D3D&= >gt=3B >=3Bx8000ffffd4d8: Bad address.) at ../src/xvbt/XShare=3D
>=3B= > >=3BdMem.m3:96#17 0x000000=3D3D>=3B >=3B0801212ab7 in XSharedMem__In= >itXClient (M3_AQuuu=3D
>=3B >=3Bi_v=3D3D3DError accessing memory=3D3= >D>=3B >=3B address 0x8000ffffd648: Bad address.) =3D
>=3B >=3Bat= > ../src/xvbt/XSharedMem.m3:29#1=3D3D>=3B >=3B8 0x0000000801211819 in XE= >xtensions_=3D
>=3B >=3B_InitXClient (M3_AQuuui_xclient=3D3D3DError= >=3D3D>=3B >=3B accessing memory address 0x=3D
>=3B >=3B8000ffffd= >7f8: Bad address.) at ../src/xvbt/X=3D3D>=3B >=3BExtensions.m3:14#19 0x= >000=3D
>=3B >=3B00008012467a4 in XClientF__Connect (M3_Bd56fi_inst= >=3D3D>=3B >=3B=3D3D3D0x1879b=3D3D2C M=3D
>=3B >=3B3_AQuuui_trsl= >=3D3D3D0x6) at ../src/xvbt/XClientF.m3:583---Typ=3D3D>=3B >=3Be <=3Br= >eturn>=3B=3D
>=3B >=3B to continue=3D3D2C or q <=3Breturn>=3B = >to quit---(More stack frames follow=3D3D>=3B >=3B..=3D
>=3B >=3B= >.)(gdb)>=3B >=3B(* return TRUE if server and client are on same host *)= >PROCEDURE =3D
>=3B >=3BSameHost (=3D3D>=3B >=3Btrsl: XClient.T):= > BOOLEAN =3D3D3D VAR display :=3D3D3D DisplayH=3D
>=3B >=3B=3D3D>= >=3B >=3Bost(trsl)=3D3D3B displayAddr: IP.Address=3D3D3B BEGIN IF display = >=3D3D3D NI=3D
>=3B >=3BL THE=3D3D>=3B >=3BN RETURN TRUE=3D3D3B E= >ND=3D3D3B>=3B >=3B TRY IF NOT IP.GetHostByName(displ=3D
>=3B >= >=3Bay=3D3D2C displayAddr) THEN RETURN FA=3D3D>=3B >=3BLSE=3D3D3B END=3D= >3D3B RETURN displayAd=3D
>=3B >=3Bdr =3D3D3D IP.GetHostAddr()=3D3D3B= > EXCEPT =3D3D>=3B >=3B| IP.Error =3D3D3D>=3B RETURN FALSE=3D
>= >=3B >=3B=3D3D3B END=3D3D3B END SameHost=3D3D3B>=3B >=3B=3D3D20>=3B = >>=3BThoughts?>=3B >=3B=3D3D20>=3B >=3BPerhaps my n=3D
>=3B &= >gt=3Betwork isn't setup well=3D3D2C like I should add the local machine =3D= >3D>=3B >=3Bto /=3D
>=3B >=3Betc/hosts.I think this can be made t= >o fail gracefully though.It seems l=3D3D>=3B=3D
>=3B >=3B >=3Bik= >e it has nothing to do with AMD64_FREEBSD=3D3D2C but could have to do wit= >=3D
>=3B >=3Bh Fr=3D3D>=3B >=3BeeBSD.>=3B >=3B=3D3D20>=3B = >>=3BSeems like SocketPosix has nearly the exact same=3D
>=3B >=3B = >code but appearsmore forgi=3D3D>=3B >=3Bving.. IOError instead of Fatal= >?>=3B >=3B=3D3D20>=3B =3D
>=3B >=3B>=3BSocketPosix.m3:>=3B= > >=3B=3D3D20>=3B >=3BPROCEDURE GetHostAddr (): Address RAISES {OSErro= >=3D
>=3B >=3Br.E} =3D3D3D VAR host : AR=3D3D>=3B >=3BRAY [0..255= >] OF CHAR=3D3D3B info : Unetdb.struc=3D
>=3B >=3Bt_hostent_star=3D3D= >3B ua : U=3D3D>=3B >=3Bin.struct_in_addr=3D3D3B BEGIN IF Unix.gethos=3D= >
>=3B >=3Btname (ADR (host[0])=3D3D2C BYTESI=3D3D>=3B >=3BZE (ho= >st)) # 0 THEN IOError (Unexpect=3D
>=3B >=3Bed)=3D3D3B END=3D3D3B>= >=3B >=3B info :=3D3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3D3B =3D>>=3B >=3BIF info =3D3D3D NIL TH=3D3D>=3B >=3BEN IOError (Unexpecte= >d)=3D3D3B END=3D3D3B <=3B* ASSERT i=3D
>=3B >=3Bnfo.h_length <= >=3B=3D3D3D BYTESIZE =3D3D>=3B >=3B(Address) *>=3B>=3B >=3B ua := >=3D3D3D LOOPHOLE(info.=3D
>=3B >=3Bh_addr_list=3D3D2C UNTRACED REF U= >NT=3D3D>=3B >=3BRACED REF Uin.struct_in_addr)^^=3D3D3B=3D
>=3B >= >=3B RETURN LOOPHOLE (ua.s_addr=3D3D2C Address=3D3D>=3B >=3B)=3D3D3B END= > GetHostAddr=3D3D3B>=3B =3D
>=3B >=3B>=3B=3D3D20>=3B >=3B=3D= >3D20>=3B >=3BIt is again disappointing to see such code duplication.>= >=3B >=3B=3D
>=3B >=3B=3D3D20>=3B >=3B=3D3D20>=3B >=3BI gue= >ss SameHost can duplicate the logic to predict the err=3D
>=3B >=3Bo= >r state and ret=3D3D>=3B >=3Burn false upon error?>=3B >=3BDuplicat= >ing the logic for a t=3D
>=3B >=3Bhird time. :(>=3B >=3B=3D3D20&= >gt=3B >=3B - Jay=3D3D>=3B >=3B>=3B >=3B--_9e67232c-a064-417d-879e= >-227a77e31=3D
>=3B >=3B0f9_>=3B >=3BContent-Type: text/html=3D3B= > charset=3D3D"iso-8859-1">=3B >=3BContent-Transfer=3D
>=3B >=3B-= >Encoding: quoted-printable>=3B >=3B>=3B >=3B<=3Bhtml>=3B>=3B = >>=3B<=3Bhead>=3B>=3B >=3B<=3Bstyle>=3B>=3B >=3B.hmmessage= > P>=3B =3D
>=3B >=3B>=3B{>=3B >=3Bmargin:0px=3D3D3B>=3B &g= >t=3Bpadding:0px>=3B >=3B}>=3B >=3Bbody.hmmessage>=3B >=3B{>= >=3B >=3Bfont-size: 10=3D
>=3B >=3Bpt=3D3D3B>=3B >=3Bfont-famil= >y:Verdana>=3B >=3B}>=3B >=3B<=3B/style>=3B>=3B >=3B<=3B/h= >ead>=3B>=3B >=3B<=3Bbody class=3D3D3D'h=3D
>=3B >=3Bmmessage= >'>=3B>=3B >=3BHi. Unix network programming question..<=3BBR>=3B&g= >t=3B >=3B<=3BBR>=3BAMD64_FREEBS=3D
>=3B >=3BD:<=3BBR>=3B&g= >t=3B >=3B<=3BBR>=3B$DISPLAY is set to point back to Cygwin host.<= >=3BBR>=3BIt works for =3D
>=3B >=3BPPC_LINUX=3D3D>=3B >=3B.<= >=3BBR>=3B>=3B >=3B<=3BBR>=3B[jay at fbsdamd64a /cm3/bin]$ ./Juno<= >=3BBR>=3B>=3B >=3B<=3BBR>=3B***<=3B=3D
>=3B >=3BBR>=3B= >*** runtime error:<=3BBR>=3B***&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&= >=3Bnbsp=3D3D3B Exception "IPE=3D
>=3B >=3B=3D3D>=3B >=3Brror.Fat= >alError" not in RAISES list<=3BBR>=3B***&=3Bnbsp=3D3D3B&=3Bnbsp= >=3D3D3B&=3Bnbsp=3D
>=3B >=3B=3D3D3B file "..=3D3D>=3B >=3B/sr= >c/common/IPError.m3"=3D3D2C line 27<=3BBR>=3B***<=3BBR>=3B>=3B &g= >t=3B<=3BBR>=3BA=3D
>=3B >=3Bbort trap: 6 (core dumped)<=3BBR&g= >t=3B[jay at fbsdamd64a /cm3/bin]$<=3BBR>=3B>=3B >=3B<=3BBR>=3BIP.m= >3:<=3BB=3D
>=3B >=3BR>=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR= >>=3B>=3B >=3BPROCEDURE GetHostAddr(): Address =3D3D3D<=3BBR>=3B&a= >mp=3Bnbsp=3D3D3B =3D
>=3B >=3BVAR hname: ARRAY [0..255] =3D3D>=3B = >OF CHAR=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B BEGIN<=3BBR>=3B&=3Bnb= >sp=3D3D=3D
>=3B >=3B3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B LOCK mu D= >O<=3BBR>=3B&=3Bnbs=3D3D>=3B >=3Bp=3D3D3B&=3Bnbsp=3D3D3B&= >=3Bnbsp=3D3D3B&=3Bn=3D
>=3B >=3Bbsp=3D3D3B&=3Bnbsp=3D3D3B IF U= >nix.gethostname(ADR(hname[0])=3D3D2C B=3D3D>=3B >=3BYTESIZE(hn=3D
&g= >t=3B >=3Bame)) # 0 THEN<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B= >&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D
>= >=3B >=3B=3D3D>=3B >=3B=3D3D3B&=3Bnbsp=3D3D3B IPError.Die ()=3D3D3B= ><=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B=3D
= >>=3B >=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B E=3D3D>=3B >=3BND=3D3= >D3B<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&= >=3Bnbsp=3D
>=3B >=3B=3D3D3B&=3Bnbsp=3D3D3B VAR h :=3D3D3D Unetdb.= >gethost=3D3D>=3B >=3Bbyname(ADR(hname[0]))=3D3D3B=3D
>=3B >=3B B= >EGIN<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&am= >p=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3B=3D3D>=3B >=3Bnbsp=3D3D3=3D
= >>=3B >=3BB&=3Bnbsp=3D3D3B IF h =3D3D3D NIL THEN IPError.Die()=3D3D3B= > END=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bn=3D
>=3B >=3Bbsp= >=3D3D>=3B >=3B=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D= >3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B RETURN Get=3D
>=3B >=3BAddr= >ess(h)=3D3D3B<=3BBR>=3B&=3Bnbs=3D3D>=3B >=3Bp=3D3D3B&=3Bnbsp= >=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B=3D
>=3B = >>=3B END=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bn= >bsp=3D3D3B END=3D3D>=3B >=3B=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B EN= >=3D
>=3B >=3BD GetHostAddr=3D3D3B<=3BBR>=3B>=3B >=3B<=3BBR= >>=3BPROCEDURE GetAddress (ent: Unetdb.struct_hoste=3D
>=3B >=3Bnt_= >star): Address =3D3D3D<=3BBR>=3B=3D3D>=3B >=3B&=3Bnbsp=3D3D3B VA= >R ua: Uin.struct_in_addr=3D3D3B=3D
>=3B >=3B<=3BBR>=3B&=3Bnbs= >p=3D3D3B BEGIN<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D>=3B >=3B= >=3D3D3B&=3Bnbsp=3D3D3B &=3Blt=3D3D3B* ASSE=3D
>=3B >=3BRT ent.= >h_length &=3Blt=3D3D3B=3D3D3D BYTESIZE(Address) *&=3Bgt=3D3D3B=3D3D&g= >t=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3D=3D
>=3B >=3B3B&=3Bnbsp= >=3D3D3B&=3Bnbsp=3D3D3B ua :=3D3D3D LOOPHOLE(ent.h_addr_list=3D3D2C<=3B= >BR>=3B&=3Bnbsp=3D3D>=3B=3D
>=3B >=3B >=3B=3D3D3B&=3Bnbsp= >=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D= >3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D=3D
>=3B >=3B3B&=3Bnbsp=3D3= >D3B&=3Bnbsp=3D3D3B=3D3D>=3B >=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B= >&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D
>=3B >=3B=3D3D3B&= >amp=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B UN= >=3D3D>=3B >=3BTRACED REF UNTRACED R=3D
>=3B >=3BEF Uin.struct_in= >_addr)^^=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbs= >p=3D3D>=3B >=3B=3D3D3B RETUR=3D
>=3B >=3BN LOOPHOLE(ua.s_addr=3D= >3D2C Address)=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B END GetAddress=3D3D3B&= >lt=3B=3D
>=3B >=3B=3D3D>=3B >=3BBR>=3B>=3B >=3B&=3Bnbsp= >=3D3D3B<=3BBR>=3B>=3B >=3Bgethostbyname is failing.<=3BBR>=3B&g= >t=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3D3B=3D
>=3B >=3B<=3BBR>= >=3B>=3B >=3BAnalogous C code also fails:<=3BBR>=3B>=3B >=3B&= >=3Bnbsp=3D3D3B<=3BBR>=3B>=3B >=3B<=3BBR>=3B[jay at fbsdamd=3D
&= >gt=3B >=3B64a /cm3/bin]$ cat ~/5.c<=3BBR>=3B#include &=3Blt=3D3D3B= >assert.h&=3Bgt=3D3D3B<=3BB=3D3D>=3B >=3BR>=3B#inc=3D
>=3B &= >gt=3Blude &=3Blt=3D3D3Bnetdb.h&=3Bgt=3D3D3B<=3BBR>=3B#include &am= >p=3Blt=3D3D3Bstdio.h&=3Bgt=3D3D3B<=3BBR>=3B#includ=3D
>=3B >= >=3Be =3D3D>=3B >=3B&=3Blt=3D3D3Berrno.h&=3Bgt=3D3D3B<=3BBR>= >=3Btypedef struct hostent hostent_t=3D3D3B<=3BBR=3D
>=3B >=3B>= >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B>=3B >=3Bint main()<= >=3BBR>=3B{<=3BBR>=3B&=3Bnbsp=3D3D3Bchar hostname[200]=3D3D3B<=3B= >B=3D
>=3B >=3BR>=3B&=3Bnbsp=3D3D3Bhostent_t* h=3D3D3B=3D3D>= >=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3D3Bint i=3D3D3B<=3BBR>=3B>=3B = >>=3B&=3Bnbsp=3D3D3=3D
>=3B >=3BBi =3D3D3D gethostname(hostname= >=3D3D2C 200)=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3Bassert(i =3D3D3D=3D3D=3D= >
>=3B >=3B3D 0)=3D3D>=3B >=3B=3D3D3B<=3BBR>=3B&=3Bnbsp=3D= >3D3Bprintf("hostname: %s\n"=3D3D2C hostname)=3D3D3B<=3BB=3D
>=3B >= >=3BR>=3B&=3Bnbsp=3D3D3Bh =3D3D3D get=3D3D>=3B >=3Bhostbyname(hostn= >ame)=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3Bherror(=3D
>=3B >=3B"foo"= >)=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3Bprintf("%p %=3D3D>=3B >=3Bd %d\= >n"=3D3D2C h=3D3D2C errno=3D3D2C h=3D
>=3B >=3B_errno)=3D3D3B<=3BBR= >>=3B&=3Bnbsp=3D3D3Bassert(h)=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3Bret= >=3D3D>=3B >=3Burn 0=3D3D3B<=3BB=3D
>=3B >=3BR>=3B}<=3BBR&g= >t=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B>=3B >=3Bherror says "= >unknown host".<=3BBR>=3B>=3B >=3B<=3BBR>=3BStack is:<=3B=3DR>>=3B >=3BBR>=3B>=3B >=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&am= >p=3Bnbsp=3D3D3B at ../src/runtime/ex_frame/RTExFrame.m=3D
>=3B >=3B3= >:58<=3BBR>=3B#13 =3D3D>=3B >=3B0x0000000801a7f2b3 in RTHooks__Raise= > (M3_AJWxb1_ex=3D3D3DEr=3D
>=3B >=3Bror accessing memory=3D3D>=3B = >>=3B ad<=3BBR>=3Bdress 0x8000ffffd278: Bad address.<=3BBR>=3B)<= >=3BBR=3D
>=3B >=3B>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bn= >bsp=3D3D3B =3D3D>=3B >=3Bat ../src/runtime/common/RTHooks.m3:7=3D
&g= >t=3B >=3B9<=3BBR>=3B#14 0x000000080169c8d3 in IPError=3D3D>=3B >= >=3B__Die () at ../src/common/IPErr=3D
>=3B >=3Bor.m3:27<=3BBR>= >=3B#15 0x0000000801698a3e in IP__Ge=3D3D>=3B >=3BtHostAddr (M3_BCxjPn__= >res=3D
>=3B ult=3D3D3DError accessing mem<=3BBR>=3Bory address 0x8= >000fff=3D3D>=3B >=3Bfd338: Bad addres=3D
>=3B >=3Bs.<=3BBR>= >=3B)<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B at= > ../src/POSIX/IP.m3:=3D3D>=3B >=3B82<=3BBR=3D
>=3B >=3B>=3B#= >16 0x00000008012133d0 in XSharedMem__SameHost (M3_AQuuui_trsl=3D3D3DErro=3D= >3D=3D
>=3B >=3B>=3B >=3Br accessing m<=3BBR>=3Bemory address= > 0x8000ffffd4d8: Bad address.<=3BBR>=3B)<=3BBR>=3B&=3Bnbs=3D
= >>=3B >=3Bp=3D3D>=3B >=3B=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B= > at ../src/xvbt/XSharedMem.m3:96<=3BBR>=3B#17 0x0=3D
>=3B >=3B00= >0000801212a=3D3D>=3B >=3Bb7 in XSharedMem__InitXClient (M3_AQuuui_v=3D3= >D3DError acc=3D
>=3B >=3Bessing m<=3BBR>=3Bemory add=3D3D>=3B = >>=3Bress 0x8000ffffd648: Bad address.<=3BBR>=3B)<=3BBR>=3B&=3B= >nbsp=3D
>=3B >=3B=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B at ../s= >r=3D3D>=3B >=3Bc/xvbt/XSharedMem.m3:29<=3BBR>=3B#18 0x00=3D
>= >=3B >=3B00000801211819 in XExtensions__InitXClie=3D3D>=3B >=3Bnt (M3_= >AQuuui_xclient=3D3D3DErr=3D
>=3B >=3Bor acce<=3BBR>=3Bssing memo= >ry address 0x8000ffffd7f8: =3D3D>=3B >=3BBad address.<=3BBR>=3B)<= >=3BBR>=3B=3D
>=3B >=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bn= >bsp=3D3D3B at ../src/xvbt/XExtensions.m3=3D3D>=3B >=3B:14<=3BBR>=3B= >#1=3D
>=3B >=3B9 0x00000008012467a4 in XClientF__Connect (M3_Bd56fi_= >inst=3D3D3D0x1879=3D3D>=3B >=3Bb=3D
>=3B >=3B=3D3D2C<=3BBR>= >=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B M3_AQuuui_trsl=3D= >3D3D0x6) at ../src/x=3D
>=3B >=3Bvbt/XClie=3D3D>=3B >=3BntF.m3:5= >83<=3BBR>=3B---Type &=3Blt=3D3D3Breturn&=3Bgt=3D3D3B to continue= >=3D3D2=3D
>=3B >=3BC or q &=3Blt=3D3D3Breturn&=3Bg=3D3D>=3B = >>=3Bt=3D3D3B to quit---<=3BBR>=3B(More stack frames follow=3D
>= >=3B >=3B...)<=3BBR>=3B(gdb)<=3BBR>=3B>=3B >=3B<=3BBR>=3B(= >* return TRUE if server and client are on same hos=3D
>=3B >=3Bt *)&= >lt=3BBR>=3BPROCEDURE Sa=3D3D>=3B >=3BmeHost (trsl: XClient.T): BOOLEA= >N =3D3D3D<=3BBR>=3B&=3Bnbsp=3D
>=3B >=3B=3D3D3B VAR<=3BBR&g= >t=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bn=3D3D>=3B >=3Bbsp=3D3D3= >B display&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D=3D
>=3B >=3B3B&=3Bnbs= >p=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp= >=3D3D3B&=3Bnbsp=3D3D>=3B >=3B=3D3D3B&=3Bnbsp=3D
>=3B >=3B= >=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D= >3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B=3D
>=3B := >=3D3D3D Di=3D3D>=3B >=3BsplayHost(trsl)=3D3D3B<=3BBR>=3B&=3Bnbsp= >=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B disp=3D
>=3B >=3BlayAddr= >: IP.Address=3D3D3B<=3BB=3D3D>=3B >=3BR>=3B&=3Bnbsp=3D3D3B BEGIN= ><=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3B=3D
>=3B >= >=3Bnbsp=3D3D3B IF display =3D3D3D NIL THEN RETURN=3D3D>=3B >=3B TRUE=3D= >3D3B END=3D3D3B<=3BBR>=3B>=3B >=3B&=3B=3D
>=3B >=3Bnbsp= >=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B TRY<=3BBR>=3B&=3Bnbsp=3D= >3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D=3D
>=3B >= >=3B3B&=3Bnbsp=3D3D3B IF=3D3D>=3B >=3B NOT IP.GetHostByName(display= >=3D3D2C displayAddr) THEN R=3D
>=3B >=3BETURN FALSE=3D3D3B END=3D3D3= >B<=3BB=3D3D>=3B >=3BR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&= >=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B=3D
>=3B >=3B&=3Bnbsp=3D3D3B RETU= >RN displayAddr =3D3D3D IP.GetHos=3D3D>=3B >=3BtAddr()=3D3D3B<=3BBR>= >=3B&=3Bnbsp=3D3D=3D
>=3B >=3B3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D= >3B EXCEPT<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D= >3B |=3D3D>=3B >=3B IP.=3D
>=3B >=3BError =3D3D3D&=3Bgt=3D3D3B= > RETURN FALSE=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&= >=3Bnbsp=3D3D3B END=3D
>=3B >=3B=3D3D3B<=3BBR>=3B&=3B=3D3D>= >=3B >=3Bnbsp=3D3D3B END SameHost=3D3D3B<=3BBR>=3B>=3B >=3B&=3B= >nbsp=3D3D3B<=3BBR>=3B>=3B >=3BThoughts=3D
>=3B >=3B?<=3BBR= >>=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B>=3B >=3B<=3BBR>= >=3BPerhaps my network isn't setup well=3D3D2C like =3D
>=3B >=3BI sh= >ould add the local mach=3D3D>=3B >=3Bine to /etc/hosts.<=3BBR>=3BI = >think this can be =3D
>=3B >=3Bmade to fail gracefully though.<=3B= >B=3D3D>=3B >=3BR>=3BIt seems like it has nothing to do=3D
>=3B &= >gt=3B with AMD64_FREEBSD=3D3D2C but could have t=3D3D>=3B >=3Bo do with= > FreeBSD.<=3BBR>=3B>=3B >=3B<=3BBR=3D
>=3B >=3B>=3B&= >=3Bnbsp=3D3D3B<=3BBR>=3B>=3B >=3BSeems like SocketPosix has nearly = >the exact same code but=3D
>=3B >=3B appears<=3BBR>=3Bmore f=3D3= >D>=3B >=3Borgiving.. IOError instead of Fatal?<=3BBR>=3B>=3B >= >=3B&=3Bnbsp=3D3D=3D
>=3B >=3B3B<=3BBR>=3B>=3B >=3B<=3BB= >R>=3BSocketPosix.m3:<=3BBR>=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR= >>=3B>=3B >=3B<=3BBR>=3BPROCEDURE GetHostAd=3D
>=3B >=3Bdr = >(): Address<=3BBR>=3B&=3Bnbsp=3D3D3B RAISES {OSError.E} =3D3D3D<= >=3BBR=3D3D>=3B >=3B>=3B&=3Bnbsp=3D3D3B V=3D
>=3B >=3BAR<= >=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B host : AR= >RAY [0..255] OF CHAR=3D3D3B<=3B=3D3D=3D
>=3B >=3B>=3B >=3BBR&g= >t=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B info : Unetdb.st= >ruct_hostent_star=3D3D3B=3D
>=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3D&= >gt=3B >=3B=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B ua&=3Bnbsp=3D3D3= >B&=3Bnbsp=3D3D3B : Uin.struc=3D
>=3B >=3Bt_in_addr=3D3D3B<=3BBR= >>=3B&=3Bnbsp=3D3D3B =3D3D>=3B >=3BBEGIN<=3BBR>=3B&=3Bnbsp= >=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B =3D
>=3B >=3BIF Unix.get= >hostname (ADR (host[0])=3D3D2C BYT=3D3D>=3B >=3BESIZE (host)) # 0 THEN&= >lt=3BBR>=3B=3D
>=3B >=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&= >=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B IOError =3D3D>=3B >= >=3B(Unexpecte=3D
>=3B >=3Bd)=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B&= >amp=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B END=3D3D3B<=3BBR>=3B>=3B >=3B&a= >mp=3Bnbsp=3D3D3B&=3Bnbsp=3D3D=3D
>=3B >=3B3B&=3Bnbsp=3D3D3B in= >fo :=3D3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3D3B<=3B=3D3D>=3B &g= >t=3BBR=3D
>=3B >=3B>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3B= >nbsp=3D3D3B IF info =3D3D3D NIL THEN IOError (Unexpected)=3D
>=3B >= >=3B=3D3D3B EN=3D3D>=3B >=3BD=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B&= >=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B &=3Blt=3D3D3B* ASSERT inf=3D
>=3B = >>=3Bo.h_length &=3Blt=3D3D3B=3D3D3D BYT=3D3D>=3B >=3BESIZE (Addres= >s) *&=3Bgt=3D3D3B<=3BBR>=3B>=3B >=3B&=3Bnbsp=3D3D3=3D
>= >=3B >=3BB&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B ua :=3D3D3D LOOPHOLE(info.h= >_addr_list=3D3D2C<=3BBR>=3B&=3Bnbsp=3D3D3=3D
>=3B >=3BB&= >=3Bn=3D3D>=3B >=3Bbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3B= >nbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D=3D
>= >=3B >=3B3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D>=3B >= >=3B=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp= >=3D
>=3B >=3B=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp= >=3D3D3B UNTRACED REF UN=3D3D>=3B >=3BTRACED REF Uin.str=3D
>=3B &g= >t=3Buct_in_addr)^^=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B= >&=3Bnbsp=3D3D3B RETURN LOOP=3D3D>=3B >=3BHOLE=3D
>=3B >=3B (u= >a.s_addr=3D3D2C Address)=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B END GetHost= >Addr=3D3D3B<=3BBR>=3B>=3B >=3B&=3Bnb=3D
>=3B >=3Bsp=3D3D3= >B<=3BBR>=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B>=3B >=3BIt= > is again disappointing to see such code d=3D
>=3B >=3Buplication.&l= >t=3BBR>=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B>=3B >=3B&= >=3Bnbsp=3D3D3B<=3BBR>=3B>=3B >=3BI guess&=3Bnbsp=3D3D3BSameHo=3D= >
>=3B >=3Bst can duplicate the logic to predict the error state =3D3= >D>=3B >=3Band return fals=3D
>=3B >=3Be&=3Bnbsp=3D3D3Bupon er= >ror?<=3BBR>=3B>=3B >=3BDuplicating the logic for a third time. :(&l= >t=3BBR>=3B=3D
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>= >=3B>=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3D3B- Jay<=3BBR>=3B<=3BBR= >>=3B<=3B/body>=3B>=3B >=3B<=3B/html>=3B=3D3D>=3B >=3B>= >=3B >=3B--=3D
>=3B >=3B_9e67232c-a064-417d-879e-227a77e310f9_--=3D= >
>=3B >=3B
>=3B >=3B--_b00371fe-730b-4981-9051-a874361296d7_<= >BR>>=3B >=3BContent-Type: text/html=3B charset=3D"iso-8859-1"
>=3B= > >=3BContent-Transfer-Encoding: quoted-printable
>=3B >=3B
>= >=3B >=3B<=3Bhtml>=3B
>=3B >=3B<=3Bhead>=3B
>=3B >= >=3B<=3Bstyle>=3B
>=3B >=3B.hmmessage P
>=3B >=3B{
>= >=3B >=3Bmargin:0px=3D3B
>=3B >=3Bpadding:0px
>=3B >=3B}
= >>=3B >=3Bbody.hmmessage
>=3B >=3B{
>=3B >=3Bfont-size: 10= >pt=3D3B
>=3B >=3Bfont-family:Verdana
>=3B >=3B}
>=3B >= >=3B<=3B/style>=3B
>=3B >=3B<=3B/head>=3B
>=3B >=3B<= >=3Bbody class=3D3D'hmmessage'>=3B
>=3B >=3BDo you know the right w= >ay?<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B = >>=3BPPC_LINUX "just worked"=3D2C and I can check Solaris and Darwin.<= >=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B= >I don't want to edit /etc/hosts -- I use DHCP.<=3BBR>=3B
>=3B >= >=3BThough DHCP has been bothering me -- only for some of my machines do nam= >es =3D
>=3B >=3Bresolve=3D2C so I end using IP addresses=3D2C which = >change sometimes=3D2C and I l=3D
>=3B >=3Boop over them running ssh = >to all of them and "see what I get"=3D2C not ideal.=3D
>=3B >=3B<= >=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B= >&=3Bnbsp=3D3B- Jay<=3BBR>=3B<=3BBR>=3B<=3BBR>=3B&=3Bgt=3D= >3B To: jay.krell at cornell.edu<=3BBR>=3B&=3Bgt=3D3B Date: S=3D
>= >=3B >=3Bun=3D2C 11 Jan 2009 08:02:18 -0800<=3BBR>=3B&=3Bgt=3D3B Fr= >om: mika at async.caltech.edu<=3BBR>=3B=3D
>=3B >=3B&=3Bgt=3D3B = >CC: m3devel at elegosoft.com<=3BBR>=3B&=3Bgt=3D3B Subject: Re: [M3devel= >] Juno (X) =3D
>=3B >=3Bnetworking problem on AMD64_FREEBSD<=3BBR&= >gt=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B This is a screwy t=3D
&= >gt=3B >=3Bhing in Modula-3. A bug I would call it.<=3BBR>=3B&=3Bgt= >=3D3B <=3BBR>=3B&=3Bgt=3D3B I've noticed =3D
>=3B >=3Ba lot o= >f networking M3 programs don't work right unless<=3BBR>=3B&=3Bgt=3D3= >B the retur=3D
>=3B >=3Bn value of Unix's "hostname" maps to a real = >IP address via<=3BBR>=3B&=3Bgt=3D3B gethos=3D
>=3B >=3Btbynam= >e. I accomplish it in practice by adding my hostname<=3BBR>=3B&=3Bgt= >=3D3B to /et=3D
>=3B >=3Bc/hosts.<=3BBR>=3B&=3Bgt=3D3B <=3B= >BR>=3B&=3Bgt=3D3B This is obviously not the right way to fix it=3D
= >>=3B >=3B... <=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B = >Mika<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Jay writes:&l= >t=3BBR>=3B&=3Bgt=3D3B &=3B=3D
>=3B >=3Bgt=3D3B--_9e67232c-a0= >64-417d-879e-227a77e310f9_<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BConten= >t-Type:=3D
>=3B >=3B text/plain=3D3B charset=3D3D"iso-8859-1"<=3BB= >R>=3B&=3Bgt=3D3B &=3Bgt=3D3BContent-Transfer-Enco=3D
>=3B >= >=3Bding: quoted-printable<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BB= >R>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3BHi=3D
>=3B >=3B. Unix network programming question..<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3BAMD64_FREEBSD:<=3BBR>=3B&=3Bgt=3D>>=3B >=3B=3D3B &=3Bgt=3D3B$DISPLAY is set to point back to Cygwin h= >ost.It works for PPC_LIN=3D
>=3B >=3BUX.<=3BBR>=3B&=3Bgt=3D3B= > &=3Bgt=3D3B[jay at fbsdamd64a /cm3/bin]$ ./Juno<=3BBR>=3B&=3Bgt=3D3= >B &=3Bgt=3D3B*****=3D
>=3B >=3B* runtime error:*** Exception "IPE= >rror.FatalError" not in RAISES li=3D3D<=3BBR>=3B&=3B=3D
>=3B &g= >t=3Bgt=3D3B &=3Bgt=3D3Bst*** file "../src/common/IPError.m3"=3D3D2C line= > 27***<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >=3B &=3Bgt=3D3BAbort = >trap: 6 (core dumped)[jay at fbsdamd64a /cm3/bin]$<=3BBR>=3B&=3Bgt=3D3B= > &=3Bgt=3D
>=3B >=3B=3D3BIP.m3:<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BPROCEDURE GetHo= >stAddr(): Ad=3D
>=3B >=3Bdress =3D3D3D VAR hname: ARRAY [0..255] OF = >CHAR=3D3D3B =3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B BEG=3D
>= >=3B >=3BIN LOCK mu DO IF Unix.gethostname(ADR(hname[0])=3D3D2C BYTESIZE(h= >na=3D3D<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &=3Bgt=3D3Bme)) = ># 0 THEN IPError.Die ()=3D3D3B END=3D3D3B VAR h :=3D3D3D Unetdb.g=3D
>= >=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bethostbyname(ADR(= >hname[0]))=3D3D3B BEGIN IF h =3D3D3D NIL T=3D
>=3B >=3BHEN IPError.D= >ie()=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D3B END=3D3D3B RETU= >RN GetAddress(h)=3D3D=3D
>=3B >=3B3B END=3D3D3B END=3D3D3B END GetHo= >s=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BtAddr=3D3D3B<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3BPROCEDURE GetAddress (ent:= > Unetdb.struct_hostent_star): Address =3D3D3D VA=3D
>=3B >=3BR ua=3D= >3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B: Uin.struct_in_addr=3D3D3B BE= >GIN &=3Blt=3D3B* ASSERT ent.=3D
>=3B >=3Bh_length &=3Blt=3D3B= >=3D3D3D BYTESIZE(Addr=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bess) *= >&=3Bgt=3D3B ua :=3D3D3=3D
>=3B >=3BD LOOPHOLE(ent.h_addr_list=3D3= >D2C UNTRACED =3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BREF UNTRACED R= >=3D
>=3B >=3BEF Uin.struct_in_addr)^^=3D3D3B RETURN LOOPHOLE(ua.s_ad= >dr=3D3D2C A=3D3D<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >=3B &=3Bgt= >=3D3Bddress)=3D3D3B END GetAddress=3D3D3B<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B= >=3D3Bgethostbyname is failing.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B= >=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAnalogou=3D
>=3B >= >=3Bs C code also fails:<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20&l= >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B[jay at fbsdamd64a =3D
>=3B >= >=3B/cm3/bin]$ cat ~/5.c#include &=3Blt=3D3Bassert.h&=3Bgt=3D3B#includ= >e &=3Blt=3D3Bnetdb.h&=3Bgt=3D
>=3B >=3B=3D3B#i=3D3D<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3Bnclude &=3Blt=3D3Bstdio.h&=3Bgt=3D3B#= >include &=3Blt=3D3Berrno.h&=3Bg=3D
>=3B >=3Bt=3D3Btypedef stru= >ct hostent hostent_t=3D3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D= >20<=3BBR>=3B&=3Bgt=3D3B &=3B=3D
>=3B >=3Bgt=3D3Bint main()= >{ char hostname[200]=3D3D3B hostent_t* h=3D3D3B int i=3D3D3B<=3BBR>=3B&= >amp=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B i =3D3D3D gethostname(host= >name=3D3D2C 200)=3D3D3B assert(i =3D3D3D=3D3D3D=3D
>=3B >=3B 0)=3D3D= >3B printf("hostna=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bme: %s\n"= >=3D3D2C hostname)=3D3D3B h =3D
>=3B >=3B=3D3D3D gethostbyname(hostna= >me)=3D3D3B herror("foo")=3D3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3B p=3D
>=3B >=3Brintf("%p %d %d\n"=3D3D2C h=3D3D2C errno=3D3D2C = >h_errno)=3D3D3B assert(h)=3D3D3B retu=3D
>=3B >=3Brn 0=3D3D3B}<=3B= >BR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &a= >mp=3Bgt=3D3Bherror says "unknown host"=3D
>=3B >=3B.<=3BBR>=3B&a= >mp=3Bgt=3D3B &=3Bgt=3D3BStack is:<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3B at ../src/runtime/ex_frame/RTE=3D
>=3B >=3BxFrame.m3:58#13 0x0= >000000801a7f2b3 in RTH=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Books_= >_Raise (M=3D
>=3B >=3B3_AJWxb1_ex=3D3D3DError accessing memory addre= >ss 0x8000ffffd278: =3D3D<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &a= >mp=3Bgt=3D3BBad address.) at ../src/runtime/common/RTHooks.m3:79#14 0x00000= >00=3D
>=3B >=3B80169c8=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3Bd3 in IPError__Die () at ../src/common/IPError.m=3D
>=3B >=3B3:27#= >15 0x0000000801698a3e =3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bin IP= >__GetHostAddr (M3_BCxjP=3D
>=3B >=3Bn__result=3D3D3DError accessing = >memory address 0x80=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B00ffff= >=3D
>=3B >=3Bd338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x00000= >008012133d0=3D3D<=3BBR>=3B&=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt= >=3D3B in XSharedMem__SameHost (M3_AQuuui_trsl=3D3D3DError accessing mem=3D<= >BR>>=3B >=3Bory address 0=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3Bx8000ffffd4d8: Bad address.) at ../src/xvb=3D
>=3B >=3Bt/XSharedMe= >m.m3:96#17 0x000000=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B0801212a= >b7 in XSharedMem_=3D
>=3B >=3B_InitXClient (M3_AQuuui_v=3D3D3DError = >accessing memory=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B ad=3D
&= >gt=3B >=3Bdress 0x8000ffffd648: Bad address.) at ../src/xvbt/XSharedMem.m= >3:29#1=3D3D<=3BBR=3D
>=3B >=3B>=3B&=3Bgt=3D3B &=3Bgt=3D3B8= > 0x0000000801211819 in XExtensions__InitXClient (M3_AQuuui_x=3D
>=3B &= >gt=3Bclient=3D3D3DError=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B acc= >essing memory address 0x8000ffffd7f=3D
>=3B >=3B8: Bad address.) at = >../src/xvbt/X=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BExtensions.m3:= >14#19 0x=3D
>=3B >=3B00000008012467a4 in XClientF__Connect (M3_Bd56f= >i_inst=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D
>=3B >=3B= >=3D3D3D0x1879b=3D3D2C M3_AQuuui_trsl=3D3D3D0x6) at ../src/xvbt/XClientF.m3:= >583---=3D
>=3B >=3BTyp=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3Be &=3Blt=3D3Breturn&=3Bgt=3D3B to continue=3D3D2C or q &=3Blt=3D= >3Bret=3D
>=3B >=3Burn&=3Bgt=3D3B to quit---(More stack frames fol= >low=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B...)(gdb)<=3B=3D
&g= >t=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B(* return TRUE if server an= >d client are on same host *)PROC=3D
>=3B >=3BEDURE SameHost (=3D3D&l= >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Btrsl: XClient.T): BOOLEAN =3D3D3D = >VAR dis=3D
>=3B >=3Bplay :=3D3D3D DisplayH=3D3D<=3BBR>=3B&=3B= >gt=3D3B &=3Bgt=3D3Bost(trsl)=3D3D3B displayAddr: IP.Addr=3D
>=3B &g= >t=3Bess=3D3D3B BEGIN IF display =3D3D3D NIL THE=3D3D<=3BBR>=3B&=3Bgt= >=3D3B &=3Bgt=3D3BN RETURN TRUE=3D3D=3D
>=3B >=3B3B END=3D3D3B<= >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B TRY IF NOT IP.GetHostByName(displa= >y=3D3D2C displ=3D
>=3B >=3BayAddr) THEN RETURN FA=3D3D<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3BLSE=3D3D3B END=3D3D3B RETURN displayA=3D
&g= >t=3B >=3Bddr =3D3D3D IP.GetHostAddr()=3D3D3B EXCEPT =3D3D<=3BBR>=3B&a= >mp=3Bgt=3D3B &=3Bgt=3D3B| IP.Error =3D3D3D=3D
>=3B >=3B&=3Bgt= >=3D3B RETURN FALSE=3D3D3B END=3D3D3B END SameHost=3D3D3B<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BB=3D
>=3B >=3BR>=3B&=3Bgt= >=3D3B &=3Bgt=3D3BThoughts?<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D= >3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BPerhaps my n=3D
>=3B &g= >t=3Betwork isn't setup well=3D3D2C like I should add the local machine =3D3= >D<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &=3Bgt=3D3Bto /etc/hos= >ts.I think this can be made to fail gracefully though.=3D
>=3B >=3BI= >t seems l=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bike it has nothing= > to do with AMD64_FREEBSD=3D
>=3B >=3B=3D3D2C but could have to do w= >ith Fr=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BeeBSD.<=3BBR>=3B&= >amp=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B=3D3D20<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3BSeems like SocketPosix has nearly the exact same c= >=3D
>=3B >=3Bode but appearsmore forgi=3D3D<=3BBR>=3B&=3Bgt= >=3D3B &=3Bgt=3D3Bving.. IOError instead of Fata=3D
>=3B >=3Bl?<= >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B= > &=3Bgt=3D3BSocketPosix.m3:<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B= >=3D
>=3B >=3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BPROCE= >DURE GetHostAddr (): Address RAISES {OSError.E} =3D
>=3B >=3B=3D3D3D= > VAR host : AR=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BRAY [0..255] = >OF CHAR=3D3D3B info : Une=3D
>=3B >=3Btdb.struct_hostent_star=3D3D3B= > ua : U=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bin.struct_in_addr=3D= >3D=3D
>=3B >=3B3B BEGIN IF Unix.gethostname (ADR (host[0])=3D3D2C BY= >TESI=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D
>=3B >=3BZE = >(host)) # 0 THEN IOError (Unexpected)=3D3D3B END=3D3D3B<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B inf=3D
>=3B >=3Bo :=3D3D3D Unetdb.gethostb= >yname (ADR (host[0]))=3D3D3B IF info =3D3D3D NIL TH=3D3D<=3B=3D
>=3B= > >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BEN IOError (Unexpected)=3D3D3B = >END=3D3D3B &=3Blt=3D3B* ASSERT info.h=3D
>=3B >=3B_length &=3B= >lt=3D3B=3D3D3D BYTESIZE =3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B(Ad= >dress) *&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &= >=3Bgt=3D3B ua :=3D3D3D LOOPHOLE(info.h_addr_list=3D3D2C UNTRACED REF UNT=3D= >3D<=3BBR>=3B=3D
>=3B >=3B&=3Bgt=3D3B &=3Bgt=3D3BRACED REF = >Uin.struct_in_addr)^^=3D3D3B RETURN LOOPHOLE (ua.s_add=3D
>=3B >=3Br= >=3D3D2C Address=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B)=3D3D3B END= > GetHostAddr=3D3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D
>=3B >= >=3B=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR&g= >t=3B&=3Bgt=3D3B &=3Bgt=3D3BIt is again disappointing to=3D
>=3B = >>=3B see such code duplication.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3= >B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B=3D= >
>=3B >=3B&=3Bgt=3D3B &=3Bgt=3D3BI guess SameHost can duplicat= >e the logic to predict the error =3D
>=3B >=3Bstate and ret=3D3D<= >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Burn false upon error?<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3BDupl=3D
>=3B >=3Bicating the logic for = >a third time. :(<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR&= >gt=3B&=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B - Jay=3D3D<=3BBR&g= >t=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3= >B--_9e67232c-a064-417d-879e-22=3D
>=3B >=3B7a77e310f9_<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3BContent-Type: text/html=3D3B charset=3D3D"iso-= >8859-=3D
>=3B >=3B1"<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BConte= >nt-Transfer-Encoding: quoted-printable<=3BBR>=3B&=3Bgt=3D3B &=3Bg= >=3D
>=3B >=3Bt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Blt=3D3Bhtml&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Blt=3D3Bhead&=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3= >B &=3Bgt=3D3B&=3Blt=3D3Bstyle&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D= >3B &=3Bgt=3D3B.hmmessage P<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D= >
>=3B >=3B{<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bmargin:0px=3D3= >D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bpadding:0px<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B}<=3BBR>=3B&=3Bgt=3D3B = >&=3Bgt=3D3Bbody.hmmessage<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B{<= >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfont-=3D
>=3B >=3Bsize: 10pt= >=3D3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfont-family:Verdana<=3B= >BR>=3B&=3Bgt=3D3B &=3Bgt=3D3B}<=3BBR>=3B&=3Bg=3D
>=3B &= >gt=3Bt=3D3B &=3Bgt=3D3B&=3Blt=3D3B/style&=3Bgt=3D3B<=3BBR>=3B&= >amp=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3B/head&=3Bgt=3D3B<=3BBR>=3B= >&=3Bgt=3D3B &=3B=3D
>=3B >=3Bgt=3D3B&=3Blt=3D3Bbody class= >=3D3D3D'hmmessage'&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B= >Hi. Unix networ=3D
>=3B >=3Bk programming question..&=3Blt=3D3BBR= >&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3BBR&a= >mp=3Bgt=3D3BAMD64_=3D
>=3B >=3BFREEBSD:&=3Blt=3D3BBR&=3Bgt=3D3= >B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3BBR&=3Bgt=3D3B$= >DISPLAY is set to poi=3D
>=3B >=3Bnt back to Cygwin host.&=3Blt= >=3D3BBR&=3Bgt=3D3BIt works for PPC_LINUX=3D3D<=3BBR>=3B&=3Bgt=3D3= >B &=3Bg=3D
>=3B >=3Bt=3D3B.&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR= >>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3BBR&=3Bgt=3D3B[jay at fbsda= >md64a /cm3/bin]=3D
>=3B >=3B$ ./Juno&=3Blt=3D3BBR&=3Bgt=3D3B&l= >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3BBR&=3Bgt=3D3B***&= >amp=3Blt=3D3BBR&=3Bgt=3D3B*** r=3D
>=3B >=3Buntime error:&=3Bl= >t=3D3BBR&=3Bgt=3D3B***&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D= >3B&=3Bamp=3D3Bnbsp=3D
>=3B >=3B=3D3D3B Exception "IPE=3D3D<=3BB= >R>=3B&=3Bgt=3D3B &=3Bgt=3D3Brror.FatalError" not in RAISES list=3D<= >BR>>=3B >=3B&=3Blt=3D3BBR&=3Bgt=3D3B***&=3Bamp=3D3Bnbsp=3D3D3B= >&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B file "..=3D
>=3B = >>=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B/src/common/IPError.m= >3"=3D3D2C line 27&=3Blt=3D3BBR&=3Bgt=3D3B***&=3Bl=3D
>=3B >= >=3Bt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3B= >lt=3D3BBR&=3Bgt=3D3BAbort trap: 6 (core dumped)&=3Blt=3D
>=3B &g= >t=3B=3D3BBR&=3Bgt=3D3B[jay at fbsdamd64a /cm3/bin]$&=3Blt=3D3BBR&=3Bg= >t=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3BB=3D
>= >=3B >=3BR&=3Bgt=3D3BIP.m3:&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&= >=3Bgt=3D3B<=3B=3D
>=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BPR= >OCEDURE GetHostAddr(): Address =3D3D3D&=3Blt=3D3BBR&=3Bgt=3D3B&=3B= >amp=3D3B=3D
>=3B >=3Bnbsp=3D3D3B VAR hname: ARRAY [0..255] =3D3D<= >=3BBR>=3B&=3Bgt=3D3B OF CHAR=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D
>= >=3B >=3B=3D3B&=3Bamp=3D3Bnbsp=3D3D3B BEGIN&=3Blt=3D3BBR&=3Bgt=3D= >3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D
>= >=3B >=3B=3D3Bnbsp=3D3D3B LOCK mu DO&=3Blt=3D3BBR&=3Bgt=3D3B&=3Ba= >mp=3D3Bnbs=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bp=3D3D3B&=3Ba= >=3D
>=3B >=3Bmp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp= >=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B IF Unix.geth=3D
>=3B >=3B= >ostname(ADR(hname[0])=3D3D2C B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3BYTESIZE(hname)) # 0 THEN&=3Blt=3D
>=3B >=3B=3D3BBR&=3Bgt= >=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbs= >p=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B=3D
>=3B >=3B&=3Bamp=3D3Bnbsp= >=3D3D3B&=3Bamp=3D3Bnbsp=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B= >=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B IPErro=3D
>=3B >=3Br.Die ()=3D3D3B= >&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp= >=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B=3D
>=3B >=3B&=3Bamp=3D3Bnbsp=3D= >3D3B&=3Bamp=3D3Bnbsp=3D3D3B E=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3BND=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B=3D
>=3B >=3B&=3Bamp= >=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3B= >amp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D
>=3B >=3B=3D3D3B VAR h := >=3D3D3D Unetdb.gethost=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bbynam= >e(ADR(hname[0]))=3D
>=3B >=3B=3D3D3B BEGIN&=3Blt=3D3BBR&=3Bgt= >=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbs= >p=3D3D3B&=3Ba=3D
>=3B >=3Bmp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp= >=3D3D3B&=3Bamp=3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bnbsp= >=3D3D3B&=3Bamp=3D3Bnb=3D
>=3B >=3Bsp=3D3D3B IF h =3D3D3D NIL THEN= > IPError.Die()=3D3D3B END=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D= >
>=3B >=3B=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnb= >sp=3D
>=3B >=3B=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp= >=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B RETURN GetAddress(h)=3D
>=3B >=3B= >=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbs=3D3D<=3BBR>=3B&= >amp=3Bgt=3D3B &=3Bgt=3D3Bp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D= >
>=3B >=3B=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bn= >bsp=3D3D3B END=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bn=3D
&= >gt=3B >=3Bbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B = >END=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D3B&=3Blt=3D3B=3D= >
>=3B >=3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B END GetHostAddr= >=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D
>=3B >=3B=3D3B&=3Blt=3D3BBR&=3Bgt=3D3BPROCEDURE GetAddress= > (ent: Unetdb.struct_hostent_star): Ad=3D
>=3B >=3Bdress =3D3D3D&= >=3Blt=3D3BBR&=3Bgt=3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >amp=3Bamp=3D3Bnbsp=3D3D3B VAR ua: Uin.s=3D
>=3B >=3Btruct_in_addr=3D= >3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B BEGIN&=3Blt= >=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3B=3D
>=3B >=3Bnbsp=3D3D3B&=3Ba= >mp=3D3Bnbsp=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D3B&=3Bam= >p=3D3Bnbsp=3D3D3B &=3Bamp=3D3Blt=3D3D3=3D
>=3B >=3BB* ASSERT ent.= >h_length &=3Bamp=3D3Blt=3D3D3B=3D3D3D BYTESIZE(Address) *&=3Bamp=3D3B= >gt=3D3D3=3D
>=3B >=3BB=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnb= >sp=3D3D3B&=3Bamp=3D3Bn=3D
>=3B >=3Bbsp=3D3D3B ua :=3D3D3D LOOPHOL= >E(ent.h_addr_list=3D3D2C&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp= >=3D
>=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D3B= >&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3= >D3B&=3Ba=3D
>=3B >=3Bmp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B= >&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D<= >BR>>=3B >=3B=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B=3D3D<=3BBR>=3B&=3B= >gt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&= >amp=3Ba=3D
>=3B >=3Bmp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D
&= >gt=3B >=3B=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B UN= >=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BTRACED REF UNTR=3D
>= >=3B ACED REF Uin.struct_in_addr)^^=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbs=3D
>=3B >=3Bp=3D3D3B&=3B= >amp=3D3Bnbsp=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D3B RETURN = >LOOPHOLE(ua.s_addr=3D3D2C A=3D
>=3B >=3Bddress)=3D3D3B&=3Blt=3D3B= >BR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B END GetAddress=3D3D3B&=3Blt= >=3D3B=3D3D<=3BBR>=3B=3D
>=3B >=3B&=3Bgt=3D3B &=3Bgt=3D3BBR= >&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbs= >p=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D
>=3B = >>=3B=3D3B &=3Bgt=3D3Bgethostbyname is failing.&=3Blt=3D3BBR&=3Bg= >t=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3BBR&=3B=3D= >
>=3B >=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&=3Bgt= >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAnalogous C code also f=3D<= >BR>>=3B >=3Bails:&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt= >=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3= >B<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &=3Bgt=3D3B&=3Blt= >=3D3BBR&=3Bgt=3D3B[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c&=3Blt=3D3BBR&a= >mp=3Bgt=3D3B#=3D
>=3B >=3Binclude &=3Bamp=3D3Blt=3D3D3Bassert.h&a= >mp=3Bamp=3D3Bgt=3D3D3B&=3Blt=3D3BB=3D3D<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3BR&=3Bgt=3D
>=3B >=3B=3D3B#include &=3Bamp=3D3Blt=3D3= >D3Bnetdb.h&=3Bamp=3D3Bgt=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B#include &a= >mp=3Bamp=3D
>=3B >=3B=3D3Blt=3D3D3Bstdio.h&=3Bamp=3D3Bgt=3D3D3B&a= >mp=3Blt=3D3BBR&=3Bgt=3D3B#include =3D3D<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B&=3B=3D
>=3B >=3Bamp=3D3Blt=3D3D3Berrno.h&=3Bamp=3D3= >Bgt=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3Btypedef struct hostent host=3D
&= >gt=3B >=3Bent_t=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3B= >gt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&=3Bgt= >=3D3B<=3BBR>=3B=3D
>=3B >=3B&=3Bgt=3D3B &=3Bgt=3D3Bint mai= >n()&=3Blt=3D3BBR&=3Bgt=3D3B{&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp= >=3D3Bnbsp=3D3D3Bchar ho=3D
>=3B >=3Bstname[200]=3D3D3B&=3Blt=3D3B= >BR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3Bhostent_t* h=3D3D3B=3D3D<=3BBR&= >gt=3B&=3Bgt=3D
>=3B >=3B=3D3B &=3Bgt=3D3B&=3Blt=3D3BBR&= >=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3Bint i=3D3D3B&=3Blt=3D3BBR&=3Bgt= >=3D3B<=3BBR>=3B&=3Bgt=3D3B =3D
>=3B >=3B&=3Bgt=3D3B&=3B= >amp=3D3Bnbsp=3D3D3Bi =3D3D3D gethostname(hostname=3D3D2C 200)=3D3D3B&=3B= >lt=3D3BBR&=3Bg=3D
>=3B >=3Bt=3D3B&=3Bamp=3D3Bnbsp=3D3D3Bassert= >(i =3D3D3D=3D3D3D 0)=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D3B= >&=3Blt=3D3BBR=3D
>=3B >=3B&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3= >Bprintf("hostname: %s\n"=3D3D2C hostname)=3D3D3B&=3Blt=3D3BBR&=3Bg=3D= >
>=3B >=3Bt=3D3B&=3Bamp=3D3Bnbsp=3D3D3Bh =3D3D3D get=3D3D<=3BBR= >>=3B&=3Bgt=3D3B &=3Bgt=3D3Bhostbyname(hostname)=3D3D3=3D
>=3B = >>=3BB&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3Bherror("foo"= >)=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D
>=3B >= >=3B=3D3D3Bprintf("%p %=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bd %d\= >n"=3D3D2C h=3D3D2C errno=3D3D2C h_errno=3D
>=3B >=3B)=3D3D3B&=3Bl= >t=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3Bassert(h)=3D3D3B&=3Blt= >=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D
>=3B >=3B=3D3D3Bret=3D3D= ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Burn 0=3D3D3B&=3Blt=3D3BBR&= >=3Bgt=3D3B}&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D
>= >=3B >=3B=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&am= >p=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bherror says "unkno=3D= >
>=3B >=3Bwn host".&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3BBR&=3Bgt=3D3BStack is:&=3Blt= >=3D3BBR&=3Bgt=3D
>=3B >=3B=3D3B<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D= >3Bnbsp=3D3D3B at ../=3D
>=3B >=3Bsrc/runtime/ex_frame/RTExFrame.m3:5= >8&=3Blt=3D3BBR&=3Bgt=3D3B#13 =3D3D<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B0=3D
>=3B >=3Bx0000000801a7f2b3 in RTHooks__Raise (M3_AJWx= >b1_ex=3D3D3DError accessing memor=3D
>=3B >=3By=3D3D<=3BBR>=3B&a= >mp=3Bgt=3D3B &=3Bgt=3D3B ad&=3Blt=3D3BBR&=3Bgt=3D3Bdress 0x8000fff= >fd278: Bad address.&=3Blt=3D
>=3B >=3B=3D3BBR&=3Bgt=3D3B)&= >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3= >D3B&=3Bamp=3D3Bnbsp=3D3D3B =3D
>=3B >=3B=3D3D<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3Bat ../src/runtime/common/RTHooks.m3:79&=3Blt=3D= >3BBR&=3Bgt=3D3B#14=3D
>=3B >=3B 0x000000080169c8d3 in IPError=3D3= >D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B__Die () at ../src/common=3D>>=3B >=3B/IPError.m3:27&=3Blt=3D3BBR&=3Bgt=3D3B#15 0x00000008016= >98a3e in IP__Ge=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3B=3D
>=3B >= >=3Bgt=3D3BtHostAddr (M3_BCxjPn__result=3D3D3DError accessing mem&=3Blt= >=3D3BBR&=3Bgt=3D3Bory =3D
>=3B >=3Baddress 0x8000fff=3D3D<=3BBR= >>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfd338: Bad address.&=3Blt=3D3BBR&= >=3Bgt=3D3B)&=3Blt=3D
>=3B >=3B=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3= >Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B at ../src/= >POSIX=3D
>=3B >=3B/IP.m3:=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3B82&=3Blt=3D3BBR&=3Bgt=3D3B#16 0x00000008012133d0 in XShare=3D>>=3B >=3BdMem__SameHost (M3_AQuuui_trsl=3D3D3DErro=3D3D<=3BBR>=3B&= >amp=3Bgt=3D3B &=3Bgt=3D3Br accessing m&=3Blt=3D
>=3B >=3B=3D3B= >BR&=3Bgt=3D3Bemory address 0x8000ffffd4d8: Bad address.&=3Blt=3D3BBR&= >amp=3Bgt=3D3B)&=3Blt=3D3BB=3D
>=3B >=3BR&=3Bgt=3D3B&=3Bamp= >=3D3Bnbsp=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D3B&=3Bamp= >=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B=3D
>=3B >=3B at ../src/xv= >bt/XSharedMem.m3:96&=3Blt=3D3BBR&=3Bgt=3D3B#17 0x0000000801212a=3D3D&= >lt=3BBR>=3B&=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3Bb7 in XShared= >Mem__InitXClient (M3_AQuuui_v=3D3D3DError accessing m=3D
>=3B >=3B&a= >mp=3Blt=3D3BBR&=3Bgt=3D3Bemory add=3D3D<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3Bress 0x8000ffffd648: Bad address=3D
>=3B >=3B.&=3Blt=3D= >3BBR&=3Bgt=3D3B)&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B= >&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D
>=3B >=3B=3D3D3B at= > ../sr=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bc/xvbt/XSharedMem.m3:= >29&=3Blt=3D3BBR&=3Bgt=3D3B#18 =3D
>=3B >=3B0x0000000801211819 = >in XExtensions__InitXClie=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bnt= > (M3_AQuu=3D
>=3B >=3Bui_xclient=3D3D3DError acce&=3Blt=3D3BBR&am= >p=3Bgt=3D3Bssing memory address 0x8000ffffd7f8:=3D
>=3B >=3B =3D3D&l= >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BBad address.&=3Blt=3D3BBR&= >=3Bgt=3D3B)&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D
>=3B &= >gt=3B=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B at ../src/= >xvbt/XExtensions.m3=3D3D<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &a= >mp=3Bgt=3D3B:14&=3Blt=3D3BBR&=3Bgt=3D3B#19 0x00000008012467a4 in XCli= >entF__Connect (M=3D
>=3B >=3B3_Bd56fi_inst=3D3D3D0x1879=3D3D<=3BBR= >>=3B&=3Bgt=3D3B &=3Bgt=3D3Bb=3D3D2C&=3Blt=3D3BBR&=3Bgt=3D3B&a= >mp=3Bamp=3D3Bnbsp=3D
>=3B >=3B=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B M3_AQuuui_trsl=3D3D3D0x6) at ../src/xvb=3D
>=3B= > >=3Bt/XClie=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BntF.m3:583&am= >p=3Blt=3D3BBR&=3Bgt=3D3B---Type &=3Bamp=3D3Blt=3D3D3Bre=3D
>=3B = >>=3Bturn&=3Bamp=3D3Bgt=3D3D3B to continue=3D3D2C or q &=3Bamp=3D3Bl= >t=3D3D3Breturn&=3Bamp=3D3Bg=3D3D<=3BBR=3D
>=3B >=3B>=3B&= >=3Bgt=3D3B &=3Bgt=3D3Bt=3D3D3B to quit---&=3Blt=3D3BBR&=3Bgt=3D3B(= >More stack frames follow...)&=3B=3D
>=3B >=3Blt=3D3BBR&=3Bgt= >=3D3B(gdb)&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B&=3Blt=3D3BBR&=3Bgt=3D3B(* return TR=3D
>=3B >=3BUE = >if server and client are on same host *)&=3Blt=3D3BBR&=3Bgt=3D3BPROCE= >DURE Sa=3D3D<=3BBR=3D
>=3B >=3B>=3B&=3Bgt=3D3B &=3Bgt=3D3B= >meHost (trsl: XClient.T): BOOLEAN =3D3D3D&=3Blt=3D3BBR&=3Bgt=3D3B&= >=3Bamp=3D3Bn=3D
>=3B >=3Bbsp=3D3D3B VAR&=3Blt=3D3BBR&=3Bgt=3D3= >B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bn=3D3D&= >lt=3BBR>=3B&=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3Bbsp=3D3D3B di= >splay&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbs= >p=3D3D3B=3D
>=3B >=3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp= >=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bn= >bsp=3D
>=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3= >D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp= >=3D3D3B&=3Ba=3D
>=3B >=3Bmp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D= >3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp= >=3D
>=3B >=3B=3D3D3B :=3D3D3D Di=3D3D<=3BBR>=3B&=3Bgt=3D3B &a= >mp=3Bgt=3D3BsplayHost(trsl)=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp= >=3D
>=3B >=3B=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D= >3Bnbsp=3D3D3B displayAddr: IP.Address=3D3D3B&=3Bl=3D
>=3B >=3Bt= >=3D3BB=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BR&=3Bgt=3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B BEGIN&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3B= >=3D
>=3B >=3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbs= >p=3D3D3B IF display =3D3D3D NIL THEN RETURN=3D
>=3B >=3B=3D3D<=3BB= >R>=3B&=3Bgt=3D3B &=3Bgt=3D3B TRUE=3D3D3B END=3D3D3B&=3Blt=3D3BBR= >&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D
&= >gt=3B >=3B=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp= >=3D3D3B TRY&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D
>=3B &= >gt=3B=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp= >=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B IF=3D3D=3D
>=3B >=3B<= >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B NOT IP.GetHostByName(display=3D3D2= >C displayAddr) THEN RETUR=3D
>=3B >=3BN FALSE=3D3D3B END=3D3D3B&= >=3Blt=3D3BB=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BR&=3Bgt=3D3B&= >amp=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D
>=3B >=3B=3D3Bnbsp=3D3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B = >RETURN display=3D
>=3B >=3BAddr =3D3D3D IP.GetHos=3D3D<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3BtAddr()=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&a= >mp=3Bamp=3D3Bnb=3D
>=3B >=3Bsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B EXCEPT&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bn= >bsp=3D3D3=3D
>=3B >=3BB&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp= >=3D3D3B |=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B IP.Error =3D3D3D&= >amp=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D3B RETURN FALSE=3D3D3B&=3Blt=3D= >3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&= >=3B=3D
>=3B >=3Bamp=3D3Bnbsp=3D3D3B END=3D3D3B&=3Blt=3D3BBR&= >=3Bgt=3D3B&=3Bamp=3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bnb= >sp=3D3D3B =3D
>=3B >=3BEND SameHost=3D3D3B&=3Blt=3D3BBR&=3Bgt= >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&= >amp=3Blt=3D3BBR&=3Bgt=3D
>=3B >=3B=3D3B<=3BBR>=3B&=3Bgt=3D= >3B &=3Bgt=3D3BThoughts?&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3=3D
>=3B >=3BB&= >=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Blt=3D3BBR&=3Bgt=3D3BPerhaps my network isn't setu=3D
>=3B >=3B= >p well=3D3D2C like I should add the local mach=3D3D<=3BBR>=3B&=3Bgt= >=3D3B &=3Bgt=3D3Bine to /etc=3D
>=3B >=3B/hosts.&=3Blt=3D3BBR&= >amp=3Bgt=3D3BI think this can be made to fail gracefully though.&=3Blt= >=3D
>=3B >=3B=3D3BB=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BR= >&=3Bgt=3D3BIt seems like it has nothing to do with AMD6=3D
>=3B >= >=3B4_FREEBSD=3D3D2C but could have t=3D3D<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3Bo do with FreeBSD.&=3Blt=3D3B=3D
>=3B >=3BBR&=3Bgt= >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3BBR&=3Bgt= >=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B= >&=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3BSeems like SocketPosix has= > nearly the exact same code but appear=3D
>=3B >=3Bs&=3Blt=3D3BBR= >&=3Bgt=3D3Bmore f=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Borgivin= >g.. IOError instead of Fata=3D
>=3B >=3Bl?&=3Blt=3D3BBR&=3Bgt= >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&= >amp=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3B=3D
>= >=3B >=3Bgt=3D3B&=3Blt=3D3BBR&=3Bgt=3D3BSocketPosix.m3:&=3Blt=3D3= >BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3B= >nbs=3D
>=3B >=3Bp=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3BBR&=3Bgt=3D3BPROCEDURE GetHos= >tAddr ()=3D
>=3B >=3B: Address&=3Blt=3D3BBR&=3Bgt=3D3B&=3Ba= >mp=3D3Bnbsp=3D3D3B RAISES {OSError.E} =3D3D3D&=3Blt=3D3BBR=3D3D=3D
&g= >t=3B >=3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B&=3B= >amp=3D3Bnbsp=3D3D3B VAR&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D= >3D3B&=3Ba=3D
>=3B >=3Bmp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3= >B host : ARRAY [0..255] OF CHAR=3D3D3B&=3Blt=3D3B=3D3D<=3B=3D
>= >=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BBR&=3Bgt=3D3B&=3Bamp= >=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B in=3D<= >BR>>=3B >=3Bfo : Unetdb.struct_hostent_star=3D3D3B&=3Blt=3D3BBR&= >=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D<=3BBR>=3B&=3Bgt=3D3B =3D
>= >=3B >=3B&=3Bgt=3D3B=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbs= >p=3D3D3B ua&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D
>=3B >= >=3B=3D3D3B : Uin.struct_in_addr=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3B= >amp=3D3Bnbsp=3D3D3B =3D3D<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >=3B &= >amp=3Bgt=3D3BBEGIN&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&= >amp=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B =3D
>=3B >=3BIF = >Unix.gethostname (ADR (host[0])=3D3D2C BYT=3D3D<=3BBR>=3B&=3Bgt=3D3B= > &=3Bgt=3D3BESIZE (host)=3D
>=3B >=3B) # 0 THEN&=3Blt=3D3BBR&a= >mp=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp= >=3D3Bnbsp=3D3D3B&=3Bam=3D
>=3B >=3Bp=3D3Bnbsp=3D3D3B&=3Bamp=3D= >3Bnbsp=3D3D3B IOError =3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B(Unex= >pected)=3D3D3B=3D
>=3B >=3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp= >=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B END=3D= >3D3B&=3Blt=3D
>=3B >=3B=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3B= >gt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&= >amp=3Bamp=3D3Bnbsp=3D3D3=3D
>=3B >=3BB info :=3D3D3D Unetdb.gethostb= >yname (ADR (host[0]))=3D3D3B&=3Blt=3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B= > =3D
>=3B >=3B&=3Bgt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D= >3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B IF info =3D3D3=3D>>=3B >=3BD NIL THEN IOError (Unexpected)=3D3D3B EN=3D3D<=3BBR>=3B&= >amp=3Bgt=3D3B &=3Bgt=3D3BD=3D3D3B&=3Blt=3D3BBR&=3Bg=3D
>=3B &= >gt=3Bt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp= >=3D3Bnbsp=3D3D3B &=3Bamp=3D3Blt=3D3D3B* ASSERT=3D
>=3B >=3B info.= >h_length &=3Bamp=3D3Blt=3D3D3B=3D3D3D BYT=3D3D<=3BBR>=3B&=3Bgt=3D= >3B &=3Bgt=3D3BESIZE (Address) *=3D
>=3B >=3B&=3Bamp=3D3Bgt=3D3= >D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3= >B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D=3D
>=3B >=3B3B&a= >mp=3Bamp=3D3Bnbsp=3D3D3B ua :=3D3D3D LOOPHOLE(info.h_addr_list=3D3D2C&= >=3Blt=3D3BBR&=3Bgt=3D3B&=3Ba=3D
>=3B >=3Bmp=3D3Bnbsp=3D3D3B&am= >p=3Bamp=3D3Bn=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bbsp=3D3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnb=3D
>=3B >=3Bsp=3D3D3B&=3B= >amp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D
>=3B >=3B=3D3Bnbsp=3D3D3B&=3B= >amp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D<=3BBR>=3B&=3Bgt=3D3B &am= >p=3Bgt=3D3B=3D3D3B&=3Bamp=3D3Bnbsp=3D
>=3B >=3B=3D3D3B&=3Bamp= >=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3B= >amp=3D3Bnbsp=3D3D3B&=3Bamp=3D
>=3B >=3B=3D3Bnbsp=3D3D3B&=3Bamp= >=3D3Bnbsp=3D3D3B UNTRACED REF UN=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3BTRACED REF =3D
>=3B >=3BUin.struct_in_addr)^^=3D3D3B&=3Blt= >=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&a= >mp=3Bam=3D
>=3B >=3Bp=3D3Bnbsp=3D3D3B RETURN LOOP=3D3D<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3BHOLE (ua.s_addr=3D3D2C Address)=3D
>=3B &= >gt=3B=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B END Ge= >tHostAddr=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3B=3D
&= >gt=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BB= >R&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnb= >sp=3D3D3B=3D
>=3B >=3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&a= >mp=3Bgt=3D3B &=3Bgt=3D3BIt is again disappointing to see such code d=3D<= >BR>>=3B >=3Buplication.&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&=3Bg= >t=3D3B<=3BBR=3D
>=3B >=3B>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt= >=3D3B &=3Bgt=3D3BI guess&=3Bamp=3D3B=3D
>=3B >=3Bnbsp=3D3D3BSa= >meHost can duplicate the logic to predict the error state =3D3D<=3BBR=3D<= >BR>>=3B >=3B>=3B&=3Bgt=3D3B &=3Bgt=3D3Band return false&=3Ba= >mp=3D3Bnbsp=3D3D3Bupon error?&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B= >=3D
>=3B >=3B&=3Bgt=3D3B &=3Bgt=3D3BDuplicating the logic for = >a third time. :(&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bg=3D
= >>=3B >=3Bt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BB= >R&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3BBR&= >amp=3Bgt=3D3B&=3Bam=3D
>=3B >=3Bp=3D3Bnbsp=3D3D3B- Jay&=3Blt= >=3D3BBR&=3Bgt=3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Blt=3D3B/body&= >=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3B=3D
>=3B >=3Bgt=3D3B&a= >mp=3Blt=3D3B/html&=3Bgt=3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B--_9e67232c-a064=3D
>= >=3B >=3B-417d-879e-227a77e310f9_--<=3BBR>=3B<=3BBR>=3B<=3B/body= >>=3B
>=3B >=3B<=3B/html>=3B=3D
>=3B >=3B
>=3B >= >=3B--_b00371fe-730b-4981-9051-a874361296d7_--

>= > >--_b0c10337-0e1c-414e-aae5-e611dcd4be8a_-- From jay.krell at cornell.edu Mon Jan 12 10:46:24 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 09:46:24 +0000 Subject: [M3devel] SPARC32_LINUX Message-ID: SPARC32_LINUX is looking pretty decent now. min and std archives at: http://modula3.elegosoft.com/cm3/uploaded-archives/ There is something funny I saw where generated OSConfig.i3 had extra stuff at the end. But I rebuilt and it went away. System builds itself, Juno, formsedit, mentor come up. After a while on the splash screen, making progress, Juno exits with: Fatal error: cannot open or create "Untitled.juno" in the current directory Hm. That might be a real problem. Maybe time to unclone the stat header.. I have write access and AMD64_FREEBSD worked ok. (Ok to have "32" in the processor name?) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 10:56:43 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 09:56:43 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: <200901120934.n0C9YOs8074851@camembert.async.caltech.edu> References: Your message of "Mon, 12 Jan 2009 08:47:17 GMT." <200901120934.n0C9YOs8074851@camembert.async.caltech.edu> Message-ID: Yes, generating the headers is viable. I thought I mentioned that a few times. They could be generated in any build "that can". i.e. a native build, that has a working C development system and checked against the checked in ones. So then porting is: copy the generator to new system, run it, copy results back, proceed Maybe a good compromise. Not good for "embedded systems", but heck, is there any such thing any longer? Doesn't everything have megs of RAM and gigs of persistant storage? :) You don't need Scheme. Just Quake + compiling and running C code. Assuming a native build system. I've done stuff in cross build systems like: typedef struct foo_t {int i; int j; } foo_t; extern const int xi = offsetof(foo_t, i); compile that, and read the value of xi out of the .obj file. The .obj file reader was written in Perl. :) (Python not available.) but to do that here, I'd have to support multiple .obj file formats. - Jay> To: jay.krell at cornell.edu> Date: Mon, 12 Jan 2009 01:34:24 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?> > > You present it as a true tragic Dilemma.> > But isn't there a Third Way---to wit, can't you "Ask the Computer"> to do the work for you?> > Generate the code somehow... Parsing the C headers is an obvious> way but there may be others that are simpler, such as writing a> Modula-3 program to generate the cloned M3 headers, sorry, interfaces.> > If I had to do this I would use my Scheme interpreter that's coded> in Modula-3 to write a Scheme program to generate the headers. This> program could pull whatever tricks are deemed necessary and suitable,> down to the point of generating and compiling and running C programs> as necessary (or parsing C code, or reading tea leaves). But the> end result would be a set of interfaces written in "Pure Modula-3".> The process of running the header generator would also have very> few dependencies on anything outside the M3 distribution.> > Mika> > Jay writes:> >--_6117a048-9185-4c03-badb-ef8f93402268_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >This is what you "have to" chose between.> >Header cloning or C code (and C headers).> >=20> >CONST or VAR (or functions?)> >=20> >I'm going to likely make the Uerror change tonight.> >You can still veto it (er=2C vote against it :) )> >=20> >Possibly some convuluted C (enum/#undef)=2C or splitting the Modula-3> >at boundaries that weren't previously believed "natural".> >(See how SetupHandlers is ~two lines in Modula-3 and the rest in C=3B> >this is partly out of ignorance. I don't know how to write those> >two lines in C=3B and laziness=2C I didn't look into how).> >=20> >=20> >=20> >Remember I'm still staying away from mainstream platforms=2C> >so the value isn't what it might appear to be=2C but it is "stage setting"=> >=2C> >and the show might go on. :)> >=20> >=20> >Also=2C the dilemna does get more difficult now=2C with the little C header=> > cloning that remains.> >=20> >For example=2C look at Upthreads.i3.> >Mainly=2C look at function prototypes.> >Constants and types are "known problems".> >Prototypes are gray. They actually tend to be portable.> >=20> >For example:> >=20> >TYPE pid_t =3D INTEGER=3B> ><*EXTERNAL "m3_getpid*> PROCEDURE getpid():pid_t=3B> >=20> >or leave it alone?> >getpid is probably the worst example.> >It is so very portable declared in Modula-3.> >But still=2C imagine pid_t might be 16bits or 32 or 64.> >Writing a wrapper is more portable -- as long as the pid isn't stuff into s=> >ome record that the system defines.> >=20> >=20> >Again=2C Upthreads.i3.> >Would you like to see it reduced=2C or left alone?> >Only deal with the types and initializers=2C or also the prototypes?> >You know=2C I could write a little portable layer=2C where all the types ar=> >e pointers=2C always null initialized.> >It would buy /some/ portability=2C and cost some.> >=20> >=20> >Do you like the sem_t change? Partly? Not at all?> >There is one sem_t in the system. So I moved it to be in C code.> >Or=2C as I had it before=2C declared as the max size/align of all the platf=> >orms -- getting that right is the same work as getting it right "the old wa=> >y"=2C except if you make a mistake=2C odds are still good of it being ok.> >=20> >=20> >Should the line be drawn at generating the remaining headers=2C rather than=> > eliminating them?> >Uerror.i3 is easily generated. Good enough?> >=20> >Upthread.i3's types can be generated generally as records with opaque array=> >s with the right size and alignment.> >=20> >Other stuff can be generated or at least checked.> >e.g. to check that getpid is declared correctly=2C you can assign it to a f=> >unction pointer and see if that compiles.> >=20> >Perf on Uerror arguably doesn't matter.> >Is it only error handling code?Or do sockets often go down "error" paths=2C=> > because they are slow and you are waiting for more data?> >=20> >Anyway=2C point is=2C I agree for sure this is valuable=2C but I might be h=> >itting the "tail" of the approach and should switch=2C I'm not sure. I keep=> > saying that though=2C and then press further.> >=20> >=20> > - Jay> >> >> >> >From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon=2C 12 Jan 200=> >9 19:24:50 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a=> > type's existance but not enough to instantiate it?> >> >> >Point taken. We live in a C universe and so need to interact. I do think => >your work with the headers is useful=2C and I want it to continue. Especia=> >lly in simplifying ports.> >> >> >On 12 Jan 2009=2C at 19:18=2C Jay wrote:> >> >I don't think a development system without C headers is interesting.. Is it=> > really? The transform I apply at times is wherever there is interaction wi=> >th C code that is described by system-dependent headers=2C or perhaps even => >fairly system-independent headers outside the Modula-3 tree=2C either write=> > wrapper functions for the functionality in the headers (e.g. stat=2C waitp=> >id)=2C which can be done in a system-independent way=2C or move the Modula-=> >3<->C transition higher=2C which is also usually system-independent=2C e.g.=> > ThreadPThreadC_SetupHandlers. It is either that or clone the headers=2C wh=> >ich seems like the worse evil. There is always going to be a Modula-3<->C t=> >ransition=2C it is just a matter of where it occurs. - Jay> >> >CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.e=> >duSubject: Re: [M3devel] declaring a type's existance but not enough to ins=> >tantiate it?Date: Mon=2C 12 Jan 2009 12:32:15 +1100> >> >> >Jay=2C I really think you are bending over backwards too far just to be abl=> >e to shoe-horn things into C. I *like* having the transpar of C header fil=> >es expressed in Modula-3=2C *particularly* for system calls=2C where you mi=> >ght even be trying to build on a system that does not have the C header fil=> >es installed=2C even though the libraries exist and can be linked to. Fund=> >amentally=2C I think anytime the Modula-3 code is made less transparent you=> > should think hard about what you are doing. The same with the change of c=> >onstants to variables.> >> >I am getting very nervous that the changes you are making are destroying th=> >e clarity of the Modula-3 run-time code.> >> >In this particular case=2C you are wanting to use a Modula-3 parameter pass=> >ing mechanism on something that is not declared in Modula-3. Seems kind of=> > dubious to me. Also=2C I really don't like the idea of accessing external=> > variables in C.> >> >-- Tony> >> >On 12 Jan 2009=2C at 11:55=2C Jay wrote:> >> >I considered ADDRESS.However I think it still doesn't satisfy. I want to be=> > able to do this: TYPE Foo_t =3D something=3B<* EXTERNAL *> VAR Foo1=2C Foo=> >2:Foo_t=3B<* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t)=> >=3B (* Modula-3=2C not external *)PROCEDURE x()=3DBEGIN UseFoo(Foo1)=3B U=> >seFoo(Foo2)=3BEND x=3B AND I want any use of:VAR Foo3:Foo3_t=3B (* Modula-3=> >=2C not external *)to error. This is sem_t and sigset_t in particular. Poss=> >ibly renaming is the thing.They used to be declared in Modula-3=2C system-d=> >ependently=2C butI moved them to portable C. I could remove the types entir=> >ely and change UseFoo to take an address=2Cand declare mask and ackSem to b=> >e integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END=3B That would sat=> >isfy but I thought it might be nicer to still provide the namedtypes to ref=> >er to the external variables. - Jay> >> >From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon=2C 12 Jan 200=> >9 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a=> > type's existance but not enough to instantiate it?What's wrong with using => >ADDRESS for references to opaque values? If sigset_t is never instantiated=> > in Modula-3=2C then why do you need it declared there?> >> >> >> >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=2C at 01:44=2C Jay wrote:> >> >Is there a way in Modula-3 to declare that a type exists=2C and there are <=> >*external*> instances of it=2C without "fully" declaring it=2C so that no M=> >odula-3 can instantiate it? I have done this for sigset_t and sem_t=2C but => >they could erroneously be instantiated by Modula-3 and I'd like to remove t=> >hat ability to mess up so easily. (* This type is not declared correctly. I=> >t is only instantiated in C code. *) sigset_t =3D RECORD END=3B(* This typ=> >e is not declared correctly. It is only instantiated in C code. *) sem_t => >=3D RECORD END=3BIn C I believe you can do this=2C like: typedef struct fo=> >o foo_t=3B extern foo_t foo=3B void UseFoo(foo_t*)=3B foo_t* GetFoo=> >(void)=3B Thanks=2C - Jay=> >> >--_6117a048-9185-4c03-badb-ef8f93402268_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >> >This is what you "have to" chose between.
> >Header cloning or C code (and C headers).
> > =3B
> >CONST or VAR (or functions?)
> > =3B
> >I'm going to likely make the Uerror change tonight.
> >You can still veto it (er=2C vote against it :) )
> > =3B
> >Possibly some convuluted C (enum/#undef)=2C or splitting the Modula-3
> >at boundaries that weren't previously believed "natural".
> >(See how SetupHandlers is ~two lines in Modula-3 and the rest in C=3B
> >this is partly out of ignorance. I don't know how to write those
> >two lines in C=3B and laziness=2C I didn't look into how).
> > =3B
> > =3B
> > =3B
> >Remember I'm still staying away from mainstream platforms=2C
> >so the value isn't what it might appear to be=2C but it is "stage setting"=> >=2C
> >and the show might go on. :)
> > =3B
> > =3B
> >Also=2C the dilemna does get more difficult now=2C with the little C header=> > cloning that remains.
> > =3B
> >For example=2C look at Upthreads.i3.
> >Mainly=2C look at function prototypes.
> >Constants and types are "known problems".
> >Prototypes are gray. They actually tend to be portable.
> > =3B
> >For example:
> > =3B
> >TYPE pid_t =3D INTEGER=3B
> ><=3B*EXTERNAL "m3_getpid*>=3B PROCEDURE getpid():pid_t=3B
> > =3B
> >or leave it alone?
> >getpid is probably the worst example.
> >It is so very portable declared in Modula-3.
> >But still=2C imagine pid_t might be 16bits or 32 or 64.
> >Writing a wrapper is more portable -- as long as the pid isn't stuff into s=> >ome record that the system defines.
> > =3B
> > =3B
> >Again=2C Upthreads.i3.
> >Would you like to see it reduced=2C or left alone?
> >Only deal with the types and initializers=2C or also the prototypes?
> >You know=2C I could write a little portable layer=2C where all the types ar=> >e pointers=2C always null initialized.
> >It would buy /some/ portability=2C and cost some.
> > =3B
> > =3B
> >Do you like the sem_t change? Partly? Not at all?
> >There is one sem_t in the system. So I moved it to be in C code.
> >Or=2C as I had it before=2C declared as the max size/align of all the platf=> >orms -- getting that right is the same work as getting it right "the old wa=> >y"=2C except if you make a mistake=2C odds are still good of it being ok. >R>> > =3B
> > =3B
> >Should the line be drawn at generating the remaining headers=2C rather than=> > eliminating them?
> >Uerror.i3 is easily generated. Good enough?
> > =3B
> >Upthread.i3's types can be generated generally as records with opaque array=> >s with the right size and alignment.
> > =3B
> >Other stuff can be generated or at least checked.
> >e.g. to check that getpid is declared correctly=2C you can assign it to a f=> >unction pointer and see if that compiles.
> > =3B
> >Perf on Uerror arguably doesn't matter.
> >Is it only error handling code?
Or do sockets often go down "error" path=> >s=2C because they are slow and you are waiting for more data?
> > =3B
> >Anyway=2C point is=2C I agree for sure this is valuable=2C but I might be h=> >itting the "tail" of the approach and should switch=2C I'm not sure. I keep=> > saying that though=2C and then press further.
> > =3B
> > =3B
> > =3B- Jay

> >> >
>
> >From: hosking at cs.purdue.edu
To: jay.krell at cornell.edu
Date: Mon=2C 12=> > Jan 2009 19:24:50 +1100
CC: m3devel at elegosoft.com
Subject: Re: [M3de=> >vel] declaring a type's existance but not enough to instantiate it?

=> >
> >
>12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-IND=> >ENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPS=> >E: separate">> >
>e=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B C=> >OLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-S=> >PACING: normal=3B BORDER-COLLAPSE: separate"> >pan style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: n=> >one=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B => >LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate"> >-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRAN=> >SFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: no=> >rmal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate"> >EC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B T=> >EXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-S=> >PACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate"> >class=3DEC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvet=> >ica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B=> > WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate=> >"> >x Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT=> >: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: => >separate"> >ONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEX=> >T-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-CO=> >LLAPSE: separate"> >0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0=> >)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B B=> >ORDER-COLLAPSE: separate">> >
Point taken.  =3BWe live in a C universe and so need to interact. => > =3BI do think your work with the headers is useful=2C and I want it to=> > continue.  =3BEspecially in simplifying ports.
> >

 >V>
> >
> >
On 12 Jan 2009=2C at 19:18=2C Jay wrote:

>erchange-newline>> >
> FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B T=> >EXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-=> >COLLAPSE: separate">> >
>>I don't think a development system without C headers is interesting.. Is i=> >t really?
 =3B
The transform I apply at times is wherever there i=> >s interaction with C code that is described by system-dependent headers=2C => >or perhaps even fairly system-independent headers outside the Modula-3 tree=> >=2C either write wrapper functions for the functionality in the headers (e.=> >g. stat=2C waitpid)=2C which =3Bcan be done in a system-independent way=> >=2C =3Bor move the Modula-3<=3B->=3BC transition higher=2C which is=> > also usually system-independent=2C e.g. ThreadPThreadC_SetupHandlers.
&=> >nbsp=3B
It is either that or clone the headers=2C which seems like the w=> >orse evil.
 =3B
There is always going to be a Modula-3<=3B->=> >=3BC transition=2C it is just a matter of where it occurs.
 =3B
&=> >nbsp=3B- Jay

> >
> >
CC: =3B >lto:m3devel at elegosoft.com">m3devel at elegosoft.com
From: >EC_Apple-converted-space> =3B >.edu">hosking at cs.purdue.edu
To: >e> =3Bjay.krell at cornell=> >.edu
Subject: Re: [M3devel] declaring a type's existance but not eno=> >ugh to instantiate it?
Date: Mon=2C 12 Jan 2009 12:32:15 +1100

>R>>
>T: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-=> >INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLL=> >APSE: separate">> >
>tyle=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=> >=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LET=> >TER-SPACING: normal=3B BORDER-COLLAPSE: separate"> >-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRAN=> >SFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: no=> >rmal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate"> >EC_EC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=> >=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WH=> >ITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate"><=> >SPAN class=3DEC_EC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12p=> >x Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT=> >: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: => >separate"> >=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=> >=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BO=> >RDER-COLLAPSE: separate"> >-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb=> >(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: n=> >ormal=3B BORDER-COLLAPSE: separate"> >yle=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B=> > COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER=> >-SPACING: normal=3B BORDER-COLLAPSE: separate"> >yle-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFO=> >RM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: norma=> >l=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate">> >
Jay=2C I really think you are bending over backwards too far just to b=> >e able to shoe-horn things into C.  =3BI *like* having the transpar of => >C header files expressed in Modula-3=2C *particularly* for system calls=2C => >where you might even be trying to build on a system that does not have the => >C header files installed=2C even though the libraries exist and can be link=> >ed to.  =3BFundamentally=2C I think anytime the Modula-3 code is made l=> >ess transparent you should think hard about what you are doing.  =3BThe=> > same with the change of constants to variables.
> >

> >
I am getting very nervous that the changes you are making are destroyi=> >ng the clarity of the Modula-3 run-time code.
> >

> >
In this particular case=2C you are wanting to use a Modula-3 parameter=> > passing mechanism on something that is not declared in Modula-3.  =3BS=> >eems kind of dubious to me.  =3BAlso=2C I really don't like the idea of=> > accessing external variables in C.
> >

> >
-- Tony
<=> >/DIV>

> >
> >
On 12 Jan 2009=2C at 11:55=2C Jay wrote:

>interchange-newline>> >
>=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=> >=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BO=> >RDER-COLLAPSE: separate">> >
>na">I considered ADDRESS.
However I think it still doesn't satisfy.
&=> >nbsp=3B
I want to be able to do this:
 =3B
TYPE =3BFoo_t => >=3D something=3B
<=3B* EXTERNAL *>=3B VAR Foo1=2C Foo2:Foo_t=3B
&=> >lt=3B* EXTERNAL *>=3B PROCEDURE =3BUseFoo(READONLY (* or VAR *) foo:F=> >oo_t)=3B
 =3B
(* Modula-3=2C not external *)
PROCEDURE x()=3D<=> >BR>BEGIN
 =3B UseFoo(Foo1)=3B
 =3B UseFoo(Foo2)=3B
END x=> >=3B
 =3B
AND I want any use of:
VAR Foo3:Foo3_t=3B (* Modula-3=> >=2C not external *)

to error. This is sem_t and sigset_t in particul=> >ar.
 =3B
Possibly renaming is the thing.
They used to be decla=> >red in Modula-3=2C system-dependently=2C but
I moved them to portable C.=> >
 =3B
I could remove the types entirely and change UseFoo to take=> > an address=2C
and declare mask and ackSem to be integers or I guess. >><=3B*EXTERNAL>=3B VAR ackSem =3B: RECORD END=3B
 =3B
Tha=> >t would satisfy but I thought it might be nicer to still provide the named<=> >BR>types to refer to the external variables.
 =3B
 =3B- Jay >R>
> >
> >
From: =3B >=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu
To: >ss=3DEC_EC_Apple-converted-space> =3B >@cornell.edu">jay.krell at cornell.edu
Date: Mon=2C 12 Jan 2009 11:13:0=> >0 +1100
CC: =3B >ref=3D"mailto:m3devel at elegosoft.com">m3devel at elegosoft.com
Subject: => >Re: [M3devel] declaring a type's existance but not enough to instantiate it=> >?

What's wrong with using ADDRESS for references to opaque values? &=> >nbsp=3BIf sigset_t is never instantiated in Modula-3=2C then why do you nee=> >d it declared there?
> >

> >
>FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TE=> >XT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-C=> >OLLAPSE: separate">> >
>n style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: non=> >e=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LE=> >TTER-SPACING: normal=3B BORDER-COLLAPSE: separate"> >pple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-=> >TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE=> >: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate"> >s=3DEC_EC_EC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helv=> >etica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=> >=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separ=> >ate"> >FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TE=> >XT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-C=> >OLLAPSE: separate"> >ACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=> >=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: nor=> >mal=3B BORDER-COLLAPSE: separate"> >tyle=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=> >=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LET=> >TER-SPACING: normal=3B BORDER-COLLAPSE: separate"> >ple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-T=> >RANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE:=> > normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate"> >=3DEC_EC_EC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helve=> >tica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=> >=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separ=> >ate">> >
>EC_EC_EC_Apple-style-span face=3D"Gill Sans"> >tyle-span style=3D"COLOR: rgb(0=2C0=2C255)=3B FONT-FAMILY: 'Gill Sans'"> >AN class=3DEC_EC_EC_Apple-style-span style=3D"COLOR: rgb(0=2C0=2C255)=3B FO=> >NT-FAMILY: 'Gill Sans'">Antony Hosking >ss=3DEC_EC_EC_Apple-style-span face=3D"Gill Sans"> >ple-style-span style=3D"FONT-FAMILY: 'Gill Sans'"> >ple-style-span style=3D"FONT-FAMILY: 'Gill Sans'"> >-converted-space> =3B|=> > =3B >=3D"FONT-FAMILY: 'Gill Sans'"> >=3D"FONT-FAMILY: 'Gill Sans'">Associate Professor >=3DEC_EC_EC_Apple-style-span style=3D"FONT-FAMILY: 'Gill Sans'"> >=3DEC_EC_EC_Apple-style-span style=3D"FONT-FAMILY: 'Gill Sans'"> =3B| C=> >omputer Science | Purdue University
> >
>ass=3DEC_EC_EC_Apple-style-span style=3D"FONT-FAMILY: GillSans-Light">305 N=> >. University Street | West Lafayette | IN 47907 | USA
> >
>00ff> >5)=3B FONT-FAMILY: 'Gill Sans'"> >le=3D"COLOR: rgb(0=2C0=2C255)=3B FONT-FAMILY: 'Gill Sans'">Office >PAN> >PAN class=3DEC_EC_EC_Apple-style-span style=3D"FONT-FAMILY: GillSans-Light"=> >> >ht"> =3B+1 765 494 6001 |&nbs=> >p=3B >e=3D"Gill Sans" color=3D#0000ff> >le=3D"COLOR: rgb(0=2C0=2C255)=3B FONT-FAMILY: 'Gill Sans'"> >_EC_EC_Apple-style-span style=3D"COLOR: rgb(0=2C0=2C255)=3B FONT-FAMILY: 'G=> >ill Sans'">Mobile >an face=3DGillSans-Light> >ONT-FAMILY: GillSans-Light"> >=3D"FONT-FAMILY: GillSans-Light">=> > =3B+1 765 427 5484
> >

>s=3DEC_EC_EC_khtml-block-placeholder>
 >AN>
>AN>

> >
> >
On 12 Jan 2009=2C at 01:44=2C Jay wrote:

>le-interchange-newline>> >
>0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0=> >)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B B=> >ORDER-COLLAPSE: separate">> >
>rdana">Is there a way in Modula-3 to declare that =3Ba type exists=2C a=> >nd there are <=3B*external*>=3B instances of it=2C without "fully" decl=> >aring it=2C so that no Modula-3 can instantiate it?
 =3B
I have d=> >one this for sigset_t and sem_t=2C but they could erroneously be instantiat=> >ed by Modula-3 and I'd like to remove that ability to mess up so easily. >> =3B
(* This type is not declared correctly. It is only instantiate=> >d in C code. *)
 =3B sigset_t =3D RECORD END=3B

(* This type => >is not declared correctly. It is only instantiated in C code. *)
 => >=3B sem_t =3D RECORD END=3B

In C I believe you can do this=2C like:<=> >BR> =3B =3Btypedef struct foo foo_t=3B =3B >C_Apple-converted-space> =3B
 =3B =3Bextern foo_t foo=> >=3B =3B =3B
=> > =3B
 =3Bvoid UseFoo(foo_t*)=3B >erted-space> =3B
 =3B foo_t* GetFoo(void)=3B >=3DEC_EC_EC_Apple-converted-space> =3B
 =3B
Thanks=2C<=> >BR> =3B- Jay




<=> >/DIV>
=> >

>V>
> >=> >> >--_6117a048-9185-4c03-badb-ef8f93402268_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Jan 12 11:13:25 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 12 Jan 2009 02:13:25 -0800 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: Your message of "Mon, 12 Jan 2009 09:56:43 GMT." Message-ID: <200901121013.n0CADQE0075969@camembert.async.caltech.edu> I think you're misunderstanding me a bit. You don't need C either. I would use a Lisp-based language for the "top level" just because they are good at handling things like parse trees, if one gets to that. The objectives are: * A finished system in Pure Modula-3 (no executable C) * Make it as self-contained as possible You'd start by simply bundling the existing headers with m3bundle and printing them out. Then you'd find duplication (what you've been doing) and express that programmatically. Then you might find things that might conceivably change in the OS headers and use whatever tricks were necessary to figure them out automatically. Does this involve C? Maybe on some architecture it does, maybe on another it doesn't. On some it might not involve running C but merely parsing C headers. Perhaps the program is just hand-written and just a way of distilling all the duplication into one place where it can be clearly described and documented. Since this is a Modula-3 distribution, obviously the program I'm talking about is written in Modula-3, not in C or Perl or Python. Mika Jay writes: >--_2e194b09-14b6-4301-9116-a9e4d1e522b4_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Yes=2C generating the headers is viable. >I thought I mentioned that a few times. >They could be generated in any build "that can". i.e. a native build=2C th= >at has a working C development system and checked against the checked in o= >nes. > So then porting is: copy the generator to new system=2C run it=2C copy r= >esults back=2C proceed=20 > Maybe a good compromise. Not good for "embedded systems"=2C but heck=2C i= >s there any such thing any longer? Doesn't everything have megs of RAM and= > gigs of persistant storage? :) >You don't need Scheme. >Just Quake + compiling and running C code. >Assuming a native build system. >I've done stuff in cross build systems like: >typedef struct foo_t {int i=3B int j=3B } foo_t=3B >extern const int xi =3D offsetof(foo_t=2C i)=3B >=20 >compile that=2C and read the value of xi out of the .obj file. >=20 > The .obj file reader was written in Perl. :)=20 > (Python not available.) > but to do that here=2C I'd have to support multiple .obj file formats. >=20 > - Jay> To: jay.krell at cornell.edu> Date: Mon=2C 12 Jan 2009 01:34:24 -0800>= > From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3d= >evel] declaring a type's existance but not enough to instantiate it?> > > Y= >ou present it as a true tragic Dilemma.> > But isn't there a Third Way---to= > wit=2C can't you "Ask the Computer"> to do the work for you?> > Generate t= >he code somehow... Parsing the C headers is an obvious> way but there may b= >e others that are simpler=2C such as writing a> Modula-3 program to generat= >e the cloned M3 headers=2C sorry=2C interfaces.> > If I had to do this I wo= >uld use my Scheme interpreter that's coded> in Modula-3 to write a Scheme p= >rogram to generate the headers. This> program could pull whatever tricks ar= >e deemed necessary and suitable=2C> down to the point of generating and com= >piling and running C programs> as necessary (or parsing C code=2C or readin= >g tea leaves). But the> end result would be a set of interfaces written in = >"Pure Modula-3".> The process of running the header generator would also ha= >ve very> few dependencies on anything outside the M3 distribution.> > Mika>= > > Jay writes:> >--_6117a048-9185-4c03-badb-ef8f93402268_> >Content-Type: t= >ext/plain=3B charset=3D"iso-8859-1"> >Content-Transfer-Encoding: quoted-pri= >ntable> >> >> >This is what you "have to" chose between.> >Header cloning o= >r C code (and C headers).> >=3D20> >CONST or VAR (or functions?)> >=3D20> >= >I'm going to likely make the Uerror change tonight.> >You can still veto it= > (er=3D2C vote against it :) )> >=3D20> >Possibly some convuluted C (enum/#= >undef)=3D2C or splitting the Modula-3> >at boundaries that weren't previous= >ly believed "natural".> >(See how SetupHandlers is ~two lines in Modula-3 a= >nd the rest in C=3D3B> >this is partly out of ignorance. I don't know how t= >o write those> >two lines in C=3D3B and laziness=3D2C I didn't look into ho= >w).> >=3D20> >=3D20> >=3D20> >Remember I'm still staying away from mainstre= >am platforms=3D2C> >so the value isn't what it might appear to be=3D2C but = >it is "stage setting"=3D> >=3D2C> >and the show might go on. :)> >=3D20> >= >=3D20> >Also=3D2C the dilemna does get more difficult now=3D2C with the lit= >tle C header=3D> > cloning that remains.> >=3D20> >For example=3D2C look at= > Upthreads.i3.> >Mainly=3D2C look at function prototypes.> >Constants and t= >ypes are "known problems".> >Prototypes are gray. They actually tend to be = >portable.> >=3D20> >For example:> >=3D20> >TYPE pid_t =3D3D INTEGER=3D3B> >= ><*EXTERNAL "m3_getpid*> PROCEDURE getpid():pid_t=3D3B> >=3D20> >or leave it= > alone?> >getpid is probably the worst example.> >It is so very portable de= >clared in Modula-3.> >But still=3D2C imagine pid_t might be 16bits or 32 or= > 64.> >Writing a wrapper is more portable -- as long as the pid isn't stuff= > into s=3D> >ome record that the system defines.> >=3D20> >=3D20> >Again=3D= >2C Upthreads.i3.> >Would you like to see it reduced=3D2C or left alone?> >O= >nly deal with the types and initializers=3D2C or also the prototypes?> >You= > know=3D2C I could write a little portable layer=3D2C where all the types a= >r=3D> >e pointers=3D2C always null initialized.> >It would buy /some/ porta= >bility=3D2C and cost some.> >=3D20> >=3D20> >Do you like the sem_t change? = >Partly? Not at all?> >There is one sem_t in the system. So I moved it to be= > in C code.> >Or=3D2C as I had it before=3D2C declared as the max size/alig= >n of all the platf=3D> >orms -- getting that right is the same work as gett= >ing it right "the old wa=3D> >y"=3D2C except if you make a mistake=3D2C odd= >s are still good of it being ok.> >=3D20> >=3D20> >Should the line be drawn= > at generating the remaining headers=3D2C rather than=3D> > eliminating the= >m?> >Uerror.i3 is easily generated. Good enough?> >=3D20> >Upthread.i3's ty= >pes can be generated generally as records with opaque array=3D> >s with the= > right size and alignment.> >=3D20> >Other stuff can be generated or at lea= >st checked.> >e.g. to check that getpid is declared correctly=3D2C you can = >assign it to a f=3D> >unction pointer and see if that compiles.> >=3D20> >P= >erf on Uerror arguably doesn't matter.> >Is it only error handling code?Or = >do sockets often go down "error" paths=3D2C=3D> > because they are slow and= > you are waiting for more data?> >=3D20> >Anyway=3D2C point is=3D2C I agree= > for sure this is valuable=3D2C but I might be h=3D> >itting the "tail" of = >the approach and should switch=3D2C I'm not sure. I keep=3D> > saying that = >though=3D2C and then press further.> >=3D20> >=3D20> > - Jay> >> >> >> >Fro= >m: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon=3D2C 12 Jan 200= >=3D> >9 19:24:50 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] decla= >ring a=3D> > type's existance but not enough to instantiate it?> >> >> >Poi= >nt taken. We live in a C universe and so need to interact. I do think =3D> = >>your work with the headers is useful=3D2C and I want it to continue. Espec= >ia=3D> >lly in simplifying ports.> >> >> >On 12 Jan 2009=3D2C at 19:18=3D2C= > Jay wrote:> >> >I don't think a development system without C headers is in= >teresting.. Is it=3D> > really? The transform I apply at times is wherever = >there is interaction wi=3D> >th C code that is described by system-dependen= >t headers=3D2C or perhaps even =3D> >fairly system-independent headers outs= >ide the Modula-3 tree=3D2C either write=3D> > wrapper functions for the fun= >ctionality in the headers (e.g. stat=3D2C waitp=3D> >id)=3D2C which can be = >done in a system-independent way=3D2C or move the Modula-=3D> >3<->C transi= >tion higher=3D2C which is also usually system-independent=3D2C e.g.=3D> > T= >hreadPThreadC_SetupHandlers. It is either that or clone the headers=3D2C wh= >=3D> >ich seems like the worse evil. There is always going to be a Modula-3= ><->C t=3D> >ransition=3D2C it is just a matter of where it occurs. - Jay> >= >> >CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornel= >l.e=3D> >duSubject: Re: [M3devel] declaring a type's existance but not enou= >gh to ins=3D> >tantiate it?Date: Mon=3D2C 12 Jan 2009 12:32:15 +1100> >> >>= > >Jay=3D2C I really think you are bending over backwards too far just to be= > abl=3D> >e to shoe-horn things into C. I *like* having the transpar of C h= >eader fil=3D> >es expressed in Modula-3=3D2C *particularly* for system call= >s=3D2C where you mi=3D> >ght even be trying to build on a system that does = >not have the C header fil=3D> >es installed=3D2C even though the libraries = >exist and can be linked to. Fund=3D> >amentally=3D2C I think anytime the Mo= >dula-3 code is made less transparent you=3D> > should think hard about what= > you are doing. The same with the change of c=3D> >onstants to variables.> = >>> >I am getting very nervous that the changes you are making are destroyin= >g th=3D> >e clarity of the Modula-3 run-time code.> >> >In this particular = >case=3D2C you are wanting to use a Modula-3 parameter pass=3D> >ing mechani= >sm on something that is not declared in Modula-3. Seems kind of=3D> > dubio= >us to me. Also=3D2C I really don't like the idea of accessing external=3D> = >> variables in C.> >> >-- Tony> >> >On 12 Jan 2009=3D2C at 11:55=3D2C Jay w= >rote:> >> >I considered ADDRESS.However I think it still doesn't satisfy. I= > want to be=3D> > able to do this: TYPE Foo_t =3D3D something=3D3B<* EXTERN= >AL *> VAR Foo1=3D2C Foo=3D> >2:Foo_t=3D3B<* EXTERNAL *> PROCEDURE UseFoo(RE= >ADONLY (* or VAR *) foo:Foo_t)=3D> >=3D3B (* Modula-3=3D2C not external *)P= >ROCEDURE x()=3D3DBEGIN UseFoo(Foo1)=3D3B U=3D> >seFoo(Foo2)=3D3BEND x=3D3B = >AND I want any use of:VAR Foo3:Foo3_t=3D3B (* Modula-3=3D> >=3D2C not exter= >nal *)to error. This is sem_t and sigset_t in particular. Poss=3D> >ibly re= >naming is the thing.They used to be declared in Modula-3=3D2C system-d=3D> = >>ependently=3D2C butI moved them to portable C. I could remove the types en= >tir=3D> >ely and change UseFoo to take an address=3D2Cand declare mask and = >ackSem to b=3D> >e integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END= >=3D3B That would sat=3D> >isfy but I thought it might be nicer to still pro= >vide the namedtypes to ref=3D> >er to the external variables. - Jay> >> >Fr= >om: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon=3D2C 12 Jan 200= >=3D> >9 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] decla= >ring a=3D> > type's existance but not enough to instantiate it?What's wrong= > with using =3D> >ADDRESS for references to opaque values? If sigset_t is n= >ever instantiated=3D> > in Modula-3=3D2C then why do you need it declared t= >here?> >> >> >> >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 200= >9=3D2C at 01:44=3D2C Jay wrote:> >> >Is there a way in Modula-3 to declare = >that a type exists=3D2C and there are <=3D> >*external*> instances of it=3D= >2C without "fully" declaring it=3D2C so that no M=3D> >odula-3 can instanti= >ate it? I have done this for sigset_t and sem_t=3D2C but =3D> >they could e= >rroneously be instantiated by Modula-3 and I'd like to remove t=3D> >hat ab= >ility to mess up so easily. (* This type is not declared correctly. I=3D> >= >t is only instantiated in C code. *) sigset_t =3D3D RECORD END=3D3B(* This = >typ=3D> >e is not declared correctly. It is only instantiated in C code. *)= > sem_t =3D> >=3D3D RECORD END=3D3BIn C I believe you can do this=3D2C like:= > typedef struct fo=3D> >o foo_t=3D3B extern foo_t foo=3D3B void UseFoo(foo_= >t*)=3D3B foo_t* GetFoo=3D> >(void)=3D3B Thanks=3D2C - Jay=3D> >> >--_6117a0= >48-9185-4c03-badb-ef8f93402268_> >Content-Type: text/html=3B charset=3D"iso= >-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >= >> >> ><= >/head>> >> >This is what you "have to" chose be= >tween.
> >Header cloning or C code (and C headers).
> > =3D3B
= >> >CONST or VAR (or functions?)
> > =3D3B
> >I'm going to likely = >make the Uerror change tonight.
> >You can still veto it (er=3D2C vote a= >gainst it :) )
> > =3D3B
> >Possibly some convuluted C (enum/#und= >ef)=3D2C or splitting the Modula-3
> >at boundaries that weren't previou= >sly believed "natural".
> >(See how SetupHandlers is ~two lines in Modul= >a-3 and the rest in C=3D3B
> >this is partly out of ignorance. I don't k= >now how to write those
> >two lines in C=3D3B and laziness=3D2C I didn't= > look into how).
> > =3D3B
> > =3D3B
> > =3D3B
> >R= >emember I'm still staying away from mainstream platforms=3D2C
> >so the = >value isn't what it might appear to be=3D2C but it is "stage setting"=3D> >= >=3D2C
> >and the show might go on. :)
> > =3D3B
> > =3D3B<= >BR>> >Also=3D2C the dilemna does get more difficult now=3D2C with the littl= >e C header=3D> > cloning that remains.
> > =3D3B
> >For example= >=3D2C look at Upthreads.i3.
> >Mainly=3D2C look at function prototypes.<= >BR>> >Constants and types are "known problems".
> >Prototypes are gray. = >They actually tend to be portable.
> > =3D3B
> >For example:
>= > > =3D3B
> >TYPE pid_t =3D3D INTEGER=3D3B
> ><=3D3B*EXTERNAL "m= >3_getpid*>=3D3B PROCEDURE getpid():pid_t=3D3B
> > =3D3B
> >or l= >eave it alone?
> >getpid is probably the worst example.
> >It is so v= >ery portable declared in Modula-3.
> >But still=3D2C imagine pid_t might= > be 16bits or 32 or 64.
> >Writing a wrapper is more portable -- as long= > as the pid isn't stuff into s=3D> >ome record that the system defines.
= >> > =3D3B
> > =3D3B
> >Again=3D2C Upthreads.i3.
> >Would y= >ou like to see it reduced=3D2C or left alone?
> >Only deal with the type= >s and initializers=3D2C or also the prototypes?
> >You know=3D2C I could= > write a little portable layer=3D2C where all the types ar=3D> >e pointers= >=3D2C always null initialized.
> >It would buy /some/ portability=3D2C a= >nd cost some.
> > =3D3B
> > =3D3B
> >Do you like the sem_t= > change? Partly? Not at all?
> >There is one sem_t in the system. So I m= >oved it to be in C code.
> >Or=3D2C as I had it before=3D2C declared as = >the max size/align of all the platf=3D> >orms -- getting that right is the = >same work as getting it right "the old wa=3D> >y"=3D2C except if you make a= > mistake=3D2C odds are still good of it being ok. >R>> > =3D3B>> > =3D3B
> >Should the line be drawn at generating the remaining h= >eaders=3D2C rather than=3D> > eliminating them?
> >Uerror.i3 is easily g= >enerated. Good enough?
> > =3D3B
> >Upthread.i3's types can be ge= >nerated generally as records with opaque array=3D> >s with the right size a= >nd alignment.
> > =3D3B
> >Other stuff can be generated or at lea= >st checked.
> >e.g. to check that getpid is declared correctly=3D2C you = >can assign it to a f=3D> >unction pointer and see if that compiles.
> >&= >nbsp=3D3B
> >Perf on Uerror arguably doesn't matter.
> >Is it only er= >ror handling code?
Or do sockets often go down "error" path=3D> >s=3D2C = >because they are slow and you are waiting for more data?
> > =3D3BR>> >Anyway=3D2C point is=3D2C I agree for sure this is valuable=3D2C but I= > might be h=3D> >itting the "tail" of the approach and should switch=3D2C I= >'m not sure. I keep=3D> > saying that though=3D2C and then press further.R>> > =3D3B
> > =3D3B
> > =3D3B- Jay

> >> >
=3D3DstopSpelling>>
> >From: hosking at cs.purdue.edu
To: jay.krell at cor= >nell.edu
Date: Mon=3D2C 12=3D> > Jan 2009 19:24:50 +1100
CC: m3devel@= >elegosoft.com
Subject: Re: [M3de=3D> >vel] declaring a type's existance = >but not enough to instantiate it?

=3D> >
> >
EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: =3D> >12px Helv= >etica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-IN= >D=3D> >ENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B B= >ORDER-COLLAPS=3D> >E: separate">> >
<= >SPAN class=3D3DEC_Apple-style-span styl=3D> >e=3D3D"WORD-SPACING: 0px=3D3B = >FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B C=3D> >OLOR: rgb(0=3D2C= >0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-S=3D> >= >PACING: normal=3D3B BORDER-COLLAPSE: separate">le-s=3D> >pan style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B T= >EXT-TRANSFORM: n=3D> >one=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: = >0px=3D3B WHITE-SPACE: normal=3D3B =3D> >LETTER-SPACING: normal=3D3B BORDER-= >COLLAPSE: separate"> >-style-span style=3D3D"WO= >RD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRAN=3D> >SFORM: none= >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: no= >=3D> >rmal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate">N class=3D3D=3D> >EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FON= >T: 12px Helvetica=3D3B T=3D> >EXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0= >=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-S=3D> >PACE: normal=3D3B LETTER-SP= >ACING: normal=3D3B BORDER-COLLAPSE: separate"> >class=3D3DEC_Appl= >e-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvet=3D> >ica= >=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT:= > 0px=3D3B=3D> > WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER= >-COLLAPSE: separate=3D> >">ORD-SPACING: 0px=3D3B FONT: 12p=3D> >x Helvetica=3D3B TEXT-TRANSFORM: none= >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT=3D> >: 0px=3D3B WHITE-SPAC= >E: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: =3D> >separate"= >>> >ONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D= >2C0)=3D3B TEX=3D> >T-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACI= >NG: normal=3D3B BORDER-CO=3D> >LLAPSE: separate">tyle-span style=3D3D"WORD-SPACING: =3D> >0px=3D3B FONT: 12px Helvetica=3D3B= > TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0=3D> >)=3D3B TEXT-INDENT= >: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B B=3D> >ORDE= >R-COLLAPSE: separate">> >
Point taken.  =3D3BWe live in a C univers= >e and so need to interact. =3D> > =3D3BI do think your work with the he= >aders is useful=3D2C and I want it to=3D> > continue.  =3D3BEspecially = >in simplifying ports.
> >

SPAN> >V>
> >
> >
On 12 Ja= >n 2009=3D2C at 19:18=3D2C Jay wrote:

>e= >rchange-newline>> >
3D"WORD-SPACING: 0px=3D3B=3D> > FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: n= >one=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B T=3D> >EXT-INDENT: 0px=3D3B WHITE-S= >PACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-=3D> >COLLAPSE: separa= >te">> >
ILY: Verdana"=3D> >>I don't think a development system without C headers is= > interesting.. Is i=3D> >t really?
 =3D3B
The transform I apply a= >t times is wherever there i=3D> >s interaction with C code that is describe= >d by system-dependent headers=3D2C =3D> >or perhaps even fairly system-inde= >pendent headers outside the Modula-3 tree=3D> >=3D2C either write wrapper f= >unctions for the functionality in the headers (e.=3D> >g. stat=3D2C waitpid= >)=3D2C which =3D3Bcan be done in a system-independent way=3D> >=3D2C&nb= >sp=3D3Bor move the Modula-3<=3D3B->=3D3BC transition higher=3D2C which = >is=3D> > also usually system-independent=3D2C e.g. ThreadPThreadC_SetupHand= >lers.
&=3D> >nbsp=3D3B
It is either that or clone the headers=3D2C wh= >ich seems like the w=3D> >orse evil.
 =3D3B
There is always going= > to be a Modula-3<=3D3B->=3D> >=3D3BC transition=3D2C it is just a matt= >er of where it occurs.
 =3D3B
&=3D> >nbsp=3D3B- Jay

> > id=3D3DEC_stopSpelling>> >
CC:= > =3D3B >lto:m3devel at elegosoft.com">m3devel at e= >legosoft.com
From: >EC_Apple-converted-space>&nb= >sp=3D3B >.edu">hosking at cs.p= >urdue.edu
To: >e> =3D= >3Bjay.krell at cornell=3D> >= >.edu
Subject: Re: [M3devel] declaring a type's existance but not eno= >=3D> >ugh to instantiate it?
Date: Mon=3D2C 12 Jan 2009 12:32:15 +1100R>
>R>>
RD-SPACING: 0px=3D3B FON=3D> >T: 12px Helvetica=3D3B TEXT-TRANSFORM: none= >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-=3D> >INDENT: 0px=3D3B WHITE-SPAC= >E: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLL=3D> >APSE: separate"= >>> >
e-span s=3D> >tyle=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TE= >XT-TRANSFORM: none=3D> >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0= >px=3D3B WHITE-SPACE: normal=3D3B LET=3D> >TER-SPACING: normal=3D3B BORDER-C= >OLLAPSE: separate"> >-style-span style=3D3D"= >WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRAN=3D> >SFORM: none= >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: no= >=3D> >rmal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate">N class=3D3D=3D> >EC_EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B = >FONT: 12px Helvetica=3D> >=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C= >0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WH=3D> >ITE-SPACE: normal=3D3B LETTER-S= >PACING: normal=3D3B BORDER-COLLAPSE: separate"><=3D> >SPAN class=3D3DEC_EC_= >Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12p=3D> >x Helveti= >ca=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDEN= >T=3D> >: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORD= >ER-COLLAPSE: =3D> >separate">=3D3D"WORD-SPACING: 0px=3D> >=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM= >: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D> >=3D3B TEXT-INDENT: 0px=3D3B WHIT= >E-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BO=3D> >RDER-COLLAPSE: sep= >arate"> >-SPACING= >: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb= >=3D> >(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B L= >ETTER-SPACING: n=3D> >ormal=3D3B BORDER-COLLAPSE: separate">DEC_EC_Apple-style-span st=3D> >yle=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px = >Helvetica=3D3B TEXT-TRANSFORM: none=3D3B=3D> > COLOR: rgb(0=3D2C0=3D2C0)=3D= >3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER=3D> >-SPACING: nor= >mal=3D3B BORDER-COLLAPSE: separate"> >yle= >-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRAN= >SFO=3D> >RM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B= > WHITE-SPACE: norma=3D> >l=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE= >: separate">> >
Jay=3D2C I really think you are bending over backwards = >too far just to b=3D> >e able to shoe-horn things into C.  =3D3BI *like= >* having the transpar of =3D> >C header files expressed in Modula-3=3D2C *p= >articularly* for system calls=3D2C =3D> >where you might even be trying to = >build on a system that does not have the =3D> >C header files installed=3D2= >C even though the libraries exist and can be link=3D> >ed to.  =3D3BFun= >damentally=3D2C I think anytime the Modula-3 code is made l=3D> >ess transp= >arent you should think hard about what you are doing.  =3D3BThe=3D> > s= >ame with the change of constants to variables.
> >

> >IV>I am getting very nervous that the changes you are making are destroyi= >=3D> >ng the clarity of the Modula-3 run-time code.
> >

= >> >
In this particular case=3D2C you are wanting to use a Modula-3 para= >meter=3D> > passing mechanism on something that is not declared in Modula-3= >.  =3D3BS=3D> >eems kind of dubious to me.  =3D3BAlso=3D2C I really= > don't like the idea of=3D> > accessing external variables in C.
> >IV>
> >
-- Tony
><=3D> >/DIV>

> >
> >
On 12 Jan 2009= >=3D2C at 11:55=3D2C Jay wrote:

>interch= >ange-newline>> >
3D"WORD-SPACING: 0px=3D> >=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: n= >one=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D> >=3D3B TEXT-INDENT: 0px=3D3B WHITE-S= >PACE: normal=3D3B LETTER-SPACING: normal=3D3B BO=3D> >RDER-COLLAPSE: separa= >te">> >
FAMILY: Verda=3D> >na">I considered ADDRESS.
However I think it still do= >esn't satisfy.
&=3D> >nbsp=3D3B
I want to be able to do this:
&nbs= >p=3D3B
TYPE =3D3BFoo_t =3D> >=3D3D something=3D3B
<=3D3B* EXTER= >NAL *>=3D3B VAR Foo1=3D2C Foo2:Foo_t=3D3B
&=3D> >lt=3D3B* EXTERNAL *&g= >t=3D3B PROCEDURE =3D3BUseFoo(READONLY (* or VAR *) foo:F=3D> >oo_t)=3D3= >B
 =3D3B
(* Modula-3=3D2C not external *)
PROCEDURE x()=3D3D<= >=3D> >BR>BEGIN
 =3D3B UseFoo(Foo1)=3D3B
 =3D3B UseFoo(Foo2)= >=3D3B
END x=3D> >=3D3B
 =3D3B
AND I want any use of:
VAR Fo= >o3:Foo3_t=3D3B (* Modula-3=3D> >=3D2C not external *)

to error. This= > is sem_t and sigset_t in particul=3D> >ar.
 =3D3B
Possibly renam= >ing is the thing.
They used to be decla=3D> >red in Modula-3=3D2C system= >-dependently=3D2C but
I moved them to portable C.=3D> >
 =3D3B>I could remove the types entirely and change UseFoo to take=3D> > an addre= >ss=3D2C
and declare mask and ackSem to be integers or I guess. >>= ><=3D3B*EXTERNAL>=3D3B VAR ackSem =3D3B: RECORD END=3D3B
 =3D= >3B
Tha=3D> >t would satisfy but I thought it might be nicer to still pro= >vide the named<=3D> >BR>types to refer to the external variables.
 = >=3D3B
 =3D3B- Jay >R>
> >
> ><= >BR>From: =3D3Bf=3D> >=3D3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu
To:= > >ss=3D3DEC_EC_Apple-converted-space> =3D3B=3D3D"mailto:jay.krell=3D> >@cornell.edu">jay.krell at cornell.edu
Date= >: Mon=3D2C 12 Jan 2009 11:13:0=3D> >0 +1100
CC:le-converted-space> =3D3B >ref=3D3D"mailto:m3devel at elego= >soft.com">m3devel at elegosoft.com
Subject: =3D> >Re: [M3devel] declari= >ng a type's existance but not enough to instantiate it=3D> >?

What's= > wrong with using ADDRESS for references to opaque values? &=3D> >nbsp=3D3B= >If sigset_t is never instantiated in Modula-3=3D2C then why do you nee=3D> = >>d it declared there?
> >

> >
-style-span style=3D3D"WORD-SPACING: 0px=3D3B =3D> >FONT: 12px Helvetica=3D= >3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TE=3D> >XT-INDE= >NT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-C= >=3D> >OLLAPSE: separate">> >
ass=3D3DEC_EC_EC_Apple-style-spa=3D> >n style=3D3D"WORD-SPACING: 0px=3D3B F= >ONT: 12px Helvetica=3D3B TEXT-TRANSFORM: non=3D> >e=3D3B COLOR: rgb(0=3D2C0= >=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LE=3D> >TTER-SP= >ACING: normal=3D3B BORDER-COLLAPSE: separate">> >pple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica= >=3D3B TEXT-=3D> >TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-I= >NDENT: 0px=3D3B WHITE-SPACE=3D> >: normal=3D3B LETTER-SPACING: normal=3D3B = >BORDER-COLLAPSE: separate"> >s=3D3DEC_EC_EC_Apple-style-span = >style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helv=3D> >etica=3D3B TEXT-TRAN= >SFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D> >=3D3B= > WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: sepa= >r=3D> >ate">NG: 0px=3D3B =3D> >FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLO= >R: rgb(0=3D2C0=3D2C0)=3D3B TE=3D> >XT-INDENT: 0px=3D3B WHITE-SPACE: normal= >=3D3B LETTER-SPACING: normal=3D3B BORDER-C=3D> >OLLAPSE: separate">ass=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SP=3D> >ACING: 0px=3D3B F= >ONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D> >=3D2C0= >=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING:= > nor=3D> >mal=3D3B BORDER-COLLAPSE: separate">e-style-span s=3D> >tyle=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica= >=3D3B TEXT-TRANSFORM: none=3D> >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-I= >NDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LET=3D> >TER-SPACING: normal=3D3B = >BORDER-COLLAPSE: separate"> >ple-style-span = >style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-T=3D> >RAN= >SFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE= >-SPACE:=3D> > normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: sepa= >rate"> >=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SPACI= >NG: 0px=3D3B FONT: 12px Helve=3D> >tica=3D3B TEXT-TRANSFORM: none=3D3B COLO= >R: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D> >=3D3B WHITE-SPACE: normal= >=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separ=3D> >ate">> >
= >D=3D> >EC_EC_EC_Apple-style-span face=3D3D"Gill Sans">_EC_Apple-s=3D> >tyle-span style=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=3D3B FONT= >-FAMILY: 'Gill Sans'"> >AN class=3D3DEC_EC_EC_Apple-style-span style= >=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=3D3B FO=3D> >NT-FAMILY: 'Gill Sans'">Anto= >ny Hosking >ss=3D3DEC_EC_EC_Apple-= >style-span face=3D3D"Gill Sans"> >ple-style-= >span style=3D3D"FONT-FAMILY: 'Gill Sans'"> >= >ple-style-span style=3D3D"FONT-FAMILY: 'Gill Sans'">pple=3D> >-converted-space> =3D3B|nverted-space>=3D> > =3D3B_Apple-style-span style=3D> >=3D3D"FONT-FAMILY: 'Gill Sans'">3DEC_EC_EC_Apple-style-span style=3D> >=3D3D"FONT-FAMILY: 'Gill Sans'">Asso= >ciate Professor >=3D3DEC_EC_EC_Apple-style-spa= >n style=3D3D"FONT-FAMILY: 'Gill Sans'"> >=3D3DEC_EC_EC_Apple= >-style-span style=3D3D"FONT-FAMILY: 'Gill Sans'"> =3D3B| C=3D> >omputer= > Science | Purdue University
> >
=3D3DEC_EC_EC_Apple-style-span face=3D3DGillSans-Light> >ass=3D= >3DEC_EC_EC_Apple-style-span style=3D3D"FONT-FAMILY: GillSans-Light">305 N= >=3D> >. University Street | West Lafayette | IN 47907 | USADIV>> >
color=3D3D#00=3D> >00ff>D"COLOR: rgb(0=3D2C0=3D2C25=3D> >5)=3D3B FONT-FAMILY: 'Gill Sans'">ass=3D3DEC_EC_EC_Apple-style-span sty=3D> >le=3D3D"COLOR: rgb(0=3D2C0=3D2C2= >55)=3D3B FONT-FAMILY: 'Gill Sans'">Office >PAN>lass=3D3DEC_EC_EC_Apple-style-span face=3D3DGillSans-Light> >PAN clas= >s=3D3DEC_EC_EC_Apple-style-span style=3D3D"FONT-FAMILY: GillSans-Light"=3D>= > >>ns-Lig=3D> >ht"> =3D3B+1 765 494 6001 |erted-space>&nbs=3D> >p=3D3BEC_EC_Apple-style-span fac=3D> >e=3D3D"Gill Sans" color=3D3D#0000ff>lass=3D3DEC_EC_EC_Apple-style-span sty=3D> >le=3D3D"COLOR: rgb(0=3D2C0=3D2C= >255)=3D3B FONT-FAMILY: 'Gill Sans'"> >_EC_EC_Apple-st= >yle-span style=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=3D3B FONT-FAMILY: 'G=3D> >i= >ll Sans'">Mobilep=3D> >an face=3D3DGillSans-Light> style=3D3D"F=3D> >ONT-FAMILY: GillSans-Light">le-style-span style=3D> >=3D3D"FONT-FAMILY: GillSans-Light">DEC_EC_Apple-converted-space>=3D> > =3D3B+1 765 427 5484<= >/SPAN>
> >
=3D3DGillSans-Light>
>s=3D3DEC_EC_EC_khtml-block-placeholder>FONT>
>AN>
=3D3DEC_EC_EC_Apple-interchange-newline> >AN>
>> >
> >
On 12 Jan 2009=3D2C at 01:44=3D2C Jay wrote:

s=3D3DEC_EC_EC_App=3D> >le-interchange-newline>> >
=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SPACING: =3D> >0px=3D3B FONT= >: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0=3D= >> >)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: no= >rmal=3D3B B=3D> >ORDER-COLLAPSE: separate">> >
sage style=3D3D"FONT-SIZE: 10pt=3D3B FONT-FAMILY: Ve=3D> >rdana">Is there a= > way in Modula-3 to declare that =3D3Ba type exists=3D2C a=3D> >nd ther= >e are <=3D3B*external*>=3D3B instances of it=3D2C without "fully" decl= >=3D> >aring it=3D2C so that no Modula-3 can instantiate it?
 =3D3BR>I have d=3D> >one this for sigset_t and sem_t=3D2C but they could erroneo= >usly be instantiat=3D> >ed by Modula-3 and I'd like to remove that ability = >to mess up so easily. >> =3D3B
(* This type is not declared c= >orrectly. It is only instantiate=3D> >d in C code. *)
 =3D3B sigset_= >t =3D3D RECORD END=3D3B

(* This type =3D> >is not declared correctly= >. It is only instantiated in C code. *)
 =3D> >=3D3B sem_t =3D3D REC= >ORD END=3D3B

In C I believe you can do this=3D2C like:<=3D> >BR>&nbs= >p=3D3B =3D3Btypedef struct foo foo_t=3D3B =3D3BC_E=3D> >C_Apple-converted-space> =3D3B
 =3D3B =3D3Be= >xtern foo_t foo=3D> >=3D3B =3D3Bd-space> =3D3B
=3D> > =3D3B
 =3D3Bvoid UseFoo(foo_= >t*)=3D3B >erted-space> =3D3BAN>
 =3D3B foo_t* GetFoo(void)=3D3B >=3D3DEC_EC_EC_Ap= >ple-converted-space> =3D3B
 =3D3B
Thanks=3D2C<=3D> >BR= >> =3D3B- Jay




<= >=3D> >/DIV>
E>
=3D> >

<= >/BLOCKQUOTE> >V>
> >=3D> >> >--_6117a048-9185-4c03= >-badb-ef8f93402268_--= > >--_2e194b09-14b6-4301-9116-a9e4d1e522b4_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Yes=2C generating the headers is viable.
>I thought I mentioned that a few times.
They could be generated in any build "that can".
 =3B i.e. a native = >build=2C that has a working C development system
 =3B and checked ag= >ainst the checked in ones.
> =3BSo then porting is:
 =3B copy the generator to new system= >=2C run it=2C copy results back=2C proceed
>
 =3BMaybe a good compromise.
 =3BNot good for "embedded sys= >tems"=2C but heck=2C is there any such thing
 =3B any longer? Doesn'= >t everything have megs of RAM and gigs of persistant storage? :)
>
You don't need =3BScheme.
>Just Quake =3B+ compiling and running C code.
>Assuming a native build system.
>I've done stuff in cross build systems like:
>typedef struct foo_t {int i=3B int j=3B } foo_t=3B
>extern const int xi =3D offsetof(foo_t=2C i)=3B
> =3B
>compile that=2C and read the value of xi out of the .obj file.
> =3B
> =3BThe .obj file reader was written in Perl. :)
> =3B (Python not available.)
> =3Bbut to do that here=2C I'd have to support multiple .obj file forma= >ts.
> =3B
> =3B- Jay

>=3B To: jay.krell at cornell.edu
>=3B Date: Mon= >=2C 12 Jan 2009 01:34:24 -0800
>=3B From: mika at async.caltech.edu
&g= >t=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] declaring a= > type's existance but not enough to instantiate it?
>=3B
>=3B R>>=3B You present it as a true tragic Dilemma.
>=3B
>=3B But = >isn't there a Third Way---to wit=2C can't you "Ask the Computer"
>=3B = >to do the work for you?
>=3B
>=3B Generate the code somehow... P= >arsing the C headers is an obvious
>=3B way but there may be others th= >at are simpler=2C such as writing a
>=3B Modula-3 program to generate = >the cloned M3 headers=2C sorry=2C interfaces.
>=3B
>=3B If I had= > to do this I would use my Scheme interpreter that's coded
>=3B in Mod= >ula-3 to write a Scheme program to generate the headers. This
>=3B pro= >gram could pull whatever tricks are deemed necessary and suitable=2C
>= >=3B down to the point of generating and compiling and running C programs>>=3B as necessary (or parsing C code=2C or reading tea leaves). But the<= >BR>>=3B end result would be a set of interfaces written in "Pure Modula-3= >".
>=3B The process of running the header generator would also have ve= >ry
>=3B few dependencies on anything outside the M3 distribution.
&= >gt=3B
>=3B Mika
>=3B
>=3B Jay writes:
>=3B >=3B--_6= >117a048-9185-4c03-badb-ef8f93402268_
>=3B >=3BContent-Type: text/pla= >in=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Encoding: quo= >ted-printable
>=3B >=3B
>=3B >=3B
>=3B >=3BThis is wha= >t you "have to" chose between.
>=3B >=3BHeader cloning or C code (an= >d C headers).
>=3B >=3B=3D20
>=3B >=3BCONST or VAR (or functi= >ons?)
>=3B >=3B=3D20
>=3B >=3BI'm going to likely make the Ue= >rror change tonight.
>=3B >=3BYou can still veto it (er=3D2C vote ag= >ainst it :) )
>=3B >=3B=3D20
>=3B >=3BPossibly some convulute= >d C (enum/#undef)=3D2C or splitting the Modula-3
>=3B >=3Bat boundar= >ies that weren't previously believed "natural".
>=3B >=3B(See how Se= >tupHandlers is ~two lines in Modula-3 and the rest in C=3D3B
>=3B >= >=3Bthis is partly out of ignorance. I don't know how to write those
>= >=3B >=3Btwo lines in C=3D3B and laziness=3D2C I didn't look into how).>>=3B >=3B=3D20
>=3B >=3B=3D20
>=3B >=3B=3D20
>=3B &= >gt=3BRemember I'm still staying away from mainstream platforms=3D2C
>= >=3B >=3Bso the value isn't what it might appear to be=3D2C but it is "sta= >ge setting"=3D
>=3B >=3B=3D2C
>=3B >=3Band the show might go = >on. :)
>=3B >=3B=3D20
>=3B >=3B=3D20
>=3B >=3BAlso=3D2= >C the dilemna does get more difficult now=3D2C with the little C header=3D<= >BR>>=3B >=3B cloning that remains.
>=3B >=3B=3D20
>=3B >= >=3BFor example=3D2C look at Upthreads.i3.
>=3B >=3BMainly=3D2C look = >at function prototypes.
>=3B >=3BConstants and types are "known prob= >lems".
>=3B >=3BPrototypes are gray. They actually tend to be portab= >le.
>=3B >=3B=3D20
>=3B >=3BFor example:
>=3B >=3B=3D2= >0
>=3B >=3BTYPE pid_t =3D3D INTEGER=3D3B
>=3B >=3B<=3B*EXTE= >RNAL "m3_getpid*>=3B PROCEDURE getpid():pid_t=3D3B
>=3B >=3B=3D20<= >BR>>=3B >=3Bor leave it alone?
>=3B >=3Bgetpid is probably the w= >orst example.
>=3B >=3BIt is so very portable declared in Modula-3.<= >BR>>=3B >=3BBut still=3D2C imagine pid_t might be 16bits or 32 or 64.R>>=3B >=3BWriting a wrapper is more portable -- as long as the pid isn= >'t stuff into s=3D
>=3B >=3Bome record that the system defines.
&= >gt=3B >=3B=3D20
>=3B >=3B=3D20
>=3B >=3BAgain=3D2C Upthread= >s.i3.
>=3B >=3BWould you like to see it reduced=3D2C or left alone?<= >BR>>=3B >=3BOnly deal with the types and initializers=3D2C or also the = >prototypes?
>=3B >=3BYou know=3D2C I could write a little portable l= >ayer=3D2C where all the types ar=3D
>=3B >=3Be pointers=3D2C always = >null initialized.
>=3B >=3BIt would buy /some/ portability=3D2C and = >cost some.
>=3B >=3B=3D20
>=3B >=3B=3D20
>=3B >=3BDo y= >ou like the sem_t change? Partly? Not at all?
>=3B >=3BThere is one = >sem_t in the system. So I moved it to be in C code.
>=3B >=3BOr=3D2C= > as I had it before=3D2C declared as the max size/align of all the platf=3D= >
>=3B >=3Borms -- getting that right is the same work as getting it = >right "the old wa=3D
>=3B >=3By"=3D2C except if you make a mistake= >=3D2C odds are still good of it being ok.
>=3B >=3B=3D20
>=3B &= >gt=3B=3D20
>=3B >=3BShould the line be drawn at generating the remai= >ning headers=3D2C rather than=3D
>=3B >=3B eliminating them?
>= >=3B >=3BUerror.i3 is easily generated. Good enough?
>=3B >=3B=3D20= >
>=3B >=3BUpthread.i3's types can be generated generally as records = >with opaque array=3D
>=3B >=3Bs with the right size and alignment.R>>=3B >=3B=3D20
>=3B >=3BOther stuff can be generated or at lea= >st checked.
>=3B >=3Be.g. to check that getpid is declared correctly= >=3D2C you can assign it to a f=3D
>=3B >=3Bunction pointer and see i= >f that compiles.
>=3B >=3B=3D20
>=3B >=3BPerf on Uerror argua= >bly doesn't matter.
>=3B >=3BIs it only error handling code?Or do so= >ckets often go down "error" paths=3D2C=3D
>=3B >=3B because they are= > slow and you are waiting for more data?
>=3B >=3B=3D20
>=3B &g= >t=3BAnyway=3D2C point is=3D2C I agree for sure this is valuable=3D2C but I = >might be h=3D
>=3B >=3Bitting the "tail" of the approach and should = >switch=3D2C I'm not sure. I keep=3D
>=3B >=3B saying that though=3D2= >C and then press further.
>=3B >=3B=3D20
>=3B >=3B=3D20
&g= >t=3B >=3B - Jay
>=3B >=3B
>=3B >=3B
>=3B >=3B
>= >=3B >=3BFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon=3D2= >C 12 Jan 200=3D
>=3B >=3B9 19:24:50 +1100CC: m3devel at elegosoft.comSu= >bject: Re: [M3devel] declaring a=3D
>=3B >=3B type's existance but n= >ot enough to instantiate it?
>=3B >=3B
>=3B >=3B
>=3B &g= >t=3BPoint taken. We live in a C universe and so need to interact. I do thin= >k =3D
>=3B >=3Byour work with the headers is useful=3D2C and I want = >it to continue. Especia=3D
>=3B >=3Blly in simplifying ports.
>= >=3B >=3B
>=3B >=3B
>=3B >=3BOn 12 Jan 2009=3D2C at 19:18=3D= >2C Jay wrote:
>=3B >=3B
>=3B >=3BI don't think a development = >system without C headers is interesting.. Is it=3D
>=3B >=3B really?= > The transform I apply at times is wherever there is interaction wi=3D
&= >gt=3B >=3Bth C code that is described by system-dependent headers=3D2C or= > perhaps even =3D
>=3B >=3Bfairly system-independent headers outside= > the Modula-3 tree=3D2C either write=3D
>=3B >=3B wrapper functions = >for the functionality in the headers (e.g. stat=3D2C waitp=3D
>=3B >= >=3Bid)=3D2C which can be done in a system-independent way=3D2C or move the = >Modula-=3D
>=3B >=3B3<=3B->=3BC transition higher=3D2C which is = >also usually system-independent=3D2C e.g.=3D
>=3B >=3B ThreadPThread= >C_SetupHandlers. It is either that or clone the headers=3D2C wh=3D
>= >=3B >=3Bich seems like the worse evil. There is always going to be a Modu= >la-3<=3B->=3BC t=3D
>=3B >=3Bransition=3D2C it is just a matter = >of where it occurs. - Jay
>=3B >=3B
>=3B >=3BCC: m3devel at eleg= >osoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.e=3D
>=3B &g= >t=3BduSubject: Re: [M3devel] declaring a type's existance but not enough to= > ins=3D
>=3B >=3Btantiate it?Date: Mon=3D2C 12 Jan 2009 12:32:15 +11= >00
>=3B >=3B
>=3B >=3B
>=3B >=3BJay=3D2C I really thin= >k you are bending over backwards too far just to be abl=3D
>=3B >=3B= >e to shoe-horn things into C. I *like* having the transpar of C header fil= >=3D
>=3B >=3Bes expressed in Modula-3=3D2C *particularly* for system= > calls=3D2C where you mi=3D
>=3B >=3Bght even be trying to build on = >a system that does not have the C header fil=3D
>=3B >=3Bes installe= >d=3D2C even though the libraries exist and can be linked to. Fund=3D
>= >=3B >=3Bamentally=3D2C I think anytime the Modula-3 code is made less tra= >nsparent you=3D
>=3B >=3B should think hard about what you are doing= >. The same with the change of c=3D
>=3B >=3Bonstants to variables.R>>=3B >=3B
>=3B >=3BI am getting very nervous that the changes = >you are making are destroying th=3D
>=3B >=3Be clarity of the Modula= >-3 run-time code.
>=3B >=3B
>=3B >=3BIn this particular case= >=3D2C you are wanting to use a Modula-3 parameter pass=3D
>=3B >=3Bi= >ng mechanism on something that is not declared in Modula-3. Seems kind of= >=3D
>=3B >=3B dubious to me. Also=3D2C I really don't like the idea = >of accessing external=3D
>=3B >=3B variables in C.
>=3B >=3B<= >BR>>=3B >=3B-- Tony
>=3B >=3B
>=3B >=3BOn 12 Jan 2009=3D2= >C at 11:55=3D2C Jay wrote:
>=3B >=3B
>=3B >=3BI considered AD= >DRESS.However I think it still doesn't satisfy. I want to be=3D
>=3B &= >gt=3B able to do this: TYPE Foo_t =3D3D something=3D3B<=3B* EXTERNAL *>= >=3B VAR Foo1=3D2C Foo=3D
>=3B >=3B2:Foo_t=3D3B<=3B* EXTERNAL *>= >=3B PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t)=3D
>=3B >=3B= >=3D3B (* Modula-3=3D2C not external *)PROCEDURE x()=3D3DBEGIN UseFoo(Foo1)= >=3D3B U=3D
>=3B >=3BseFoo(Foo2)=3D3BEND x=3D3B AND I want any use of= >:VAR Foo3:Foo3_t=3D3B (* Modula-3=3D
>=3B >=3B=3D2C not external *)t= >o error. This is sem_t and sigset_t in particular. Poss=3D
>=3B >=3B= >ibly renaming is the thing.They used to be declared in Modula-3=3D2C system= >-d=3D
>=3B >=3Bependently=3D2C butI moved them to portable C. I coul= >d remove the types entir=3D
>=3B >=3Bely and change UseFoo to take a= >n address=3D2Cand declare mask and ackSem to b=3D
>=3B >=3Be integer= >s or I guess.<=3B*EXTERNAL>=3B VAR ackSem : RECORD END=3D3B That would = >sat=3D
>=3B >=3Bisfy but I thought it might be nicer to still provid= >e the namedtypes to ref=3D
>=3B >=3Ber to the external variables. - = >Jay
>=3B >=3B
>=3B >=3BFrom: hosking at cs.purdue.eduTo: jay.kre= >ll at cornell.eduDate: Mon=3D2C 12 Jan 200=3D
>=3B >=3B9 11:13:00 +1100= >CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a=3D
>=3B &g= >t=3B type's existance but not enough to instantiate it?What's wrong with us= >ing =3D
>=3B >=3BADDRESS for references to opaque values? If sigset_= >t is never instantiated=3D
>=3B >=3B in Modula-3=3D2C then why do yo= >u need it declared there?
>=3B >=3B
>=3B >=3B
>=3B >= >=3B
>=3B >=3BAntony Hosking | Associate Professor | Computer Science= > | Purdue University
>=3B >=3B305 N. University Street | West Lafaye= >tte | IN 47907 | USA
>=3B >=3BOffice +1 765 494 6001 | Mobile +1 765= > 427 5484
>=3B >=3B
>=3B >=3B
>=3B >=3BOn 12 Jan 2009= >=3D2C at 01:44=3D2C Jay wrote:
>=3B >=3B
>=3B >=3BIs there a = >way in Modula-3 to declare that a type exists=3D2C and there are <=3B=3D<= >BR>>=3B >=3B*external*>=3B instances of it=3D2C without "fully" decla= >ring it=3D2C so that no M=3D
>=3B >=3Bodula-3 can instantiate it? I = >have done this for sigset_t and sem_t=3D2C but =3D
>=3B >=3Bthey cou= >ld erroneously be instantiated by Modula-3 and I'd like to remove t=3D
&= >gt=3B >=3Bhat ability to mess up so easily. (* This type is not declared = >correctly. I=3D
>=3B >=3Bt is only instantiated in C code. *) sigset= >_t =3D3D RECORD END=3D3B(* This typ=3D
>=3B >=3Be is not declared co= >rrectly. It is only instantiated in C code. *) sem_t =3D
>=3B >=3B= >=3D3D RECORD END=3D3BIn C I believe you can do this=3D2C like: typedef stru= >ct fo=3D
>=3B >=3Bo foo_t=3D3B extern foo_t foo=3D3B void UseFoo(foo= >_t*)=3D3B foo_t* GetFoo=3D
>=3B >=3B(void)=3D3B Thanks=3D2C - Jay=3D= >
>=3B >=3B
>=3B >=3B--_6117a048-9185-4c03-badb-ef8f93402268_<= >BR>>=3B >=3BContent-Type: text/html=3B charset=3D"iso-8859-1"
>=3B= > >=3BContent-Transfer-Encoding: quoted-printable
>=3B >=3B
>= >=3B >=3B<=3Bhtml>=3B
>=3B >=3B<=3Bhead>=3B
>=3B >= >=3B<=3Bstyle>=3B
>=3B >=3B.hmmessage P
>=3B >=3B{
>= >=3B >=3Bmargin:0px=3D3B
>=3B >=3Bpadding:0px
>=3B >=3B}
= >>=3B >=3Bbody.hmmessage
>=3B >=3B{
>=3B >=3Bfont-size: 10= >pt=3D3B
>=3B >=3Bfont-family:Verdana
>=3B >=3B}
>=3B >= >=3B<=3B/style>=3B
>=3B >=3B<=3B/head>=3B
>=3B >=3B<= >=3Bbody class=3D3D'hmmessage'>=3B
>=3B >=3BThis is what you "have = >to" chose between.<=3BBR>=3B
>=3B >=3BHeader cloning or C code (= >and C headers).<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>= >=3B
>=3B >=3BCONST or VAR (or functions?)<=3BBR>=3B
>=3B &g= >t=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BI'm going to likely make= > the Uerror change tonight.<=3BBR>=3B
>=3B >=3BYou can still vet= >o it (er=3D2C vote against it :) )<=3BBR>=3B
>=3B >=3B&=3Bnbs= >p=3D3B<=3BBR>=3B
>=3B >=3BPossibly some convuluted C (enum/#unde= >f)=3D2C or splitting the Modula-3<=3BBR>=3B
>=3B >=3Bat boundari= >es that weren't previously believed "natural".<=3BBR>=3B
>=3B >= >=3B(See how SetupHandlers is ~two lines in Modula-3 and the rest in C=3D3B&= >lt=3BBR>=3B
>=3B >=3Bthis is partly out of ignorance. I don't know= > how to write those<=3BBR>=3B
>=3B >=3Btwo lines in C=3D3B and l= >aziness=3D2C I didn't look into how).<=3BBR>=3B
>=3B >=3B&=3B= >nbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
&= >gt=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BRemember I'm sti= >ll staying away from mainstream platforms=3D2C<=3BBR>=3B
>=3B >= >=3Bso the value isn't what it might appear to be=3D2C but it is "stage sett= >ing"=3D
>=3B >=3B=3D2C<=3BBR>=3B
>=3B >=3Band the show mi= >ght go on. :)<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B<= >BR>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BAlso=3D2C th= >e dilemna does get more difficult now=3D2C with the little C header=3D
&= >gt=3B >=3B cloning that remains.<=3BBR>=3B
>=3B >=3B&=3Bnbs= >p=3D3B<=3BBR>=3B
>=3B >=3BFor example=3D2C look at Upthreads.i3.= ><=3BBR>=3B
>=3B >=3BMainly=3D2C look at function prototypes.<= >=3BBR>=3B
>=3B >=3BConstants and types are "known problems".<=3B= >BR>=3B
>=3B >=3BPrototypes are gray. They actually tend to be port= >able.<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>= >=3B >=3BFor example:<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3B= >BR>=3B
>=3B >=3BTYPE pid_t =3D3D INTEGER=3D3B<=3BBR>=3B
>= >=3B >=3B&=3Blt=3D3B*EXTERNAL "m3_getpid*&=3Bgt=3D3B PROCEDURE getpi= >d():pid_t=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B= >
>=3B >=3Bor leave it alone?<=3BBR>=3B
>=3B >=3Bgetpid is= > probably the worst example.<=3BBR>=3B
>=3B >=3BIt is so very po= >rtable declared in Modula-3.<=3BBR>=3B
>=3B >=3BBut still=3D2C i= >magine pid_t might be 16bits or 32 or 64.<=3BBR>=3B
>=3B >=3BWri= >ting a wrapper is more portable -- as long as the pid isn't stuff into s=3D= >
>=3B >=3Bome record that the system defines.<=3BBR>=3B
>= >=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B&l= >t=3BBR>=3B
>=3B >=3BAgain=3D2C Upthreads.i3.<=3BBR>=3B
>= >=3B >=3BWould you like to see it reduced=3D2C or left alone?<=3BBR>= >=3B
>=3B >=3BOnly deal with the types and initializers=3D2C or also = >the prototypes?<=3BBR>=3B
>=3B >=3BYou know=3D2C I could write a= > little portable layer=3D2C where all the types ar=3D
>=3B >=3Be poi= >nters=3D2C always null initialized.<=3BBR>=3B
>=3B >=3BIt would = >buy /some/ portability=3D2C and cost some.<=3BBR>=3B
>=3B >=3B&a= >mp=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B= >
>=3B >=3BDo you like the sem_t change? Partly? Not at all?<=3BBR&= >gt=3B
>=3B >=3BThere is one sem_t in the system. So I moved it to be= > in C code.<=3BBR>=3B
>=3B >=3BOr=3D2C as I had it before=3D2C d= >eclared as the max size/align of all the platf=3D
>=3B >=3Borms -- g= >etting that right is the same work as getting it right "the old wa=3D
&g= >t=3B >=3By"=3D2C except if you make a mistake=3D2C odds are still good of= > it being ok.<=3BB=3D
>=3B >=3BR>=3B
>=3B >=3B&=3Bnbsp= >=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>= >=3B >=3BShould the line be drawn at generating the remaining headers=3D2C= > rather than=3D
>=3B >=3B eliminating them?<=3BBR>=3B
>=3B = >>=3BUerror.i3 is easily generated. Good enough?<=3BBR>=3B
>=3B &= >gt=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BUpthread.i3's types can= > be generated generally as records with opaque array=3D
>=3B >=3Bs w= >ith the right size and alignment.<=3BBR>=3B
>=3B >=3B&=3Bnbsp= >=3D3B<=3BBR>=3B
>=3B >=3BOther stuff can be generated or at leas= >t checked.<=3BBR>=3B
>=3B >=3Be.g. to check that getpid is decla= >red correctly=3D2C you can assign it to a f=3D
>=3B >=3Bunction poin= >ter and see if that compiles.<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3= >B<=3BBR>=3B
>=3B >=3BPerf on Uerror arguably doesn't matter.<= >=3BBR>=3B
>=3B >=3BIs it only error handling code?<=3BBR>=3BOr= > do sockets often go down "error" path=3D
>=3B >=3Bs=3D2C because th= >ey are slow and you are waiting for more data?<=3BBR>=3B
>=3B >= >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BAnyway=3D2C point is=3D2C= > I agree for sure this is valuable=3D2C but I might be h=3D
>=3B >= >=3Bitting the "tail" of the approach and should switch=3D2C I'm not sure. I= > keep=3D
>=3B >=3B saying that though=3D2C and then press further.&l= >t=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >= >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B- Jay<= >=3BBR>=3B<=3BBR>=3B
>=3B >=3B
>=3B >=3B<=3BHR id=3D3D= >stopSpelling>=3B
>=3B <=3BBR>=3B
>=3B >=3BFrom: hosking at c= >s.purdue.edu<=3BBR>=3BTo: jay.krell at cornell.edu<=3BBR>=3BDate: Mon= >=3D2C 12=3D
>=3B >=3B Jan 2009 19:24:50 +1100<=3BBR>=3BCC: m3dev= >el at elegosoft.com<=3BBR>=3BSubject: Re: [M3de=3D
>=3B >=3Bvel] de= >claring a type's existance but not enough to instantiate it?<=3BBR>=3B&= >lt=3BBR>=3B=3D
>=3B >=3B<=3BBR>=3B
>=3B >=3B<=3BDIV&g= >t=3B<=3BSPAN class=3D3DEC_Apple-style-span style=3D3D"WORD-SPACING: 0px= >=3D3B FONT: =3D
>=3B >=3B12px Helvetica=3D3B TEXT-TRANSFORM: none=3D= >3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-IND=3D
>=3B >=3BENT: 0px=3D3B= > WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPS=3D
= >>=3B >=3BE: separate">=3B
>=3B >=3B<=3BDIV style=3D3D"WORD-W= RAP: break-word">=3B<=3BSPAN class=3D3DEC_Apple-style-span styl=3D
&= >gt=3B >=3Be=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TR= >ANSFORM: none=3D3B C=3D
>=3B >=3BOLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-= >INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-S=3D
>=3B >=3BPACIN= >G: normal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=3D3DEC_Appl= >e-style-s=3D
>=3B >=3Bpan style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12= >px Helvetica=3D3B TEXT-TRANSFORM: n=3D
>=3B >=3Bone=3D3B COLOR: rgb(= >0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B =3D
&= >gt=3B >=3BLETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate">=3B<= >=3BSPAN class=3D3DEC_Apple=3D
>=3B >=3B-style-span style=3D3D"WORD-S= >PACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRAN=3D
>=3B >=3BSFO= >RM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SP= >ACE: no=3D
>=3B >=3Brmal=3D3B LETTER-SPACING: normal=3D3B BORDER-COL= >LAPSE: separate">=3B<=3BSPAN class=3D3D=3D
>=3B >=3BEC_Apple-sty= >le-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B T=3D>>=3B >=3BEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-= >INDENT: 0px=3D3B WHITE-S=3D
>=3B >=3BPACE: normal=3D3B LETTER-SPACIN= >G: normal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN =3D
>=3B >= >=3Bclass=3D3DEC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12= >px Helvet=3D
>=3B >=3Bica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(= >0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B=3D
>=3B >=3B WHITE-SPACE: = >normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate=3D
>= >=3B >=3B">=3B<=3BSPAN class=3D3DEC_Apple-style-span style=3D3D"WORD-S= >PACING: 0px=3D3B FONT: 12p=3D
>=3B >=3Bx Helvetica=3D3B TEXT-TRANSFO= >RM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT=3D
>=3B >= >=3B: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-C= >OLLAPSE: =3D
>=3B >=3Bseparate">=3B<=3BSPAN class=3D3DEC_Apple-s= >tyle-span style=3D3D"WORD-SPACING: 0px=3D3B F=3D
>=3B >=3BONT: 12px = >Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEX= >=3D
>=3B >=3BT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPAC= >ING: normal=3D3B BORDER-CO=3D
>=3B >=3BLLAPSE: separate">=3B<=3B= >SPAN class=3D3DEC_Apple-style-span style=3D3D"WORD-SPACING: =3D
>=3B &= >gt=3B0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rg= >b(0=3D2C0=3D2C0=3D
>=3B >=3B)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE= >: normal=3D3B LETTER-SPACING: normal=3D3B B=3D
>=3B >=3BORDER-COLLAP= >SE: separate">=3B
>=3B >=3B<=3BDIV>=3BPoint taken. &=3Bnbsp= >=3D3BWe live in a C universe and so need to interact. =3D
>=3B >=3B&= >amp=3Bnbsp=3D3BI do think your work with the headers is useful=3D2C and I w= >ant it to=3D
>=3B >=3B continue. &=3Bnbsp=3D3BEspecially in simpl= >ifying ports.<=3B/DIV>=3B
>=3B >=3B<=3BDIV>=3B<=3BBR>=3B= ><=3B/DIV>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/S= >PAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>= >=3B<=3B/DI=3D
>=3B >=3BV>=3B<=3B/SPAN>=3B<=3B/DIV>=3B>>=3B >=3B<=3BDIV>=3B
>=3B >=3B<=3BDIV>=3BOn 12 Jan 2009= >=3D2C at 19:18=3D2C Jay wrote:<=3B/DIV>=3B<=3BBR class=3D3DEC_Apple-i= >nt=3D
>=3B >=3Berchange-newline>=3B
>=3B >=3B<=3BBLOCKQUO= >TE>=3B<=3BSPAN class=3D3DEC_Apple-style-span style=3D3D"WORD-SPACING: 0= >px=3D3B=3D
>=3B >=3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none= >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B T=3D
>=3B >=3BEXT-INDENT: 0px= >=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-=3D
&g= >t=3B >=3BCOLLAPSE: separate">=3B
>=3B >=3B<=3BDIV class=3D3DEC= >_hmmessage style=3D3D"FONT-SIZE: 10pt=3D3B FONT-FAMILY: Verdana"=3D
>= >=3B >=3B>=3BI don't think a development system without C headers is int= >eresting.. Is i=3D
>=3B >=3Bt really?<=3BBR>=3B&=3Bnbsp=3D3B&= >lt=3BBR>=3BThe transform I apply at times is wherever there i=3D
>= >=3B >=3Bs interaction with C code that is described by system-dependent h= >eaders=3D2C =3D
>=3B >=3Bor perhaps even fairly system-independent h= >eaders outside the Modula-3 tree=3D
>=3B >=3B=3D2C either write wrap= >per functions for the functionality in the headers (e.=3D
>=3B >=3Bg= >. stat=3D2C waitpid)=3D2C which&=3Bnbsp=3D3Bcan be done in a system-inde= >pendent way=3D
>=3B >=3B=3D2C&=3Bnbsp=3D3Bor move the Modula-3&am= >p=3Blt=3D3B-&=3Bgt=3D3BC transition higher=3D2C which is=3D
>=3B &g= >t=3B also usually system-independent=3D2C e.g. ThreadPThreadC_SetupHandlers= >.<=3BBR>=3B&=3B=3D
>=3B >=3Bnbsp=3D3B<=3BBR>=3BIt is eith= >er that or clone the headers=3D2C which seems like the w=3D
>=3B >= >=3Borse evil.<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3BThere is always go= >ing to be a Modula-3&=3Blt=3D3B-&=3Bgt=3D
>=3B >=3B=3D3BC tran= >sition=3D2C it is just a matter of where it occurs.<=3BBR>=3B&=3Bnbs= >p=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bnbsp=3D3B- Jay<=3BBR>=3B= ><=3BBR>=3B
>=3B >=3B<=3BHR id=3D3DEC_stopSpelling>=3B
>= >=3B >=3B<=3BBR>=3BCC:<=3BSPAN class=3D3DEC_Apple-converted-space>= >=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BA href=3D3D"mai=3D
>=3B >= >=3Blto:m3devel at elegosoft.com">=3Bm3devel at elegosoft.com<=3B/A>=3B<= >=3BBR>=3BFrom:<=3BSPAN class=3D3D=3D
>=3B >=3BEC_Apple-converted= >-space>=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BA href=3D3D"mailto:hoski= >ng at cs.purdue=3D
>=3B >=3B.edu">=3Bhosking at cs.purdue.edu<=3B/A>= >=3B<=3BBR>=3BTo:<=3BSPAN class=3D3DEC_Apple-converted-spac=3D
>= >=3B >=3Be>=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BA href=3D3D"mailto:= >jay.krell at cornell.edu">=3Bjay.krell at cornell=3D
>=3B >=3B.edu<=3B= >/A>=3B<=3BBR>=3BSubject: Re: [M3devel] declaring a type's existance b= >ut not eno=3D
>=3B >=3Bugh to instantiate it?<=3BBR>=3BDate: Mon= >=3D2C 12 Jan 2009 12:32:15 +1100<=3BBR>=3B<=3BBR>=3B<=3BB=3D
&= >gt=3B >=3BR>=3B
>=3B <=3BDIV>=3B<=3BSPAN class=3D3DEC_EC_App= >le-style-span style=3D3D"WORD-SPACING: 0px=3D3B FON=3D
>=3B >=3BT: 1= >2px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B= > TEXT-=3D
>=3B >=3BINDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-= >SPACING: normal=3D3B BORDER-COLL=3D
>=3B >=3BAPSE: separate">=3BR>>=3B >=3B<=3BDIV style=3D3D"WORD-WRAP: break-word">=3B<=3BSPAN = >class=3D3DEC_EC_Apple-style-span s=3D
>=3B >=3Btyle=3D3D"WORD-SPACIN= >G: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D
>=3B >= >=3B=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: = >normal=3D3B LET=3D
>=3B >=3BTER-SPACING: normal=3D3B BORDER-COLLAPSE= >: separate">=3B<=3BSPAN class=3D3DEC_EC_Apple=3D
>=3B >=3B-style= >-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRAN= >=3D
>=3B >=3BSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-IN= >DENT: 0px=3D3B WHITE-SPACE: no=3D
>=3B >=3Brmal=3D3B LETTER-SPACING:= > normal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=3D3D=3D
&g= >t=3B >=3BEC_EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 1= >2px Helvetica=3D
>=3B >=3B=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb= >(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WH=3D
>=3B >=3BITE-SPACE:= > normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate">=3B&l= >t=3B=3D
>=3B >=3BSPAN class=3D3DEC_EC_Apple-style-span style=3D3D"WO= >RD-SPACING: 0px=3D3B FONT: 12p=3D
>=3B >=3Bx Helvetica=3D3B TEXT-TRA= >NSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT=3D
>=3B &= >gt=3B: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER= >-COLLAPSE: =3D
>=3B >=3Bseparate">=3B<=3BSPAN class=3D3DEC_EC_Ap= >ple-style-span style=3D3D"WORD-SPACING: 0px=3D
>=3B >=3B=3D3B FONT: = >12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D<= >BR>>=3B >=3B=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER= >-SPACING: normal=3D3B BO=3D
>=3B >=3BRDER-COLLAPSE: separate">=3B&= >lt=3BSPAN class=3D3DEC_EC_Apple-style-span style=3D3D"WORD=3D
>=3B >= >=3B-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B C= >OLOR: rgb=3D
>=3B >=3B(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHI= >TE-SPACE: normal=3D3B LETTER-SPACING: n=3D
>=3B >=3Bormal=3D3B BORDE= >R-COLLAPSE: separate">=3B<=3BSPAN class=3D3DEC_EC_Apple-style-span st= >=3D
>=3B >=3Byle=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D= >3B TEXT-TRANSFORM: none=3D3B=3D
>=3B >=3B COLOR: rgb(0=3D2C0=3D2C0)= >=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER=3D
>=3B &g= >t=3B-SPACING: normal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class= >=3D3DEC_EC_Apple-st=3D
>=3B >=3Byle-span style=3D3D"WORD-SPACING: 0p= >x=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFO=3D
>=3B >=3BRM: none= >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: nor= >ma=3D
>=3B >=3Bl=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: s= >eparate">=3B
>=3B >=3B<=3BDIV>=3BJay=3D2C I really think you a= >re bending over backwards too far just to b=3D
>=3B >=3Be able to sh= >oe-horn things into C. &=3Bnbsp=3D3BI *like* having the transpar of =3D<= >BR>>=3B >=3BC header files expressed in Modula-3=3D2C *particularly* fo= >r system calls=3D2C =3D
>=3B >=3Bwhere you might even be trying to b= >uild on a system that does not have the =3D
>=3B >=3BC header files = >installed=3D2C even though the libraries exist and can be link=3D
>=3B= > >=3Bed to. &=3Bnbsp=3D3BFundamentally=3D2C I think anytime the Modula= >-3 code is made l=3D
>=3B >=3Bess transparent you should think hard = >about what you are doing. &=3Bnbsp=3D3BThe=3D
>=3B >=3B same with= > the change of constants to variables.<=3B/DIV>=3B
>=3B >=3B<= >=3BDIV>=3B<=3BBR>=3B<=3B/DIV>=3B
>=3B >=3B<=3BDIV>=3BI= > am getting very nervous that the changes you are making are destroyi=3D>>=3B >=3Bng the clarity of the Modula-3 run-time code.<=3B/DIV>=3B= >
>=3B >=3B<=3BDIV>=3B<=3BBR>=3B<=3B/DIV>=3B
>=3B &g= >t=3B<=3BDIV>=3BIn this particular case=3D2C you are wanting to use a Mo= >dula-3 parameter=3D
>=3B >=3B passing mechanism on something that is= > not declared in Modula-3. &=3Bnbsp=3D3BS=3D
>=3B >=3Beems kind o= >f dubious to me. &=3Bnbsp=3D3BAlso=3D2C I really don't like the idea of= >=3D
>=3B >=3B accessing external variables in C.<=3B/DIV>=3B
= >>=3B >=3B<=3BDIV>=3B<=3BBR>=3B<=3B/DIV>=3B
>=3B >=3B= ><=3BDIV>=3B-- Tony<=3B/DIV>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<= >=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPA= >N>=3B<=3B/SPAN>=3B<=3B=3D
>=3B >=3B/DIV>=3B<=3B/SPAN>= >=3B<=3B/DIV>=3B<=3BBR>=3B
>=3B >=3B<=3BDIV>=3B
>=3B= > >=3B<=3BDIV>=3BOn 12 Jan 2009=3D2C at 11:55=3D2C Jay wrote:<=3B/DI= >V>=3B<=3BBR class=3D3DEC_EC_Apple-=3D
>=3B >=3Binterchange-newli= >ne>=3B
>=3B >=3B<=3BBLOCKQUOTE>=3B<=3BSPAN class=3D3DEC_EC_A= >pple-style-span style=3D3D"WORD-SPACING: 0px=3D
>=3B >=3B=3D3B FONT:= > 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D= >
>=3B >=3B=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTE= >R-SPACING: normal=3D3B BO=3D
>=3B >=3BRDER-COLLAPSE: separate">=3B= >
>=3B >=3B<=3BDIV class=3D3DEC_EC_hmmessage style=3D3D"FONT-SIZE: = >10pt=3D3B FONT-FAMILY: Verda=3D
>=3B >=3Bna">=3BI considered ADDRE= >SS.<=3BBR>=3BHowever I think it still doesn't satisfy.<=3BBR>=3B&am= >p=3B=3D
>=3B >=3Bnbsp=3D3B<=3BBR>=3BI want to be able to do this= >:<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3BTYPE&=3Bnbsp=3D3BFoo_t =3D<= >BR>>=3B >=3B=3D3D something=3D3B<=3BBR>=3B&=3Blt=3D3B* EXTERNAL = >*&=3Bgt=3D3B VAR Foo1=3D2C Foo2:Foo_t=3D3B<=3BBR>=3B&=3B=3D
&g= >t=3B >=3Blt=3D3B* EXTERNAL *&=3Bgt=3D3B PROCEDURE&=3Bnbsp=3D3BUseFo= >o(READONLY (* or VAR *) foo:F=3D
>=3B >=3Boo_t)=3D3B<=3BBR>=3B&a= >mp=3Bnbsp=3D3B<=3BBR>=3B(* Modula-3=3D2C not external *)<=3BBR>=3BP= >ROCEDURE x()=3D3D<=3B=3D
>=3B >=3BBR>=3BBEGIN<=3BBR>=3B&= >=3Bnbsp=3D3B UseFoo(Foo1)=3D3B<=3BBR>=3B&=3Bnbsp=3D3B UseFoo(Foo2)= >=3D3B<=3BBR>=3BEND x=3D
>=3B >=3B=3D3B<=3BBR>=3B&=3Bnbsp= >=3D3B<=3BBR>=3BAND I want any use of:<=3BBR>=3BVAR Foo3:Foo3_t=3D3B= > (* Modula-3=3D
>=3B >=3B=3D2C not external *)<=3BBR>=3B<=3BBR= >>=3Bto error. This is sem_t and sigset_t in particul=3D
>=3B >=3Ba= >r.<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3BPossibly renaming is the thin= >g.<=3BBR>=3BThey used to be decla=3D
>=3B >=3Bred in Modula-3=3D= >2C system-dependently=3D2C but<=3BBR>=3BI moved them to portable C.=3D<= >BR>>=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3BI could remove = >the types entirely and change UseFoo to take=3D
>=3B >=3B an address= >=3D2C<=3BBR>=3Band declare mask and ackSem to be integers or I guess.&l= >t=3BBR=3D
>=3B >=3B>=3B&=3Blt=3D3B*EXTERNAL&=3Bgt=3D3B VAR a= >ckSem&=3Bnbsp=3D3B: RECORD END=3D3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BB= >R>=3BTha=3D
>=3B >=3Bt would satisfy but I thought it might be nic= >er to still provide the named<=3B=3D
>=3B >=3BBR>=3Btypes to ref= >er to the external variables.<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B&a= >mp=3Bnbsp=3D3B- Jay<=3BB=3D
>=3B >=3BR>=3B<=3BBR>=3B
>= >=3B >=3B<=3BHR id=3D3DEC_EC_stopSpelling>=3B
>=3B >=3B<=3BBR= >>=3BFrom:<=3BSPAN class=3D3DEC_EC_Apple-converted-space>=3B&=3Bnbs= >p=3D3B<=3B/SPAN>=3B<=3BA href=3D
>=3B >=3B=3D3D"mailto:hosking= >@cs.purdue.edu">=3Bhosking at cs.purdue.edu<=3B/A>=3B<=3BBR>=3BTo:&l= >t=3BSPAN cla=3D
>=3B >=3Bss=3D3DEC_EC_Apple-converted-space>=3B&am= >p=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BA href=3D3D"mailto:jay.krell=3D
>= >=3B >=3B at cornell.edu">=3Bjay.krell at cornell.edu<=3B/A>=3B<=3BBR>= >=3BDate: Mon=3D2C 12 Jan 2009 11:13:0=3D
>=3B >=3B0 +1100<=3BBR>= >=3BCC:<=3BSPAN class=3D3DEC_EC_Apple-converted-space>=3B&=3Bnbsp=3D3= >B<=3B/SPAN>=3B<=3BA h=3D
>=3B >=3Bref=3D3D"mailto:m3devel at eleg= >osoft.com">=3Bm3devel at elegosoft.com<=3B/A>=3B<=3BBR>=3BSubject: = >=3D
>=3B >=3BRe: [M3devel] declaring a type's existance but not enou= >gh to instantiate it=3D
>=3B >=3B?<=3BBR>=3B<=3BBR>=3BWhat's= > wrong with using ADDRESS for references to opaque values? &=3B=3D
&g= >t=3B >=3Bnbsp=3D3BIf sigset_t is never instantiated in Modula-3=3D2C then= > why do you nee=3D
>=3B >=3Bd it declared there?<=3BBR>=3B
&g= >t=3B >=3B<=3BDIV>=3B<=3BBR>=3B
>=3B >=3B<=3BDIV>=3B<= >=3BSPAN class=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D= >3B =3D
>=3B >=3BFONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B = >COLOR: rgb(0=3D2C0=3D2C0)=3D3B TE=3D
>=3B >=3BXT-INDENT: 0px=3D3B WH= >ITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-C=3D
>=3B &g= >t=3BOLLAPSE: separate">=3B
>=3B >=3B<=3BDIV style=3D3D"WORD-WRAP= >: break-word">=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-spa=3D
>= >=3B >=3Bn style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEX= >T-TRANSFORM: non=3D
>=3B >=3Be=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B T= >EXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LE=3D
>=3B >=3BTTER-SP= >ACING: normal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=3D3DEC_= >EC_EC_A=3D
>=3B >=3Bpple-style-span style=3D3D"WORD-SPACING: 0px=3D3= >B FONT: 12px Helvetica=3D3B TEXT-=3D
>=3B >=3BTRANSFORM: none=3D3B C= >OLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE=3D
>= >=3B >=3B: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separa= >te">=3B<=3BSPAN clas=3D
>=3B >=3Bs=3D3DEC_EC_EC_Apple-style-span= > style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helv=3D
>=3B >=3Betica= >=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT:= > 0px=3D
>=3B >=3B=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: norm= >al=3D3B BORDER-COLLAPSE: separ=3D
>=3B >=3Bate">=3B<=3BSPAN clas= >s=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B =3D
&g= >t=3B >=3BFONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0= >=3D2C0=3D2C0)=3D3B TE=3D
>=3B >=3BXT-INDENT: 0px=3D3B WHITE-SPACE: n= >ormal=3D3B LETTER-SPACING: normal=3D3B BORDER-C=3D
>=3B >=3BOLLAPSE:= > separate">=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-span style=3D3D"W= >ORD-SP=3D
>=3B >=3BACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TR= >ANSFORM: none=3D3B COLOR: rgb(0=3D
>=3B >=3B=3D2C0=3D2C0)=3D3B TEXT-= >INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: nor=3D
>=3B = >>=3Bmal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=3D3DEC_EC_E= >C_Apple-style-span s=3D
>=3B >=3Btyle=3D3D"WORD-SPACING: 0px=3D3B FO= >NT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D
>=3B >=3B=3D3B COLOR= >: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LE= >T=3D
>=3B >=3BTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate">= >=3B<=3BSPAN class=3D3DEC_EC_EC_Ap=3D
>=3B >=3Bple-style-span style= >=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-T=3D
>=3B = >>=3BRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px= >=3D3B WHITE-SPACE:=3D
>=3B >=3B normal=3D3B LETTER-SPACING: normal= >=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=3D
>=3B >=3B= >=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px= > Helve=3D
>=3B >=3Btica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0= >=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D
>=3B >=3B=3D3B WHITE-SPACE: n= >ormal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separ=3D
>=3B = >>=3Bate">=3B
>=3B >=3B<=3BDIV>=3B<=3BFONT class=3D3DEC_EC_= >EC_Apple-style-span color=3D3D#0000ff>=3B<=3BFONT class=3D3D=3D
>= >=3B >=3BEC_EC_EC_Apple-style-span face=3D3D"Gill Sans">=3B<=3BSPAN cl= >ass=3D3DEC_EC_EC_Apple-s=3D
>=3B >=3Btyle-span style=3D3D"COLOR: rgb= >(0=3D2C0=3D2C255)=3D3B FONT-FAMILY: 'Gill Sans'">=3B<=3BSP=3D
>=3B= > >=3BAN class=3D3DEC_EC_EC_Apple-style-span style=3D3D"COLOR: rgb(0=3D2C0= >=3D2C255)=3D3B FO=3D
>=3B >=3BNT-FAMILY: 'Gill Sans'">=3BAntony Ho= >sking<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/FONT>=3B<=3B/FONT>=3B&l= >t=3BFONT cla=3D
>=3B >=3Bss=3D3DEC_EC_EC_Apple-style-span face=3D3D"= >Gill Sans">=3B<=3BSPAN class=3D3DEC_EC_EC_Ap=3D
>=3B >=3Bple-sty= >le-span style=3D3D"FONT-FAMILY: 'Gill Sans'">=3B<=3BSPAN class=3D3DEC_E= >C_EC_Ap=3D
>=3B >=3Bple-style-span style=3D3D"FONT-FAMILY: 'Gill San= >s'">=3B<=3BSPAN class=3D3DEC_EC_Apple=3D
>=3B >=3B-converted-spa= >ce>=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B|<=3BSPAN class=3D3DEC_EC_Apple-= >converted-space>=3B=3D
>=3B >=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B&= >lt=3B/SPAN>=3B<=3B/SPAN>=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-= >span style=3D
>=3B >=3B=3D3D"FONT-FAMILY: 'Gill Sans'">=3B<=3BSP= >AN class=3D3DEC_EC_EC_Apple-style-span style=3D
>=3B >=3B=3D3D"FONT-= >FAMILY: 'Gill Sans'">=3BAssociate Professor<=3B/SPAN>=3B<=3B/SPAN&g= >t=3B<=3BSPAN class=3D
>=3B >=3B=3D3DEC_EC_EC_Apple-style-span styl= >e=3D3D"FONT-FAMILY: 'Gill Sans'">=3B<=3BSPAN class=3D
>=3B >=3B= >=3D3DEC_EC_EC_Apple-style-span style=3D3D"FONT-FAMILY: 'Gill Sans'">=3B&a= >mp=3Bnbsp=3D3B| C=3D
>=3B >=3Bomputer Science | Purdue University<= >=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/FONT>=3B<=3B/DIV>=3B
>=3B = >>=3B<=3BDIV>=3B<=3BFONT class=3D3DEC_EC_EC_Apple-style-span face=3D= >3DGillSans-Light>=3B<=3BSPAN cl=3D
>=3B >=3Bass=3D3DEC_EC_EC_App= >le-style-span style=3D3D"FONT-FAMILY: GillSans-Light">=3B305 N=3D
>= >=3B >=3B. University Street | West Lafayette | IN 47907 | USA<=3B/SPAN&= >gt=3B<=3B/FONT>=3B<=3B/DIV>=3B
>=3B >=3B<=3BDIV>=3B<= >=3BFONT class=3D3DEC_EC_EC_Apple-style-span face=3D3D"Gill Sans" color=3D3D= >#00=3D
>=3B >=3B00ff>=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-= >span style=3D3D"COLOR: rgb(0=3D2C0=3D2C25=3D
>=3B >=3B5)=3D3B FONT-F= >AMILY: 'Gill Sans'">=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-span sty= >=3D
>=3B >=3Ble=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=3D3B FONT-FAMILY: '= >Gill Sans'">=3BOffice<=3B/SPAN>=3B<=3B/S=3D
>=3B >=3BPAN>= >=3B<=3B/FONT>=3B<=3BFONT class=3D3DEC_EC_EC_Apple-style-span face=3D3= >DGillSans-Light>=3B<=3BS=3D
>=3B >=3BPAN class=3D3DEC_EC_EC_Appl= >e-style-span style=3D3D"FONT-FAMILY: GillSans-Light"=3D
>=3B >=3B>= >=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-span style=3D3D"FONT-FAMILY: G= >illSans-Lig=3D
>=3B >=3Bht">=3B&=3Bnbsp=3D3B+1 765 494 6001 |&l= >t=3BSPAN class=3D3DEC_EC_Apple-converted-space>=3B&=3Bnbs=3D
>=3B= > >=3Bp=3D3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/FONT= >>=3B<=3BFONT class=3D3DEC_EC_EC_Apple-style-span fac=3D
>=3B >= >=3Be=3D3D"Gill Sans" color=3D3D#0000ff>=3B<=3BSPAN class=3D3DEC_EC_EC_A= >pple-style-span sty=3D
>=3B >=3Ble=3D3D"COLOR: rgb(0=3D2C0=3D2C255)= >=3D3B FONT-FAMILY: 'Gill Sans'">=3B<=3BSPAN class=3D3DEC=3D
>=3B &= >gt=3B_EC_EC_Apple-style-span style=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=3D3B FO= >NT-FAMILY: 'G=3D
>=3B >=3Bill Sans'">=3BMobile<=3B/SPAN>=3B<= >=3B/SPAN>=3B<=3B/FONT>=3B<=3BFONT class=3D3DEC_EC_EC_Apple-style-sp= >=3D
>=3B >=3Ban face=3D3DGillSans-Light>=3B<=3BSPAN class=3D3DEC= >_EC_EC_Apple-style-span style=3D3D"F=3D
>=3B >=3BONT-FAMILY: GillSan= >s-Light">=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-span style=3D
&g= >t=3B >=3B=3D3D"FONT-FAMILY: GillSans-Light">=3B<=3BSPAN class=3D3DEC_= >EC_Apple-converted-space>=3B=3D
>=3B >=3B&=3Bnbsp=3D3B<=3B/SP= >AN>=3B+1 765 427 5484<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/FONT>=3B&= >lt=3B/DIV>=3B
>=3B >=3B<=3BDIV>=3B<=3BFONT class=3D3DEC_EC_E= >C_Apple-style-span face=3D3DGillSans-Light>=3B<=3BBR clas=3D
>=3B = >>=3Bs=3D3DEC_EC_EC_khtml-block-placeholder>=3B<=3B/FONT>=3B<=3B/D= >IV>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SP=3D
= >>=3B >=3BAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<= >=3BBR class=3D3DEC_EC_EC_Apple-interchange-newline>=3B<=3B/SP=3D
>= >=3B >=3BAN>=3B<=3B/DIV>=3B<=3B/SPAN>=3B<=3B/DIV>=3B<=3BBR= >>=3B
>=3B >=3B<=3BDIV>=3B
>=3B >=3B<=3BDIV>=3BOn 12= > Jan 2009=3D2C at 01:44=3D2C Jay wrote:<=3B/DIV>=3B<=3BBR class=3D3DE= >C_EC_EC_App=3D
>=3B >=3Ble-interchange-newline>=3B
>=3B >= >=3B<=3BBLOCKQUOTE>=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-span sty= >le=3D3D"WORD-SPACING: =3D
>=3B >=3B0px=3D3B FONT: 12px Helvetica=3D3= >B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0=3D
>=3B >=3B)= >=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal= >=3D3B B=3D
>=3B >=3BORDER-COLLAPSE: separate">=3B
>=3B >=3B= ><=3BDIV class=3D3DEC_EC_EC_hmmessage style=3D3D"FONT-SIZE: 10pt=3D3B FONT= >-FAMILY: Ve=3D
>=3B >=3Brdana">=3BIs there a way in Modula-3 to de= >clare that&=3Bnbsp=3D3Ba type exists=3D2C a=3D
>=3B >=3Bnd there = >are &=3Blt=3D3B*external*&=3Bgt=3D3B instances of it=3D2C without "fu= >lly" decl=3D
>=3B >=3Baring it=3D2C so that no Modula-3 can instanti= >ate it?<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3BI have d=3D
>=3B &g= >t=3Bone this for sigset_t and sem_t=3D2C but they could erroneously be inst= >antiat=3D
>=3B >=3Bed by Modula-3 and I'd like to remove that abilit= >y to mess up so easily.<=3BBR=3D
>=3B >=3B>=3B&=3Bnbsp=3D3B&l= >t=3BBR>=3B(* This type is not declared correctly. It is only instantiate= >=3D
>=3B >=3Bd in C code. *)<=3BBR>=3B&=3Bnbsp=3D3B sigset_t = >=3D3D RECORD END=3D3B<=3BBR>=3B<=3BBR>=3B(* This type =3D
>=3B= > >=3Bis not declared correctly. It is only instantiated in C code. *)<= >=3BBR>=3B&=3Bnbsp=3D
>=3B >=3B=3D3B sem_t =3D3D RECORD END=3D3B= ><=3BBR>=3B<=3BBR>=3BIn C I believe you can do this=3D2C like:<=3B= >=3D
>=3B >=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3Btypedef struct = >foo foo_t=3D3B&=3Bnbsp=3D3B<=3BSPAN class=3D3DEC_EC_E=3D
>=3B >= >=3BC_Apple-converted-space>=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BBR&g= >t=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3Bextern foo_t foo=3D
>=3B >=3B=3D= >3B&=3Bnbsp=3D3B<=3BSPAN class=3D3DEC_EC_EC_Apple-converted-space>=3B= >&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BBR>=3B=3D
>=3B >=3B&=3Bn= >bsp=3D3B<=3BBR>=3B&=3Bnbsp=3D3Bvoid UseFoo(foo_t*)=3D3B<=3BSPAN cl= >ass=3D3DEC_EC_EC_Apple-conv=3D
>=3B >=3Berted-space>=3B&=3Bnbsp= >=3D3B<=3B/SPAN>=3B<=3BBR>=3B&=3Bnbsp=3D3B foo_t* GetFoo(void)=3D= >3B<=3BSPAN class=3D
>=3B >=3B=3D3DEC_EC_EC_Apple-converted-space&g= >t=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR= >>=3BThanks=3D2C<=3B=3D
>=3B >=3BBR>=3B&=3Bnbsp=3D3B- Jay<= >=3BBR>=3B<=3BBR>=3B<=3BBR>=3B<=3BBR>=3B<=3B/DIV>=3B<=3B= >/SPAN>=3B<=3B/BLOCKQUOTE>=3B<=3B/DIV>=3B<=3BBR>=3B<=3B/DIV&= >gt=3B<=3B=3D
>=3B >=3B/DIV>=3B<=3B/SPAN>=3B<=3BBR class=3D= >3DEC_EC_Apple-interchange-newline>=3B<=3B/BLOCKQUOTE>=3B<=3B/DIV>= >=3B=3D
>=3B >=3B<=3BBR>=3B<=3B/DIV>=3B<=3B/SPAN>=3B<= >=3BBR class=3D3DEC_Apple-interchange-newline>=3B<=3B/BLOCKQUOTE>=3B&l= >t=3B/DI=3D
>=3B >=3BV>=3B<=3BBR>=3B<=3B/body>=3B
>=3B= > >=3B<=3B/html>=3B=3D
>=3B >=3B
>=3B >=3B--_6117a048-91= >85-4c03-badb-ef8f93402268_--

>= > >--_2e194b09-14b6-4301-9116-a9e4d1e522b4_-- From jay.krell at cornell.edu Mon Jan 12 11:24:37 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 10:24:37 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: <200901121013.n0CADQE0075969@camembert.async.caltech.edu> References: Your message of "Mon, 12 Jan 2009 09:56:43 GMT." <200901121013.n0CADQE0075969@camembert.async.caltech.edu> Message-ID: I don't at this time want to write C a parser. (Actually I do, as part of an entire compiler, but...) I'd rather run the one I already have -- the C compiler. I briefly in the past dreamt that C programmers might start writing "xml" (schema?!) or "idl". Oh, and you can't rely on headers being written in an easy to parse C subset. There are inlines, #pragmas, compiler-specific extensions, etc. Best just to use them as part of compiling C with the intended compiler. Well, I have parsed C subsets actually..more than once. One didn't really have to be very complete. One "lived" with the headers and there was flexibility to fix the headers to suit. - Jay> To: jay.krell at cornell.edu> Date: Mon, 12 Jan 2009 02:13:25 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?> > > I think you're misunderstanding me a bit. You don't need C either.> I would use a Lisp-based language for the "top level" just because> they are good at handling things like parse trees, if one gets to> that.> > The objectives are:> > * A finished system in Pure Modula-3 (no executable C)> > * Make it as self-contained as possible> > You'd start by simply bundling the existing headers with m3bundle> and printing them out. Then you'd find duplication (what you've> been doing) and express that programmatically. Then you might find> things that might conceivably change in the OS headers and use> whatever tricks were necessary to figure them out automatically.> Does this involve C? Maybe on some architecture it does, maybe on> another it doesn't. On some it might not involve running C but> merely parsing C headers. Perhaps the program is just hand-written> and just a way of distilling all the duplication into one place> where it can be clearly described and documented. Since this is a> Modula-3 distribution, obviously the program I'm talking about is> written in Modula-3, not in C or Perl or Python.> > Mika> > Jay writes:> >--_2e194b09-14b6-4301-9116-a9e4d1e522b4_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >Yes=2C generating the headers is viable.> >I thought I mentioned that a few times.> >They could be generated in any build "that can". i.e. a native build=2C th=> >at has a working C development system and checked against the checked in o=> >nes.> > So then porting is: copy the generator to new system=2C run it=2C copy r=> >esults back=2C proceed=20> > Maybe a good compromise. Not good for "embedded systems"=2C but heck=2C i=> >s there any such thing any longer? Doesn't everything have megs of RAM and=> > gigs of persistant storage? :)> >You don't need Scheme.> >Just Quake + compiling and running C code.> >Assuming a native build system.> >I've done stuff in cross build systems like:> >typedef struct foo_t {int i=3B int j=3B } foo_t=3B> >extern const int xi =3D offsetof(foo_t=2C i)=3B> >=20> >compile that=2C and read the value of xi out of the .obj file.> >=20> > The .obj file reader was written in Perl. :)=20> > (Python not available.)> > but to do that here=2C I'd have to support multiple .obj file formats.> >=20> > - Jay> To: jay.krell at cornell.edu> Date: Mon=2C 12 Jan 2009 01:34:24 -0800>=> > From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3d=> >evel] declaring a type's existance but not enough to instantiate it?> > > Y=> >ou present it as a true tragic Dilemma.> > But isn't there a Third Way---to=> > wit=2C can't you "Ask the Computer"> to do the work for you?> > Generate t=> >he code somehow... Parsing the C headers is an obvious> way but there may b=> >e others that are simpler=2C such as writing a> Modula-3 program to generat=> >e the cloned M3 headers=2C sorry=2C interfaces.> > If I had to do this I wo=> >uld use my Scheme interpreter that's coded> in Modula-3 to write a Scheme p=> >rogram to generate the headers. This> program could pull whatever tricks ar=> >e deemed necessary and suitable=2C> down to the point of generating and com=> >piling and running C programs> as necessary (or parsing C code=2C or readin=> >g tea leaves). But the> end result would be a set of interfaces written in => >"Pure Modula-3".> The process of running the header generator would also ha=> >ve very> few dependencies on anything outside the M3 distribution.> > Mika>=> > > Jay writes:> >--_6117a048-9185-4c03-badb-ef8f93402268_> >Content-Type: t=> >ext/plain=3B charset=3D"iso-8859-1"> >Content-Transfer-Encoding: quoted-pri=> >ntable> >> >> >This is what you "have to" chose between.> >Header cloning o=> >r C code (and C headers).> >=3D20> >CONST or VAR (or functions?)> >=3D20> >=> >I'm going to likely make the Uerror change tonight.> >You can still veto it=> > (er=3D2C vote against it :) )> >=3D20> >Possibly some convuluted C (enum/#=> >undef)=3D2C or splitting the Modula-3> >at boundaries that weren't previous=> >ly believed "natural".> >(See how SetupHandlers is ~two lines in Modula-3 a=> >nd the rest in C=3D3B> >this is partly out of ignorance. I don't know how t=> >o write those> >two lines in C=3D3B and laziness=3D2C I didn't look into ho=> >w).> >=3D20> >=3D20> >=3D20> >Remember I'm still staying away from mainstre=> >am platforms=3D2C> >so the value isn't what it might appear to be=3D2C but => >it is "stage setting"=3D> >=3D2C> >and the show might go on. :)> >=3D20> >=> >=3D20> >Also=3D2C the dilemna does get more difficult now=3D2C with the lit=> >tle C header=3D> > cloning that remains.> >=3D20> >For example=3D2C look at=> > Upthreads.i3.> >Mainly=3D2C look at function prototypes.> >Constants and t=> >ypes are "known problems".> >Prototypes are gray. They actually tend to be => >portable.> >=3D20> >For example:> >=3D20> >TYPE pid_t =3D3D INTEGER=3D3B> >=> ><*EXTERNAL "m3_getpid*> PROCEDURE getpid():pid_t=3D3B> >=3D20> >or leave it=> > alone?> >getpid is probably the worst example.> >It is so very portable de=> >clared in Modula-3.> >But still=3D2C imagine pid_t might be 16bits or 32 or=> > 64.> >Writing a wrapper is more portable -- as long as the pid isn't stuff=> > into s=3D> >ome record that the system defines.> >=3D20> >=3D20> >Again=3D=> >2C Upthreads.i3.> >Would you like to see it reduced=3D2C or left alone?> >O=> >nly deal with the types and initializers=3D2C or also the prototypes?> >You=> > know=3D2C I could write a little portable layer=3D2C where all the types a=> >r=3D> >e pointers=3D2C always null initialized.> >It would buy /some/ porta=> >bility=3D2C and cost some.> >=3D20> >=3D20> >Do you like the sem_t change? => >Partly? Not at all?> >There is one sem_t in the system. So I moved it to be=> > in C code.> >Or=3D2C as I had it before=3D2C declared as the max size/alig=> >n of all the platf=3D> >orms -- getting that right is the same work as gett=> >ing it right "the old wa=3D> >y"=3D2C except if you make a mistake=3D2C odd=> >s are still good of it being ok.> >=3D20> >=3D20> >Should the line be drawn=> > at generating the remaining headers=3D2C rather than=3D> > eliminating the=> >m?> >Uerror.i3 is easily generated. Good enough?> >=3D20> >Upthread.i3's ty=> >pes can be generated generally as records with opaque array=3D> >s with the=> > right size and alignment.> >=3D20> >Other stuff can be generated or at lea=> >st checked.> >e.g. to check that getpid is declared correctly=3D2C you can => >assign it to a f=3D> >unction pointer and see if that compiles.> >=3D20> >P=> >erf on Uerror arguably doesn't matter.> >Is it only error handling code?Or => >do sockets often go down "error" paths=3D2C=3D> > because they are slow and=> > you are waiting for more data?> >=3D20> >Anyway=3D2C point is=3D2C I agree=> > for sure this is valuable=3D2C but I might be h=3D> >itting the "tail" of => >the approach and should switch=3D2C I'm not sure. I keep=3D> > saying that => >though=3D2C and then press further.> >=3D20> >=3D20> > - Jay> >> >> >> >Fro=> >m: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon=3D2C 12 Jan 200=> >=3D> >9 19:24:50 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] decla=> >ring a=3D> > type's existance but not enough to instantiate it?> >> >> >Poi=> >nt taken. We live in a C universe and so need to interact. I do think =3D> => >>your work with the headers is useful=3D2C and I want it to continue. Espec=> >ia=3D> >lly in simplifying ports.> >> >> >On 12 Jan 2009=3D2C at 19:18=3D2C=> > Jay wrote:> >> >I don't think a development system without C headers is in=> >teresting.. Is it=3D> > really? The transform I apply at times is wherever => >there is interaction wi=3D> >th C code that is described by system-dependen=> >t headers=3D2C or perhaps even =3D> >fairly system-independent headers outs=> >ide the Modula-3 tree=3D2C either write=3D> > wrapper functions for the fun=> >ctionality in the headers (e.g. stat=3D2C waitp=3D> >id)=3D2C which can be => >done in a system-independent way=3D2C or move the Modula-=3D> >3<->C transi=> >tion higher=3D2C which is also usually system-independent=3D2C e.g.=3D> > T=> >hreadPThreadC_SetupHandlers. It is either that or clone the headers=3D2C wh=> >=3D> >ich seems like the worse evil. There is always going to be a Modula-3=> ><->C t=3D> >ransition=3D2C it is just a matter of where it occurs. - Jay> >=> >> >CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornel=> >l.e=3D> >duSubject: Re: [M3devel] declaring a type's existance but not enou=> >gh to ins=3D> >tantiate it?Date: Mon=3D2C 12 Jan 2009 12:32:15 +1100> >> >>=> > >Jay=3D2C I really think you are bending over backwards too far just to be=> > abl=3D> >e to shoe-horn things into C. I *like* having the transpar of C h=> >eader fil=3D> >es expressed in Modula-3=3D2C *particularly* for system call=> >s=3D2C where you mi=3D> >ght even be trying to build on a system that does => >not have the C header fil=3D> >es installed=3D2C even though the libraries => >exist and can be linked to. Fund=3D> >amentally=3D2C I think anytime the Mo=> >dula-3 code is made less transparent you=3D> > should think hard about what=> > you are doing. The same with the change of c=3D> >onstants to variables.> => >>> >I am getting very nervous that the changes you are making are destroyin=> >g th=3D> >e clarity of the Modula-3 run-time code.> >> >In this particular => >case=3D2C you are wanting to use a Modula-3 parameter pass=3D> >ing mechani=> >sm on something that is not declared in Modula-3. Seems kind of=3D> > dubio=> >us to me. Also=3D2C I really don't like the idea of accessing external=3D> => >> variables in C.> >> >-- Tony> >> >On 12 Jan 2009=3D2C at 11:55=3D2C Jay w=> >rote:> >> >I considered ADDRESS.However I think it still doesn't satisfy. I=> > want to be=3D> > able to do this: TYPE Foo_t =3D3D something=3D3B<* EXTERN=> >AL *> VAR Foo1=3D2C Foo=3D> >2:Foo_t=3D3B<* EXTERNAL *> PROCEDURE UseFoo(RE=> >ADONLY (* or VAR *) foo:Foo_t)=3D> >=3D3B (* Modula-3=3D2C not external *)P=> >ROCEDURE x()=3D3DBEGIN UseFoo(Foo1)=3D3B U=3D> >seFoo(Foo2)=3D3BEND x=3D3B => >AND I want any use of:VAR Foo3:Foo3_t=3D3B (* Modula-3=3D> >=3D2C not exter=> >nal *)to error. This is sem_t and sigset_t in particular. Poss=3D> >ibly re=> >naming is the thing.They used to be declared in Modula-3=3D2C system-d=3D> => >>ependently=3D2C butI moved them to portable C. I could remove the types en=> >tir=3D> >ely and change UseFoo to take an address=3D2Cand declare mask and => >ackSem to b=3D> >e integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END=> >=3D3B That would sat=3D> >isfy but I thought it might be nicer to still pro=> >vide the namedtypes to ref=3D> >er to the external variables. - Jay> >> >Fr=> >om: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon=3D2C 12 Jan 200=> >=3D> >9 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] decla=> >ring a=3D> > type's existance but not enough to instantiate it?What's wrong=> > with using =3D> >ADDRESS for references to opaque values? If sigset_t is n=> >ever instantiated=3D> > in Modula-3=3D2C then why do you need it declared t=> >here?> >> >> >> >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 200=> >9=3D2C at 01:44=3D2C Jay wrote:> >> >Is there a way in Modula-3 to declare => >that a type exists=3D2C and there are <=3D> >*external*> instances of it=3D=> >2C without "fully" declaring it=3D2C so that no M=3D> >odula-3 can instanti=> >ate it? I have done this for sigset_t and sem_t=3D2C but =3D> >they could e=> >rroneously be instantiated by Modula-3 and I'd like to remove t=3D> >hat ab=> >ility to mess up so easily. (* This type is not declared correctly. I=3D> >=> >t is only instantiated in C code. *) sigset_t =3D3D RECORD END=3D3B(* This => >typ=3D> >e is not declared correctly. It is only instantiated in C code. *)=> > sem_t =3D> >=3D3D RECORD END=3D3BIn C I believe you can do this=3D2C like:=> > typedef struct fo=3D> >o foo_t=3D3B extern foo_t foo=3D3B void UseFoo(foo_=> >t*)=3D3B foo_t* GetFoo=3D> >(void)=3D3B Thanks=3D2C - Jay=3D> >> >--_6117a0=> >48-9185-4c03-badb-ef8f93402268_> >Content-Type: text/html=3B charset=3D"iso=> >-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >=> >> >> ><=> >/head>> >> >This is what you "have to" chose be=> >tween.
> >Header cloning or C code (and C headers).
> > =3D3B
=> >> >CONST or VAR (or functions?)
> > =3D3B
> >I'm going to likely => >make the Uerror change tonight.
> >You can still veto it (er=3D2C vote a=> >gainst it :) )
> > =3D3B
> >Possibly some convuluted C (enum/#und=> >ef)=3D2C or splitting the Modula-3
> >at boundaries that weren't previou=> >sly believed "natural".
> >(See how SetupHandlers is ~two lines in Modul=> >a-3 and the rest in C=3D3B
> >this is partly out of ignorance. I don't k=> >now how to write those
> >two lines in C=3D3B and laziness=3D2C I didn't=> > look into how).
> > =3D3B
> > =3D3B
> > =3D3B
> >R=> >emember I'm still staying away from mainstream platforms=3D2C
> >so the => >value isn't what it might appear to be=3D2C but it is "stage setting"=3D> >=> >=3D2C
> >and the show might go on. :)
> > =3D3B
> > =3D3B<=> >BR>> >Also=3D2C the dilemna does get more difficult now=3D2C with the littl=> >e C header=3D> > cloning that remains.
> > =3D3B
> >For example=> >=3D2C look at Upthreads.i3.
> >Mainly=3D2C look at function prototypes.<=> >BR>> >Constants and types are "known problems".
> >Prototypes are gray. => >They actually tend to be portable.
> > =3D3B
> >For example:
>=> > > =3D3B
> >TYPE pid_t =3D3D INTEGER=3D3B
> ><=3D3B*EXTERNAL "m=> >3_getpid*>=3D3B PROCEDURE getpid():pid_t=3D3B
> > =3D3B
> >or l=> >eave it alone?
> >getpid is probably the worst example.
> >It is so v=> >ery portable declared in Modula-3.
> >But still=3D2C imagine pid_t might=> > be 16bits or 32 or 64.
> >Writing a wrapper is more portable -- as long=> > as the pid isn't stuff into s=3D> >ome record that the system defines.
=> >> > =3D3B
> > =3D3B
> >Again=3D2C Upthreads.i3.
> >Would y=> >ou like to see it reduced=3D2C or left alone?
> >Only deal with the type=> >s and initializers=3D2C or also the prototypes?
> >You know=3D2C I could=> > write a little portable layer=3D2C where all the types ar=3D> >e pointers=> >=3D2C always null initialized.
> >It would buy /some/ portability=3D2C a=> >nd cost some.
> > =3D3B
> > =3D3B
> >Do you like the sem_t=> > change? Partly? Not at all?
> >There is one sem_t in the system. So I m=> >oved it to be in C code.
> >Or=3D2C as I had it before=3D2C declared as => >the max size/align of all the platf=3D> >orms -- getting that right is the => >same work as getting it right "the old wa=3D> >y"=3D2C except if you make a=> > mistake=3D2C odds are still good of it being ok. >R>> > =3D3B >>> > =3D3B
> >Should the line be drawn at generating the remaining h=> >eaders=3D2C rather than=3D> > eliminating them?
> >Uerror.i3 is easily g=> >enerated. Good enough?
> > =3D3B
> >Upthread.i3's types can be ge=> >nerated generally as records with opaque array=3D> >s with the right size a=> >nd alignment.
> > =3D3B
> >Other stuff can be generated or at lea=> >st checked.
> >e.g. to check that getpid is declared correctly=3D2C you => >can assign it to a f=3D> >unction pointer and see if that compiles.
> >&=> >nbsp=3D3B
> >Perf on Uerror arguably doesn't matter.
> >Is it only er=> >ror handling code?
Or do sockets often go down "error" path=3D> >s=3D2C => >because they are slow and you are waiting for more data?
> > =3D3B >R>> >Anyway=3D2C point is=3D2C I agree for sure this is valuable=3D2C but I=> > might be h=3D> >itting the "tail" of the approach and should switch=3D2C I=> >'m not sure. I keep=3D> > saying that though=3D2C and then press further. >R>> > =3D3B
> > =3D3B
> > =3D3B- Jay

> >> >
>=3D3DstopSpelling>>
> >From: hosking at cs.purdue.edu
To: jay.krell at cor=> >nell.edu
Date: Mon=3D2C 12=3D> > Jan 2009 19:24:50 +1100
CC: m3devel@=> >elegosoft.com
Subject: Re: [M3de=3D> >vel] declaring a type's existance => >but not enough to instantiate it?

=3D> >
> >
>EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: =3D> >12px Helv=> >etica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-IN=> >D=3D> >ENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B B=> >ORDER-COLLAPS=3D> >E: separate">> >
<=> >SPAN class=3D3DEC_Apple-style-span styl=3D> >e=3D3D"WORD-SPACING: 0px=3D3B => >FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B C=3D> >OLOR: rgb(0=3D2C=> >0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-S=3D> >=> >PACING: normal=3D3B BORDER-COLLAPSE: separate"> >le-s=3D> >pan style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B T=> >EXT-TRANSFORM: n=3D> >one=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: => >0px=3D3B WHITE-SPACE: normal=3D3B =3D> >LETTER-SPACING: normal=3D3B BORDER-=> >COLLAPSE: separate"> >-style-span style=3D3D"WO=> >RD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRAN=3D> >SFORM: none=> >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: no=> >=3D> >rmal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate"> >N class=3D3D=3D> >EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FON=> >T: 12px Helvetica=3D3B T=3D> >EXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=> >=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-S=3D> >PACE: normal=3D3B LETTER-SP=> >ACING: normal=3D3B BORDER-COLLAPSE: separate"> >class=3D3DEC_Appl=> >e-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvet=3D> >ica=> >=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT:=> > 0px=3D3B=3D> > WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER=> >-COLLAPSE: separate=3D> >"> >ORD-SPACING: 0px=3D3B FONT: 12p=3D> >x Helvetica=3D3B TEXT-TRANSFORM: none=> >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT=3D> >: 0px=3D3B WHITE-SPAC=> >E: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: =3D> >separate"=> >> >> >ONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D=> >2C0)=3D3B TEX=3D> >T-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACI=> >NG: normal=3D3B BORDER-CO=3D> >LLAPSE: separate"> >tyle-span style=3D3D"WORD-SPACING: =3D> >0px=3D3B FONT: 12px Helvetica=3D3B=> > TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0=3D> >)=3D3B TEXT-INDENT=> >: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B B=3D> >ORDE=> >R-COLLAPSE: separate">> >
Point taken.  =3D3BWe live in a C univers=> >e and so need to interact. =3D> > =3D3BI do think your work with the he=> >aders is useful=3D2C and I want it to=3D> > continue.  =3D3BEspecially => >in simplifying ports.
> >

 >SPAN> >V>
> >
> >
On 12 Ja=> >n 2009=3D2C at 19:18=3D2C Jay wrote:

>e=> >rchange-newline>> >
>3D"WORD-SPACING: 0px=3D3B=3D> > FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: n=> >one=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B T=3D> >EXT-INDENT: 0px=3D3B WHITE-S=> >PACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-=3D> >COLLAPSE: separa=> >te">> >
>ILY: Verdana"=3D> >>I don't think a development system without C headers is=> > interesting.. Is i=3D> >t really?
 =3D3B
The transform I apply a=> >t times is wherever there i=3D> >s interaction with C code that is describe=> >d by system-dependent headers=3D2C =3D> >or perhaps even fairly system-inde=> >pendent headers outside the Modula-3 tree=3D> >=3D2C either write wrapper f=> >unctions for the functionality in the headers (e.=3D> >g. stat=3D2C waitpid=> >)=3D2C which =3D3Bcan be done in a system-independent way=3D> >=3D2C&nb=> >sp=3D3Bor move the Modula-3<=3D3B->=3D3BC transition higher=3D2C which => >is=3D> > also usually system-independent=3D2C e.g. ThreadPThreadC_SetupHand=> >lers.
&=3D> >nbsp=3D3B
It is either that or clone the headers=3D2C wh=> >ich seems like the w=3D> >orse evil.
 =3D3B
There is always going=> > to be a Modula-3<=3D3B->=3D> >=3D3BC transition=3D2C it is just a matt=> >er of where it occurs.
 =3D3B
&=3D> >nbsp=3D3B- Jay

> > > id=3D3DEC_stopSpelling>> >
CC:=> > =3D3B >lto:m3devel at elegosoft.com">m3devel at e=> >legosoft.com
From: >EC_Apple-converted-space>&nb=> >sp=3D3B >.edu">hosking at cs.p=> >urdue.edu
To: >e> =3D=> >3Bjay.krell at cornell=3D> >=> >.edu
Subject: Re: [M3devel] declaring a type's existance but not eno=> >=3D> >ugh to instantiate it?
Date: Mon=3D2C 12 Jan 2009 12:32:15 +1100 >R>
>R>>
>RD-SPACING: 0px=3D3B FON=3D> >T: 12px Helvetica=3D3B TEXT-TRANSFORM: none=> >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-=3D> >INDENT: 0px=3D3B WHITE-SPAC=> >E: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLL=3D> >APSE: separate"=> >>> >
>e-span s=3D> >tyle=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TE=> >XT-TRANSFORM: none=3D> >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0=> >px=3D3B WHITE-SPACE: normal=3D3B LET=3D> >TER-SPACING: normal=3D3B BORDER-C=> >OLLAPSE: separate"> >-style-span style=3D3D"=> >WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRAN=3D> >SFORM: none=> >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: no=> >=3D> >rmal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate"> >N class=3D3D=3D> >EC_EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B => >FONT: 12px Helvetica=3D> >=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C=> >0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WH=3D> >ITE-SPACE: normal=3D3B LETTER-S=> >PACING: normal=3D3B BORDER-COLLAPSE: separate"><=3D> >SPAN class=3D3DEC_EC_=> >Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12p=3D> >x Helveti=> >ca=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDEN=> >T=3D> >: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORD=> >ER-COLLAPSE: =3D> >separate"> >=3D3D"WORD-SPACING: 0px=3D> >=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM=> >: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D> >=3D3B TEXT-INDENT: 0px=3D3B WHIT=> >E-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BO=3D> >RDER-COLLAPSE: sep=> >arate"> >-SPACING=> >: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb=> >=3D> >(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B L=> >ETTER-SPACING: n=3D> >ormal=3D3B BORDER-COLLAPSE: separate"> >DEC_EC_Apple-style-span st=3D> >yle=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px => >Helvetica=3D3B TEXT-TRANSFORM: none=3D3B=3D> > COLOR: rgb(0=3D2C0=3D2C0)=3D=> >3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER=3D> >-SPACING: nor=> >mal=3D3B BORDER-COLLAPSE: separate"> >yle=> >-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRAN=> >SFO=3D> >RM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B=> > WHITE-SPACE: norma=3D> >l=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE=> >: separate">> >
Jay=3D2C I really think you are bending over backwards => >too far just to b=3D> >e able to shoe-horn things into C.  =3D3BI *like=> >* having the transpar of =3D> >C header files expressed in Modula-3=3D2C *p=> >articularly* for system calls=3D2C =3D> >where you might even be trying to => >build on a system that does not have the =3D> >C header files installed=3D2=> >C even though the libraries exist and can be link=3D> >ed to.  =3D3BFun=> >damentally=3D2C I think anytime the Modula-3 code is made l=3D> >ess transp=> >arent you should think hard about what you are doing.  =3D3BThe=3D> > s=> >ame with the change of constants to variables.
> >

> > >IV>I am getting very nervous that the changes you are making are destroyi=> >=3D> >ng the clarity of the Modula-3 run-time code.
> >

=> >> >
In this particular case=3D2C you are wanting to use a Modula-3 para=> >meter=3D> > passing mechanism on something that is not declared in Modula-3=> >.  =3D3BS=3D> >eems kind of dubious to me.  =3D3BAlso=3D2C I really=> > don't like the idea of=3D> > accessing external variables in C.
> > >IV>
> >
-- Tony
>><=3D> >/DIV>

> >
> >
On 12 Jan 2009=> >=3D2C at 11:55=3D2C Jay wrote:

>interch=> >ange-newline>> >
>3D"WORD-SPACING: 0px=3D> >=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: n=> >one=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D> >=3D3B TEXT-INDENT: 0px=3D3B WHITE-S=> >PACE: normal=3D3B LETTER-SPACING: normal=3D3B BO=3D> >RDER-COLLAPSE: separa=> >te">> >
>FAMILY: Verda=3D> >na">I considered ADDRESS.
However I think it still do=> >esn't satisfy.
&=3D> >nbsp=3D3B
I want to be able to do this:
&nbs=> >p=3D3B
TYPE =3D3BFoo_t =3D> >=3D3D something=3D3B
<=3D3B* EXTER=> >NAL *>=3D3B VAR Foo1=3D2C Foo2:Foo_t=3D3B
&=3D> >lt=3D3B* EXTERNAL *&g=> >t=3D3B PROCEDURE =3D3BUseFoo(READONLY (* or VAR *) foo:F=3D> >oo_t)=3D3=> >B
 =3D3B
(* Modula-3=3D2C not external *)
PROCEDURE x()=3D3D<=> >=3D> >BR>BEGIN
 =3D3B UseFoo(Foo1)=3D3B
 =3D3B UseFoo(Foo2)=> >=3D3B
END x=3D> >=3D3B
 =3D3B
AND I want any use of:
VAR Fo=> >o3:Foo3_t=3D3B (* Modula-3=3D> >=3D2C not external *)

to error. This=> > is sem_t and sigset_t in particul=3D> >ar.
 =3D3B
Possibly renam=> >ing is the thing.
They used to be decla=3D> >red in Modula-3=3D2C system=> >-dependently=3D2C but
I moved them to portable C.=3D> >
 =3D3B >>I could remove the types entirely and change UseFoo to take=3D> > an addre=> >ss=3D2C
and declare mask and ackSem to be integers or I guess. >>=> ><=3D3B*EXTERNAL>=3D3B VAR ackSem =3D3B: RECORD END=3D3B
 =3D=> >3B
Tha=3D> >t would satisfy but I thought it might be nicer to still pro=> >vide the named<=3D> >BR>types to refer to the external variables.
 => >=3D3B
 =3D3B- Jay >R>
> >
> ><=> >BR>From: =3D3B >f=3D> >=3D3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu
To:=> > >ss=3D3DEC_EC_Apple-converted-space> =3D3B >=3D3D"mailto:jay.krell=3D> >@cornell.edu">jay.krell at cornell.edu
Date=> >: Mon=3D2C 12 Jan 2009 11:13:0=3D> >0 +1100
CC: >le-converted-space> =3D3B >ref=3D3D"mailto:m3devel at elego=> >soft.com">m3devel at elegosoft.com
Subject: =3D> >Re: [M3devel] declari=> >ng a type's existance but not enough to instantiate it=3D> >?

What's=> > wrong with using ADDRESS for references to opaque values? &=3D> >nbsp=3D3B=> >If sigset_t is never instantiated in Modula-3=3D2C then why do you nee=3D> => >>d it declared there?
> >

> >
>-style-span style=3D3D"WORD-SPACING: 0px=3D3B =3D> >FONT: 12px Helvetica=3D=> >3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TE=3D> >XT-INDE=> >NT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-C=> >=3D> >OLLAPSE: separate">> >
>ass=3D3DEC_EC_EC_Apple-style-spa=3D> >n style=3D3D"WORD-SPACING: 0px=3D3B F=> >ONT: 12px Helvetica=3D3B TEXT-TRANSFORM: non=3D> >e=3D3B COLOR: rgb(0=3D2C0=> >=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LE=3D> >TTER-SP=> >ACING: normal=3D3B BORDER-COLLAPSE: separate"> >> >pple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=> >=3D3B TEXT-=3D> >TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-I=> >NDENT: 0px=3D3B WHITE-SPACE=3D> >: normal=3D3B LETTER-SPACING: normal=3D3B => >BORDER-COLLAPSE: separate"> >s=3D3DEC_EC_EC_Apple-style-span => >style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helv=3D> >etica=3D3B TEXT-TRAN=> >SFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D> >=3D3B=> > WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: sepa=> >r=3D> >ate"> >NG: 0px=3D3B =3D> >FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLO=> >R: rgb(0=3D2C0=3D2C0)=3D3B TE=3D> >XT-INDENT: 0px=3D3B WHITE-SPACE: normal=> >=3D3B LETTER-SPACING: normal=3D3B BORDER-C=3D> >OLLAPSE: separate"> >ass=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SP=3D> >ACING: 0px=3D3B F=> >ONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D> >=3D2C0=> >=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING:=> > nor=3D> >mal=3D3B BORDER-COLLAPSE: separate"> >e-style-span s=3D> >tyle=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=> >=3D3B TEXT-TRANSFORM: none=3D> >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-I=> >NDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LET=3D> >TER-SPACING: normal=3D3B => >BORDER-COLLAPSE: separate"> >ple-style-span => >style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-T=3D> >RAN=> >SFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE=> >-SPACE:=3D> > normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: sepa=> >rate"> >=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SPACI=> >NG: 0px=3D3B FONT: 12px Helve=3D> >tica=3D3B TEXT-TRANSFORM: none=3D3B COLO=> >R: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D> >=3D3B WHITE-SPACE: normal=> >=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separ=3D> >ate">> >
=> > >D=3D> >EC_EC_EC_Apple-style-span face=3D3D"Gill Sans"> >_EC_Apple-s=3D> >tyle-span style=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=3D3B FONT=> >-FAMILY: 'Gill Sans'"> >AN class=3D3DEC_EC_EC_Apple-style-span style=> >=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=3D3B FO=3D> >NT-FAMILY: 'Gill Sans'">Anto=> >ny Hosking >ss=3D3DEC_EC_EC_Apple-=> >style-span face=3D3D"Gill Sans"> >ple-style-=> >span style=3D3D"FONT-FAMILY: 'Gill Sans'"> >=> >ple-style-span style=3D3D"FONT-FAMILY: 'Gill Sans'"> >pple=3D> >-converted-space> =3D3B| >nverted-space>=3D> > =3D3B >_Apple-style-span style=3D> >=3D3D"FONT-FAMILY: 'Gill Sans'"> >3DEC_EC_EC_Apple-style-span style=3D> >=3D3D"FONT-FAMILY: 'Gill Sans'">Asso=> >ciate Professor >=3D3DEC_EC_EC_Apple-style-spa=> >n style=3D3D"FONT-FAMILY: 'Gill Sans'"> >=3D3DEC_EC_EC_Apple=> >-style-span style=3D3D"FONT-FAMILY: 'Gill Sans'"> =3D3B| C=3D> >omputer=> > Science | Purdue University
> >
>=3D3DEC_EC_EC_Apple-style-span face=3D3DGillSans-Light> >ass=3D=> >3DEC_EC_EC_Apple-style-span style=3D3D"FONT-FAMILY: GillSans-Light">305 N=> >=3D> >. University Street | West Lafayette | IN 47907 | USA >DIV>> >
>color=3D3D#00=3D> >00ff> >D"COLOR: rgb(0=3D2C0=3D2C25=3D> >5)=3D3B FONT-FAMILY: 'Gill Sans'"> >ass=3D3DEC_EC_EC_Apple-style-span sty=3D> >le=3D3D"COLOR: rgb(0=3D2C0=3D2C2=> >55)=3D3B FONT-FAMILY: 'Gill Sans'">Office >PAN> >lass=3D3DEC_EC_EC_Apple-style-span face=3D3DGillSans-Light> >PAN clas=> >s=3D3DEC_EC_EC_Apple-style-span style=3D3D"FONT-FAMILY: GillSans-Light"=3D>=> > >> >ns-Lig=3D> >ht"> =3D3B+1 765 494 6001 | >erted-space>&nbs=3D> >p=3D3B >EC_EC_Apple-style-span fac=3D> >e=3D3D"Gill Sans" color=3D3D#0000ff> >lass=3D3DEC_EC_EC_Apple-style-span sty=3D> >le=3D3D"COLOR: rgb(0=3D2C0=3D2C=> >255)=3D3B FONT-FAMILY: 'Gill Sans'"> >_EC_EC_Apple-st=> >yle-span style=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=3D3B FONT-FAMILY: 'G=3D> >i=> >ll Sans'">Mobile >p=3D> >an face=3D3DGillSans-Light> > style=3D3D"F=3D> >ONT-FAMILY: GillSans-Light"> >le-style-span style=3D> >=3D3D"FONT-FAMILY: GillSans-Light"> >DEC_EC_Apple-converted-space>=3D> > =3D3B+1 765 427 5484<=> >/SPAN>
> >
>=3D3DGillSans-Light>
>s=3D3DEC_EC_EC_khtml-block-placeholder> >FONT>
>AN>
>=3D3DEC_EC_EC_Apple-interchange-newline> >AN>
>>> >
> >
On 12 Jan 2009=3D2C at 01:44=3D2C Jay wrote:

>s=3D3DEC_EC_EC_App=3D> >le-interchange-newline>> >
>=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SPACING: =3D> >0px=3D3B FONT=> >: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0=3D=> >> >)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: no=> >rmal=3D3B B=3D> >ORDER-COLLAPSE: separate">> >
>sage style=3D3D"FONT-SIZE: 10pt=3D3B FONT-FAMILY: Ve=3D> >rdana">Is there a=> > way in Modula-3 to declare that =3D3Ba type exists=3D2C a=3D> >nd ther=> >e are <=3D3B*external*>=3D3B instances of it=3D2C without "fully" decl=> >=3D> >aring it=3D2C so that no Modula-3 can instantiate it?
 =3D3B >R>I have d=3D> >one this for sigset_t and sem_t=3D2C but they could erroneo=> >usly be instantiat=3D> >ed by Modula-3 and I'd like to remove that ability => >to mess up so easily. >> =3D3B
(* This type is not declared c=> >orrectly. It is only instantiate=3D> >d in C code. *)
 =3D3B sigset_=> >t =3D3D RECORD END=3D3B

(* This type =3D> >is not declared correctly=> >. It is only instantiated in C code. *)
 =3D> >=3D3B sem_t =3D3D REC=> >ORD END=3D3B

In C I believe you can do this=3D2C like:<=3D> >BR>&nbs=> >p=3D3B =3D3Btypedef struct foo foo_t=3D3B =3D3B >C_E=3D> >C_Apple-converted-space> =3D3B
 =3D3B =3D3Be=> >xtern foo_t foo=3D> >=3D3B =3D3B >d-space> =3D3B
=3D> > =3D3B
 =3D3Bvoid UseFoo(foo_=> >t*)=3D3B >erted-space> =3D3B >AN>
 =3D3B foo_t* GetFoo(void)=3D3B >=3D3DEC_EC_EC_Ap=> >ple-converted-space> =3D3B
 =3D3B
Thanks=3D2C<=3D> >BR=> >> =3D3B- Jay




<=> >=3D> >/DIV>
>E>
=3D> >

<=> >/BLOCKQUOTE> >V>
> >=3D> >> >--_6117a048-9185-4c03=> >-badb-ef8f93402268_--=> >> >--_2e194b09-14b6-4301-9116-a9e4d1e522b4_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >> >Yes=2C generating the headers is viable.
> >I thought I mentioned that a few times.
> They could be generated in any build "that can".
 =3B i.e. a native => >build=2C that has a working C development system
 =3B and checked ag=> >ainst the checked in ones.
> > =3BSo then porting is:
 =3B copy the generator to new system=> >=2C run it=2C copy results back=2C proceed
> >
 =3BMaybe a good compromise.
 =3BNot good for "embedded sys=> >tems"=2C but heck=2C is there any such thing
 =3B any longer? Doesn'=> >t everything have megs of RAM and gigs of persistant storage? :)
> >
You don't need =3BScheme.
> >Just Quake =3B+ compiling and running C code.
> >Assuming a native build system.
> >I've done stuff in cross build systems like:
> >typedef struct foo_t {int i=3B int j=3B } foo_t=3B
> >extern const int xi =3D offsetof(foo_t=2C i)=3B
> > =3B
> >compile that=2C and read the value of xi out of the .obj file.
> > =3B
> > =3BThe .obj file reader was written in Perl. :)
> > =3B (Python not available.)
> > =3Bbut to do that here=2C I'd have to support multiple .obj file forma=> >ts.
> > =3B
> > =3B- Jay

>=3B To: jay.krell at cornell.edu
>=3B Date: Mon=> >=2C 12 Jan 2009 01:34:24 -0800
>=3B From: mika at async.caltech.edu
&g=> >t=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] declaring a=> > type's existance but not enough to instantiate it?
>=3B
>=3B >R>>=3B You present it as a true tragic Dilemma.
>=3B
>=3B But => >isn't there a Third Way---to wit=2C can't you "Ask the Computer"
>=3B => >to do the work for you?
>=3B
>=3B Generate the code somehow... P=> >arsing the C headers is an obvious
>=3B way but there may be others th=> >at are simpler=2C such as writing a
>=3B Modula-3 program to generate => >the cloned M3 headers=2C sorry=2C interfaces.
>=3B
>=3B If I had=> > to do this I would use my Scheme interpreter that's coded
>=3B in Mod=> >ula-3 to write a Scheme program to generate the headers. This
>=3B pro=> >gram could pull whatever tricks are deemed necessary and suitable=2C
>=> >=3B down to the point of generating and compiling and running C programs >>>=3B as necessary (or parsing C code=2C or reading tea leaves). But the<=> >BR>>=3B end result would be a set of interfaces written in "Pure Modula-3=> >".
>=3B The process of running the header generator would also have ve=> >ry
>=3B few dependencies on anything outside the M3 distribution.
&=> >gt=3B
>=3B Mika
>=3B
>=3B Jay writes:
>=3B >=3B--_6=> >117a048-9185-4c03-badb-ef8f93402268_
>=3B >=3BContent-Type: text/pla=> >in=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Encoding: quo=> >ted-printable
>=3B >=3B
>=3B >=3B
>=3B >=3BThis is wha=> >t you "have to" chose between.
>=3B >=3BHeader cloning or C code (an=> >d C headers).
>=3B >=3B=3D20
>=3B >=3BCONST or VAR (or functi=> >ons?)
>=3B >=3B=3D20
>=3B >=3BI'm going to likely make the Ue=> >rror change tonight.
>=3B >=3BYou can still veto it (er=3D2C vote ag=> >ainst it :) )
>=3B >=3B=3D20
>=3B >=3BPossibly some convulute=> >d C (enum/#undef)=3D2C or splitting the Modula-3
>=3B >=3Bat boundar=> >ies that weren't previously believed "natural".
>=3B >=3B(See how Se=> >tupHandlers is ~two lines in Modula-3 and the rest in C=3D3B
>=3B >=> >=3Bthis is partly out of ignorance. I don't know how to write those
>=> >=3B >=3Btwo lines in C=3D3B and laziness=3D2C I didn't look into how). >>>=3B >=3B=3D20
>=3B >=3B=3D20
>=3B >=3B=3D20
>=3B &=> >gt=3BRemember I'm still staying away from mainstream platforms=3D2C
>=> >=3B >=3Bso the value isn't what it might appear to be=3D2C but it is "sta=> >ge setting"=3D
>=3B >=3B=3D2C
>=3B >=3Band the show might go => >on. :)
>=3B >=3B=3D20
>=3B >=3B=3D20
>=3B >=3BAlso=3D2=> >C the dilemna does get more difficult now=3D2C with the little C header=3D<=> >BR>>=3B >=3B cloning that remains.
>=3B >=3B=3D20
>=3B >=> >=3BFor example=3D2C look at Upthreads.i3.
>=3B >=3BMainly=3D2C look => >at function prototypes.
>=3B >=3BConstants and types are "known prob=> >lems".
>=3B >=3BPrototypes are gray. They actually tend to be portab=> >le.
>=3B >=3B=3D20
>=3B >=3BFor example:
>=3B >=3B=3D2=> >0
>=3B >=3BTYPE pid_t =3D3D INTEGER=3D3B
>=3B >=3B<=3B*EXTE=> >RNAL "m3_getpid*>=3B PROCEDURE getpid():pid_t=3D3B
>=3B >=3B=3D20<=> >BR>>=3B >=3Bor leave it alone?
>=3B >=3Bgetpid is probably the w=> >orst example.
>=3B >=3BIt is so very portable declared in Modula-3.<=> >BR>>=3B >=3BBut still=3D2C imagine pid_t might be 16bits or 32 or 64. >R>>=3B >=3BWriting a wrapper is more portable -- as long as the pid isn=> >'t stuff into s=3D
>=3B >=3Bome record that the system defines.
&=> >gt=3B >=3B=3D20
>=3B >=3B=3D20
>=3B >=3BAgain=3D2C Upthread=> >s.i3.
>=3B >=3BWould you like to see it reduced=3D2C or left alone?<=> >BR>>=3B >=3BOnly deal with the types and initializers=3D2C or also the => >prototypes?
>=3B >=3BYou know=3D2C I could write a little portable l=> >ayer=3D2C where all the types ar=3D
>=3B >=3Be pointers=3D2C always => >null initialized.
>=3B >=3BIt would buy /some/ portability=3D2C and => >cost some.
>=3B >=3B=3D20
>=3B >=3B=3D20
>=3B >=3BDo y=> >ou like the sem_t change? Partly? Not at all?
>=3B >=3BThere is one => >sem_t in the system. So I moved it to be in C code.
>=3B >=3BOr=3D2C=> > as I had it before=3D2C declared as the max size/align of all the platf=3D=> >
>=3B >=3Borms -- getting that right is the same work as getting it => >right "the old wa=3D
>=3B >=3By"=3D2C except if you make a mistake=> >=3D2C odds are still good of it being ok.
>=3B >=3B=3D20
>=3B &=> >gt=3B=3D20
>=3B >=3BShould the line be drawn at generating the remai=> >ning headers=3D2C rather than=3D
>=3B >=3B eliminating them?
>=> >=3B >=3BUerror.i3 is easily generated. Good enough?
>=3B >=3B=3D20=> >
>=3B >=3BUpthread.i3's types can be generated generally as records => >with opaque array=3D
>=3B >=3Bs with the right size and alignment. >R>>=3B >=3B=3D20
>=3B >=3BOther stuff can be generated or at lea=> >st checked.
>=3B >=3Be.g. to check that getpid is declared correctly=> >=3D2C you can assign it to a f=3D
>=3B >=3Bunction pointer and see i=> >f that compiles.
>=3B >=3B=3D20
>=3B >=3BPerf on Uerror argua=> >bly doesn't matter.
>=3B >=3BIs it only error handling code?Or do so=> >ckets often go down "error" paths=3D2C=3D
>=3B >=3B because they are=> > slow and you are waiting for more data?
>=3B >=3B=3D20
>=3B &g=> >t=3BAnyway=3D2C point is=3D2C I agree for sure this is valuable=3D2C but I => >might be h=3D
>=3B >=3Bitting the "tail" of the approach and should => >switch=3D2C I'm not sure. I keep=3D
>=3B >=3B saying that though=3D2=> >C and then press further.
>=3B >=3B=3D20
>=3B >=3B=3D20
&g=> >t=3B >=3B - Jay
>=3B >=3B
>=3B >=3B
>=3B >=3B
>=> >=3B >=3BFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon=3D2=> >C 12 Jan 200=3D
>=3B >=3B9 19:24:50 +1100CC: m3devel at elegosoft.comSu=> >bject: Re: [M3devel] declaring a=3D
>=3B >=3B type's existance but n=> >ot enough to instantiate it?
>=3B >=3B
>=3B >=3B
>=3B &g=> >t=3BPoint taken. We live in a C universe and so need to interact. I do thin=> >k =3D
>=3B >=3Byour work with the headers is useful=3D2C and I want => >it to continue. Especia=3D
>=3B >=3Blly in simplifying ports.
>=> >=3B >=3B
>=3B >=3B
>=3B >=3BOn 12 Jan 2009=3D2C at 19:18=3D=> >2C Jay wrote:
>=3B >=3B
>=3B >=3BI don't think a development => >system without C headers is interesting.. Is it=3D
>=3B >=3B really?=> > The transform I apply at times is wherever there is interaction wi=3D
&=> >gt=3B >=3Bth C code that is described by system-dependent headers=3D2C or=> > perhaps even =3D
>=3B >=3Bfairly system-independent headers outside=> > the Modula-3 tree=3D2C either write=3D
>=3B >=3B wrapper functions => >for the functionality in the headers (e.g. stat=3D2C waitp=3D
>=3B >=> >=3Bid)=3D2C which can be done in a system-independent way=3D2C or move the => >Modula-=3D
>=3B >=3B3<=3B->=3BC transition higher=3D2C which is => >also usually system-independent=3D2C e.g.=3D
>=3B >=3B ThreadPThread=> >C_SetupHandlers. It is either that or clone the headers=3D2C wh=3D
>=> >=3B >=3Bich seems like the worse evil. There is always going to be a Modu=> >la-3<=3B->=3BC t=3D
>=3B >=3Bransition=3D2C it is just a matter => >of where it occurs. - Jay
>=3B >=3B
>=3B >=3BCC: m3devel at eleg=> >osoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.e=3D
>=3B &g=> >t=3BduSubject: Re: [M3devel] declaring a type's existance but not enough to=> > ins=3D
>=3B >=3Btantiate it?Date: Mon=3D2C 12 Jan 2009 12:32:15 +11=> >00
>=3B >=3B
>=3B >=3B
>=3B >=3BJay=3D2C I really thin=> >k you are bending over backwards too far just to be abl=3D
>=3B >=3B=> >e to shoe-horn things into C. I *like* having the transpar of C header fil=> >=3D
>=3B >=3Bes expressed in Modula-3=3D2C *particularly* for system=> > calls=3D2C where you mi=3D
>=3B >=3Bght even be trying to build on => >a system that does not have the C header fil=3D
>=3B >=3Bes installe=> >d=3D2C even though the libraries exist and can be linked to. Fund=3D
>=> >=3B >=3Bamentally=3D2C I think anytime the Modula-3 code is made less tra=> >nsparent you=3D
>=3B >=3B should think hard about what you are doing=> >. The same with the change of c=3D
>=3B >=3Bonstants to variables. >R>>=3B >=3B
>=3B >=3BI am getting very nervous that the changes => >you are making are destroying th=3D
>=3B >=3Be clarity of the Modula=> >-3 run-time code.
>=3B >=3B
>=3B >=3BIn this particular case=> >=3D2C you are wanting to use a Modula-3 parameter pass=3D
>=3B >=3Bi=> >ng mechanism on something that is not declared in Modula-3. Seems kind of=> >=3D
>=3B >=3B dubious to me. Also=3D2C I really don't like the idea => >of accessing external=3D
>=3B >=3B variables in C.
>=3B >=3B<=> >BR>>=3B >=3B-- Tony
>=3B >=3B
>=3B >=3BOn 12 Jan 2009=3D2=> >C at 11:55=3D2C Jay wrote:
>=3B >=3B
>=3B >=3BI considered AD=> >DRESS.However I think it still doesn't satisfy. I want to be=3D
>=3B &=> >gt=3B able to do this: TYPE Foo_t =3D3D something=3D3B<=3B* EXTERNAL *>=> >=3B VAR Foo1=3D2C Foo=3D
>=3B >=3B2:Foo_t=3D3B<=3B* EXTERNAL *>=> >=3B PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t)=3D
>=3B >=3B=> >=3D3B (* Modula-3=3D2C not external *)PROCEDURE x()=3D3DBEGIN UseFoo(Foo1)=> >=3D3B U=3D
>=3B >=3BseFoo(Foo2)=3D3BEND x=3D3B AND I want any use of=> >:VAR Foo3:Foo3_t=3D3B (* Modula-3=3D
>=3B >=3B=3D2C not external *)t=> >o error. This is sem_t and sigset_t in particular. Poss=3D
>=3B >=3B=> >ibly renaming is the thing.They used to be declared in Modula-3=3D2C system=> >-d=3D
>=3B >=3Bependently=3D2C butI moved them to portable C. I coul=> >d remove the types entir=3D
>=3B >=3Bely and change UseFoo to take a=> >n address=3D2Cand declare mask and ackSem to b=3D
>=3B >=3Be integer=> >s or I guess.<=3B*EXTERNAL>=3B VAR ackSem : RECORD END=3D3B That would => >sat=3D
>=3B >=3Bisfy but I thought it might be nicer to still provid=> >e the namedtypes to ref=3D
>=3B >=3Ber to the external variables. - => >Jay
>=3B >=3B
>=3B >=3BFrom: hosking at cs.purdue.eduTo: jay.kre=> >ll at cornell.eduDate: Mon=3D2C 12 Jan 200=3D
>=3B >=3B9 11:13:00 +1100=> >CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a=3D
>=3B &g=> >t=3B type's existance but not enough to instantiate it?What's wrong with us=> >ing =3D
>=3B >=3BADDRESS for references to opaque values? If sigset_=> >t is never instantiated=3D
>=3B >=3B in Modula-3=3D2C then why do yo=> >u need it declared there?
>=3B >=3B
>=3B >=3B
>=3B >=> >=3B
>=3B >=3BAntony Hosking | Associate Professor | Computer Science=> > | Purdue University
>=3B >=3B305 N. University Street | West Lafaye=> >tte | IN 47907 | USA
>=3B >=3BOffice +1 765 494 6001 | Mobile +1 765=> > 427 5484
>=3B >=3B
>=3B >=3B
>=3B >=3BOn 12 Jan 2009=> >=3D2C at 01:44=3D2C Jay wrote:
>=3B >=3B
>=3B >=3BIs there a => >way in Modula-3 to declare that a type exists=3D2C and there are <=3B=3D<=> >BR>>=3B >=3B*external*>=3B instances of it=3D2C without "fully" decla=> >ring it=3D2C so that no M=3D
>=3B >=3Bodula-3 can instantiate it? I => >have done this for sigset_t and sem_t=3D2C but =3D
>=3B >=3Bthey cou=> >ld erroneously be instantiated by Modula-3 and I'd like to remove t=3D
&=> >gt=3B >=3Bhat ability to mess up so easily. (* This type is not declared => >correctly. I=3D
>=3B >=3Bt is only instantiated in C code. *) sigset=> >_t =3D3D RECORD END=3D3B(* This typ=3D
>=3B >=3Be is not declared co=> >rrectly. It is only instantiated in C code. *) sem_t =3D
>=3B >=3B=> >=3D3D RECORD END=3D3BIn C I believe you can do this=3D2C like: typedef stru=> >ct fo=3D
>=3B >=3Bo foo_t=3D3B extern foo_t foo=3D3B void UseFoo(foo=> >_t*)=3D3B foo_t* GetFoo=3D
>=3B >=3B(void)=3D3B Thanks=3D2C - Jay=3D=> >
>=3B >=3B
>=3B >=3B--_6117a048-9185-4c03-badb-ef8f93402268_<=> >BR>>=3B >=3BContent-Type: text/html=3B charset=3D"iso-8859-1"
>=3B=> > >=3BContent-Transfer-Encoding: quoted-printable
>=3B >=3B
>=> >=3B >=3B<=3Bhtml>=3B
>=3B >=3B<=3Bhead>=3B
>=3B >=> >=3B<=3Bstyle>=3B
>=3B >=3B.hmmessage P
>=3B >=3B{
>=> >=3B >=3Bmargin:0px=3D3B
>=3B >=3Bpadding:0px
>=3B >=3B}
=> >>=3B >=3Bbody.hmmessage
>=3B >=3B{
>=3B >=3Bfont-size: 10=> >pt=3D3B
>=3B >=3Bfont-family:Verdana
>=3B >=3B}
>=3B >=> >=3B<=3B/style>=3B
>=3B >=3B<=3B/head>=3B
>=3B >=3B<=> >=3Bbody class=3D3D'hmmessage'>=3B
>=3B >=3BThis is what you "have => >to" chose between.<=3BBR>=3B
>=3B >=3BHeader cloning or C code (=> >and C headers).<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=> >=3B
>=3B >=3BCONST or VAR (or functions?)<=3BBR>=3B
>=3B &g=> >t=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BI'm going to likely make=> > the Uerror change tonight.<=3BBR>=3B
>=3B >=3BYou can still vet=> >o it (er=3D2C vote against it :) )<=3BBR>=3B
>=3B >=3B&=3Bnbs=> >p=3D3B<=3BBR>=3B
>=3B >=3BPossibly some convuluted C (enum/#unde=> >f)=3D2C or splitting the Modula-3<=3BBR>=3B
>=3B >=3Bat boundari=> >es that weren't previously believed "natural".<=3BBR>=3B
>=3B >=> >=3B(See how SetupHandlers is ~two lines in Modula-3 and the rest in C=3D3B&=> >lt=3BBR>=3B
>=3B >=3Bthis is partly out of ignorance. I don't know=> > how to write those<=3BBR>=3B
>=3B >=3Btwo lines in C=3D3B and l=> >aziness=3D2C I didn't look into how).<=3BBR>=3B
>=3B >=3B&=3B=> >nbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
&=> >gt=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BRemember I'm sti=> >ll staying away from mainstream platforms=3D2C<=3BBR>=3B
>=3B >=> >=3Bso the value isn't what it might appear to be=3D2C but it is "stage sett=> >ing"=3D
>=3B >=3B=3D2C<=3BBR>=3B
>=3B >=3Band the show mi=> >ght go on. :)<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B<=> >BR>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BAlso=3D2C th=> >e dilemna does get more difficult now=3D2C with the little C header=3D
&=> >gt=3B >=3B cloning that remains.<=3BBR>=3B
>=3B >=3B&=3Bnbs=> >p=3D3B<=3BBR>=3B
>=3B >=3BFor example=3D2C look at Upthreads.i3.=> ><=3BBR>=3B
>=3B >=3BMainly=3D2C look at function prototypes.<=> >=3BBR>=3B
>=3B >=3BConstants and types are "known problems".<=3B=> >BR>=3B
>=3B >=3BPrototypes are gray. They actually tend to be port=> >able.<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=> >=3B >=3BFor example:<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3B=> >BR>=3B
>=3B >=3BTYPE pid_t =3D3D INTEGER=3D3B<=3BBR>=3B
>=> >=3B >=3B&=3Blt=3D3B*EXTERNAL "m3_getpid*&=3Bgt=3D3B PROCEDURE getpi=> >d():pid_t=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B=> >
>=3B >=3Bor leave it alone?<=3BBR>=3B
>=3B >=3Bgetpid is=> > probably the worst example.<=3BBR>=3B
>=3B >=3BIt is so very po=> >rtable declared in Modula-3.<=3BBR>=3B
>=3B >=3BBut still=3D2C i=> >magine pid_t might be 16bits or 32 or 64.<=3BBR>=3B
>=3B >=3BWri=> >ting a wrapper is more portable -- as long as the pid isn't stuff into s=3D=> >
>=3B >=3Bome record that the system defines.<=3BBR>=3B
>=> >=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B&l=> >t=3BBR>=3B
>=3B >=3BAgain=3D2C Upthreads.i3.<=3BBR>=3B
>=> >=3B >=3BWould you like to see it reduced=3D2C or left alone?<=3BBR>=> >=3B
>=3B >=3BOnly deal with the types and initializers=3D2C or also => >the prototypes?<=3BBR>=3B
>=3B >=3BYou know=3D2C I could write a=> > little portable layer=3D2C where all the types ar=3D
>=3B >=3Be poi=> >nters=3D2C always null initialized.<=3BBR>=3B
>=3B >=3BIt would => >buy /some/ portability=3D2C and cost some.<=3BBR>=3B
>=3B >=3B&a=> >mp=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B=> >
>=3B >=3BDo you like the sem_t change? Partly? Not at all?<=3BBR&=> >gt=3B
>=3B >=3BThere is one sem_t in the system. So I moved it to be=> > in C code.<=3BBR>=3B
>=3B >=3BOr=3D2C as I had it before=3D2C d=> >eclared as the max size/align of all the platf=3D
>=3B >=3Borms -- g=> >etting that right is the same work as getting it right "the old wa=3D
&g=> >t=3B >=3By"=3D2C except if you make a mistake=3D2C odds are still good of=> > it being ok.<=3BB=3D
>=3B >=3BR>=3B
>=3B >=3B&=3Bnbsp=> >=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=> >=3B >=3BShould the line be drawn at generating the remaining headers=3D2C=> > rather than=3D
>=3B >=3B eliminating them?<=3BBR>=3B
>=3B => >>=3BUerror.i3 is easily generated. Good enough?<=3BBR>=3B
>=3B &=> >gt=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BUpthread.i3's types can=> > be generated generally as records with opaque array=3D
>=3B >=3Bs w=> >ith the right size and alignment.<=3BBR>=3B
>=3B >=3B&=3Bnbsp=> >=3D3B<=3BBR>=3B
>=3B >=3BOther stuff can be generated or at leas=> >t checked.<=3BBR>=3B
>=3B >=3Be.g. to check that getpid is decla=> >red correctly=3D2C you can assign it to a f=3D
>=3B >=3Bunction poin=> >ter and see if that compiles.<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3=> >B<=3BBR>=3B
>=3B >=3BPerf on Uerror arguably doesn't matter.<=> >=3BBR>=3B
>=3B >=3BIs it only error handling code?<=3BBR>=3BOr=> > do sockets often go down "error" path=3D
>=3B >=3Bs=3D2C because th=> >ey are slow and you are waiting for more data?<=3BBR>=3B
>=3B >=> >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BAnyway=3D2C point is=3D2C=> > I agree for sure this is valuable=3D2C but I might be h=3D
>=3B >=> >=3Bitting the "tail" of the approach and should switch=3D2C I'm not sure. I=> > keep=3D
>=3B >=3B saying that though=3D2C and then press further.&l=> >t=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=> >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B- Jay<=> >=3BBR>=3B<=3BBR>=3B
>=3B >=3B
>=3B >=3B<=3BHR id=3D3D=> >stopSpelling>=3B
>=3B <=3BBR>=3B
>=3B >=3BFrom: hosking at c=> >s.purdue.edu<=3BBR>=3BTo: jay.krell at cornell.edu<=3BBR>=3BDate: Mon=> >=3D2C 12=3D
>=3B >=3B Jan 2009 19:24:50 +1100<=3BBR>=3BCC: m3dev=> >el at elegosoft.com<=3BBR>=3BSubject: Re: [M3de=3D
>=3B >=3Bvel] de=> >claring a type's existance but not enough to instantiate it?<=3BBR>=3B&=> >lt=3BBR>=3B=3D
>=3B >=3B<=3BBR>=3B
>=3B >=3B<=3BDIV&g=> >t=3B<=3BSPAN class=3D3DEC_Apple-style-span style=3D3D"WORD-SPACING: 0px=> >=3D3B FONT: =3D
>=3B >=3B12px Helvetica=3D3B TEXT-TRANSFORM: none=3D=> >3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-IND=3D
>=3B >=3BENT: 0px=3D3B=> > WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPS=3D
=> >>=3B >=3BE: separate">=3B
>=3B >=3B<=3BDIV style=3D3D"WORD-W=> RAP: break-word">=3B<=3BSPAN class=3D3DEC_Apple-style-span styl=3D
&=> >gt=3B >=3Be=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TR=> >ANSFORM: none=3D3B C=3D
>=3B >=3BOLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-=> >INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-S=3D
>=3B >=3BPACIN=> >G: normal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=3D3DEC_Appl=> >e-style-s=3D
>=3B >=3Bpan style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12=> >px Helvetica=3D3B TEXT-TRANSFORM: n=3D
>=3B >=3Bone=3D3B COLOR: rgb(=> >0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B =3D
&=> >gt=3B >=3BLETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate">=3B<=> >=3BSPAN class=3D3DEC_Apple=3D
>=3B >=3B-style-span style=3D3D"WORD-S=> >PACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRAN=3D
>=3B >=3BSFO=> >RM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SP=> >ACE: no=3D
>=3B >=3Brmal=3D3B LETTER-SPACING: normal=3D3B BORDER-COL=> >LAPSE: separate">=3B<=3BSPAN class=3D3D=3D
>=3B >=3BEC_Apple-sty=> >le-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B T=3D >>>=3B >=3BEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-=> >INDENT: 0px=3D3B WHITE-S=3D
>=3B >=3BPACE: normal=3D3B LETTER-SPACIN=> >G: normal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN =3D
>=3B >=> >=3Bclass=3D3DEC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12=> >px Helvet=3D
>=3B >=3Bica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(=> >0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B=3D
>=3B >=3B WHITE-SPACE: => >normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate=3D
>=> >=3B >=3B">=3B<=3BSPAN class=3D3DEC_Apple-style-span style=3D3D"WORD-S=> >PACING: 0px=3D3B FONT: 12p=3D
>=3B >=3Bx Helvetica=3D3B TEXT-TRANSFO=> >RM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT=3D
>=3B >=> >=3B: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-C=> >OLLAPSE: =3D
>=3B >=3Bseparate">=3B<=3BSPAN class=3D3DEC_Apple-s=> >tyle-span style=3D3D"WORD-SPACING: 0px=3D3B F=3D
>=3B >=3BONT: 12px => >Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEX=> >=3D
>=3B >=3BT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPAC=> >ING: normal=3D3B BORDER-CO=3D
>=3B >=3BLLAPSE: separate">=3B<=3B=> >SPAN class=3D3DEC_Apple-style-span style=3D3D"WORD-SPACING: =3D
>=3B &=> >gt=3B0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rg=> >b(0=3D2C0=3D2C0=3D
>=3B >=3B)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE=> >: normal=3D3B LETTER-SPACING: normal=3D3B B=3D
>=3B >=3BORDER-COLLAP=> >SE: separate">=3B
>=3B >=3B<=3BDIV>=3BPoint taken. &=3Bnbsp=> >=3D3BWe live in a C universe and so need to interact. =3D
>=3B >=3B&=> >amp=3Bnbsp=3D3BI do think your work with the headers is useful=3D2C and I w=> >ant it to=3D
>=3B >=3B continue. &=3Bnbsp=3D3BEspecially in simpl=> >ifying ports.<=3B/DIV>=3B
>=3B >=3B<=3BDIV>=3B<=3BBR>=3B=> ><=3B/DIV>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/S=> >PAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=> >=3B<=3B/DI=3D
>=3B >=3BV>=3B<=3B/SPAN>=3B<=3B/DIV>=3B >>>=3B >=3B<=3BDIV>=3B
>=3B >=3B<=3BDIV>=3BOn 12 Jan 2009=> >=3D2C at 19:18=3D2C Jay wrote:<=3B/DIV>=3B<=3BBR class=3D3DEC_Apple-i=> >nt=3D
>=3B >=3Berchange-newline>=3B
>=3B >=3B<=3BBLOCKQUO=> >TE>=3B<=3BSPAN class=3D3DEC_Apple-style-span style=3D3D"WORD-SPACING: 0=> >px=3D3B=3D
>=3B >=3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=> >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B T=3D
>=3B >=3BEXT-INDENT: 0px=> >=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-=3D
&g=> >t=3B >=3BCOLLAPSE: separate">=3B
>=3B >=3B<=3BDIV class=3D3DEC=> >_hmmessage style=3D3D"FONT-SIZE: 10pt=3D3B FONT-FAMILY: Verdana"=3D
>=> >=3B >=3B>=3BI don't think a development system without C headers is int=> >eresting.. Is i=3D
>=3B >=3Bt really?<=3BBR>=3B&=3Bnbsp=3D3B&=> >lt=3BBR>=3BThe transform I apply at times is wherever there i=3D
>=> >=3B >=3Bs interaction with C code that is described by system-dependent h=> >eaders=3D2C =3D
>=3B >=3Bor perhaps even fairly system-independent h=> >eaders outside the Modula-3 tree=3D
>=3B >=3B=3D2C either write wrap=> >per functions for the functionality in the headers (e.=3D
>=3B >=3Bg=> >. stat=3D2C waitpid)=3D2C which&=3Bnbsp=3D3Bcan be done in a system-inde=> >pendent way=3D
>=3B >=3B=3D2C&=3Bnbsp=3D3Bor move the Modula-3&am=> >p=3Blt=3D3B-&=3Bgt=3D3BC transition higher=3D2C which is=3D
>=3B &g=> >t=3B also usually system-independent=3D2C e.g. ThreadPThreadC_SetupHandlers=> >.<=3BBR>=3B&=3B=3D
>=3B >=3Bnbsp=3D3B<=3BBR>=3BIt is eith=> >er that or clone the headers=3D2C which seems like the w=3D
>=3B >=> >=3Borse evil.<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3BThere is always go=> >ing to be a Modula-3&=3Blt=3D3B-&=3Bgt=3D
>=3B >=3B=3D3BC tran=> >sition=3D2C it is just a matter of where it occurs.<=3BBR>=3B&=3Bnbs=> >p=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bnbsp=3D3B- Jay<=3BBR>=3B=> ><=3BBR>=3B
>=3B >=3B<=3BHR id=3D3DEC_stopSpelling>=3B
>=> >=3B >=3B<=3BBR>=3BCC:<=3BSPAN class=3D3DEC_Apple-converted-space>=> >=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BA href=3D3D"mai=3D
>=3B >=> >=3Blto:m3devel at elegosoft.com">=3Bm3devel at elegosoft.com<=3B/A>=3B<=> >=3BBR>=3BFrom:<=3BSPAN class=3D3D=3D
>=3B >=3BEC_Apple-converted=> >-space>=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BA href=3D3D"mailto:hoski=> >ng at cs.purdue=3D
>=3B >=3B.edu">=3Bhosking at cs.purdue.edu<=3B/A>=> >=3B<=3BBR>=3BTo:<=3BSPAN class=3D3DEC_Apple-converted-spac=3D
>=> >=3B >=3Be>=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BA href=3D3D"mailto:=> >jay.krell at cornell.edu">=3Bjay.krell at cornell=3D
>=3B >=3B.edu<=3B=> >/A>=3B<=3BBR>=3BSubject: Re: [M3devel] declaring a type's existance b=> >ut not eno=3D
>=3B >=3Bugh to instantiate it?<=3BBR>=3BDate: Mon=> >=3D2C 12 Jan 2009 12:32:15 +1100<=3BBR>=3B<=3BBR>=3B<=3BB=3D
&=> >gt=3B >=3BR>=3B
>=3B <=3BDIV>=3B<=3BSPAN class=3D3DEC_EC_App=> >le-style-span style=3D3D"WORD-SPACING: 0px=3D3B FON=3D
>=3B >=3BT: 1=> >2px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B=> > TEXT-=3D
>=3B >=3BINDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-=> >SPACING: normal=3D3B BORDER-COLL=3D
>=3B >=3BAPSE: separate">=3B >R>>=3B >=3B<=3BDIV style=3D3D"WORD-WRAP: break-word">=3B<=3BSPAN => >class=3D3DEC_EC_Apple-style-span s=3D
>=3B >=3Btyle=3D3D"WORD-SPACIN=> >G: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D
>=3B >=> >=3B=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: => >normal=3D3B LET=3D
>=3B >=3BTER-SPACING: normal=3D3B BORDER-COLLAPSE=> >: separate">=3B<=3BSPAN class=3D3DEC_EC_Apple=3D
>=3B >=3B-style=> >-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRAN=> >=3D
>=3B >=3BSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-IN=> >DENT: 0px=3D3B WHITE-SPACE: no=3D
>=3B >=3Brmal=3D3B LETTER-SPACING:=> > normal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=3D3D=3D
&g=> >t=3B >=3BEC_EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 1=> >2px Helvetica=3D
>=3B >=3B=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb=> >(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WH=3D
>=3B >=3BITE-SPACE:=> > normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate">=3B&l=> >t=3B=3D
>=3B >=3BSPAN class=3D3DEC_EC_Apple-style-span style=3D3D"WO=> >RD-SPACING: 0px=3D3B FONT: 12p=3D
>=3B >=3Bx Helvetica=3D3B TEXT-TRA=> >NSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT=3D
>=3B &=> >gt=3B: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER=> >-COLLAPSE: =3D
>=3B >=3Bseparate">=3B<=3BSPAN class=3D3DEC_EC_Ap=> >ple-style-span style=3D3D"WORD-SPACING: 0px=3D
>=3B >=3B=3D3B FONT: => >12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D<=> >BR>>=3B >=3B=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER=> >-SPACING: normal=3D3B BO=3D
>=3B >=3BRDER-COLLAPSE: separate">=3B&=> >lt=3BSPAN class=3D3DEC_EC_Apple-style-span style=3D3D"WORD=3D
>=3B >=> >=3B-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B C=> >OLOR: rgb=3D
>=3B >=3B(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHI=> >TE-SPACE: normal=3D3B LETTER-SPACING: n=3D
>=3B >=3Bormal=3D3B BORDE=> >R-COLLAPSE: separate">=3B<=3BSPAN class=3D3DEC_EC_Apple-style-span st=> >=3D
>=3B >=3Byle=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D=> >3B TEXT-TRANSFORM: none=3D3B=3D
>=3B >=3B COLOR: rgb(0=3D2C0=3D2C0)=> >=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER=3D
>=3B &g=> >t=3B-SPACING: normal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=> >=3D3DEC_EC_Apple-st=3D
>=3B >=3Byle-span style=3D3D"WORD-SPACING: 0p=> >x=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFO=3D
>=3B >=3BRM: none=> >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: nor=> >ma=3D
>=3B >=3Bl=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: s=> >eparate">=3B
>=3B >=3B<=3BDIV>=3BJay=3D2C I really think you a=> >re bending over backwards too far just to b=3D
>=3B >=3Be able to sh=> >oe-horn things into C. &=3Bnbsp=3D3BI *like* having the transpar of =3D<=> >BR>>=3B >=3BC header files expressed in Modula-3=3D2C *particularly* fo=> >r system calls=3D2C =3D
>=3B >=3Bwhere you might even be trying to b=> >uild on a system that does not have the =3D
>=3B >=3BC header files => >installed=3D2C even though the libraries exist and can be link=3D
>=3B=> > >=3Bed to. &=3Bnbsp=3D3BFundamentally=3D2C I think anytime the Modula=> >-3 code is made l=3D
>=3B >=3Bess transparent you should think hard => >about what you are doing. &=3Bnbsp=3D3BThe=3D
>=3B >=3B same with=> > the change of constants to variables.<=3B/DIV>=3B
>=3B >=3B<=> >=3BDIV>=3B<=3BBR>=3B<=3B/DIV>=3B
>=3B >=3B<=3BDIV>=3BI=> > am getting very nervous that the changes you are making are destroyi=3D >>>=3B >=3Bng the clarity of the Modula-3 run-time code.<=3B/DIV>=3B=> >
>=3B >=3B<=3BDIV>=3B<=3BBR>=3B<=3B/DIV>=3B
>=3B &g=> >t=3B<=3BDIV>=3BIn this particular case=3D2C you are wanting to use a Mo=> >dula-3 parameter=3D
>=3B >=3B passing mechanism on something that is=> > not declared in Modula-3. &=3Bnbsp=3D3BS=3D
>=3B >=3Beems kind o=> >f dubious to me. &=3Bnbsp=3D3BAlso=3D2C I really don't like the idea of=> >=3D
>=3B >=3B accessing external variables in C.<=3B/DIV>=3B
=> >>=3B >=3B<=3BDIV>=3B<=3BBR>=3B<=3B/DIV>=3B
>=3B >=3B=> ><=3BDIV>=3B-- Tony<=3B/DIV>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=> >=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPA=> >N>=3B<=3B/SPAN>=3B<=3B=3D
>=3B >=3B/DIV>=3B<=3B/SPAN>=> >=3B<=3B/DIV>=3B<=3BBR>=3B
>=3B >=3B<=3BDIV>=3B
>=3B=> > >=3B<=3BDIV>=3BOn 12 Jan 2009=3D2C at 11:55=3D2C Jay wrote:<=3B/DI=> >V>=3B<=3BBR class=3D3DEC_EC_Apple-=3D
>=3B >=3Binterchange-newli=> >ne>=3B
>=3B >=3B<=3BBLOCKQUOTE>=3B<=3BSPAN class=3D3DEC_EC_A=> >pple-style-span style=3D3D"WORD-SPACING: 0px=3D
>=3B >=3B=3D3B FONT:=> > 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D=> >
>=3B >=3B=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTE=> >R-SPACING: normal=3D3B BO=3D
>=3B >=3BRDER-COLLAPSE: separate">=3B=> >
>=3B >=3B<=3BDIV class=3D3DEC_EC_hmmessage style=3D3D"FONT-SIZE: => >10pt=3D3B FONT-FAMILY: Verda=3D
>=3B >=3Bna">=3BI considered ADDRE=> >SS.<=3BBR>=3BHowever I think it still doesn't satisfy.<=3BBR>=3B&am=> >p=3B=3D
>=3B >=3Bnbsp=3D3B<=3BBR>=3BI want to be able to do this=> >:<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3BTYPE&=3Bnbsp=3D3BFoo_t =3D<=> >BR>>=3B >=3B=3D3D something=3D3B<=3BBR>=3B&=3Blt=3D3B* EXTERNAL => >*&=3Bgt=3D3B VAR Foo1=3D2C Foo2:Foo_t=3D3B<=3BBR>=3B&=3B=3D
&g=> >t=3B >=3Blt=3D3B* EXTERNAL *&=3Bgt=3D3B PROCEDURE&=3Bnbsp=3D3BUseFo=> >o(READONLY (* or VAR *) foo:F=3D
>=3B >=3Boo_t)=3D3B<=3BBR>=3B&a=> >mp=3Bnbsp=3D3B<=3BBR>=3B(* Modula-3=3D2C not external *)<=3BBR>=3BP=> >ROCEDURE x()=3D3D<=3B=3D
>=3B >=3BBR>=3BBEGIN<=3BBR>=3B&=> >=3Bnbsp=3D3B UseFoo(Foo1)=3D3B<=3BBR>=3B&=3Bnbsp=3D3B UseFoo(Foo2)=> >=3D3B<=3BBR>=3BEND x=3D
>=3B >=3B=3D3B<=3BBR>=3B&=3Bnbsp=> >=3D3B<=3BBR>=3BAND I want any use of:<=3BBR>=3BVAR Foo3:Foo3_t=3D3B=> > (* Modula-3=3D
>=3B >=3B=3D2C not external *)<=3BBR>=3B<=3BBR=> >>=3Bto error. This is sem_t and sigset_t in particul=3D
>=3B >=3Ba=> >r.<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3BPossibly renaming is the thin=> >g.<=3BBR>=3BThey used to be decla=3D
>=3B >=3Bred in Modula-3=3D=> >2C system-dependently=3D2C but<=3BBR>=3BI moved them to portable C.=3D<=> >BR>>=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3BI could remove => >the types entirely and change UseFoo to take=3D
>=3B >=3B an address=> >=3D2C<=3BBR>=3Band declare mask and ackSem to be integers or I guess.&l=> >t=3BBR=3D
>=3B >=3B>=3B&=3Blt=3D3B*EXTERNAL&=3Bgt=3D3B VAR a=> >ckSem&=3Bnbsp=3D3B: RECORD END=3D3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BB=> >R>=3BTha=3D
>=3B >=3Bt would satisfy but I thought it might be nic=> >er to still provide the named<=3B=3D
>=3B >=3BBR>=3Btypes to ref=> >er to the external variables.<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B&a=> >mp=3Bnbsp=3D3B- Jay<=3BB=3D
>=3B >=3BR>=3B<=3BBR>=3B
>=> >=3B >=3B<=3BHR id=3D3DEC_EC_stopSpelling>=3B
>=3B >=3B<=3BBR=> >>=3BFrom:<=3BSPAN class=3D3DEC_EC_Apple-converted-space>=3B&=3Bnbs=> >p=3D3B<=3B/SPAN>=3B<=3BA href=3D
>=3B >=3B=3D3D"mailto:hosking=> >@cs.purdue.edu">=3Bhosking at cs.purdue.edu<=3B/A>=3B<=3BBR>=3BTo:&l=> >t=3BSPAN cla=3D
>=3B >=3Bss=3D3DEC_EC_Apple-converted-space>=3B&am=> >p=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BA href=3D3D"mailto:jay.krell=3D
>=> >=3B >=3B at cornell.edu">=3Bjay.krell at cornell.edu<=3B/A>=3B<=3BBR>=> >=3BDate: Mon=3D2C 12 Jan 2009 11:13:0=3D
>=3B >=3B0 +1100<=3BBR>=> >=3BCC:<=3BSPAN class=3D3DEC_EC_Apple-converted-space>=3B&=3Bnbsp=3D3=> >B<=3B/SPAN>=3B<=3BA h=3D
>=3B >=3Bref=3D3D"mailto:m3devel at eleg=> >osoft.com">=3Bm3devel at elegosoft.com<=3B/A>=3B<=3BBR>=3BSubject: => >=3D
>=3B >=3BRe: [M3devel] declaring a type's existance but not enou=> >gh to instantiate it=3D
>=3B >=3B?<=3BBR>=3B<=3BBR>=3BWhat's=> > wrong with using ADDRESS for references to opaque values? &=3B=3D
&g=> >t=3B >=3Bnbsp=3D3BIf sigset_t is never instantiated in Modula-3=3D2C then=> > why do you nee=3D
>=3B >=3Bd it declared there?<=3BBR>=3B
&g=> >t=3B >=3B<=3BDIV>=3B<=3BBR>=3B
>=3B >=3B<=3BDIV>=3B<=> >=3BSPAN class=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D=> >3B =3D
>=3B >=3BFONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B => >COLOR: rgb(0=3D2C0=3D2C0)=3D3B TE=3D
>=3B >=3BXT-INDENT: 0px=3D3B WH=> >ITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-C=3D
>=3B &g=> >t=3BOLLAPSE: separate">=3B
>=3B >=3B<=3BDIV style=3D3D"WORD-WRAP=> >: break-word">=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-spa=3D
>=> >=3B >=3Bn style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEX=> >T-TRANSFORM: non=3D
>=3B >=3Be=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B T=> >EXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LE=3D
>=3B >=3BTTER-SP=> >ACING: normal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=3D3DEC_=> >EC_EC_A=3D
>=3B >=3Bpple-style-span style=3D3D"WORD-SPACING: 0px=3D3=> >B FONT: 12px Helvetica=3D3B TEXT-=3D
>=3B >=3BTRANSFORM: none=3D3B C=> >OLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE=3D
>=> >=3B >=3B: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separa=> >te">=3B<=3BSPAN clas=3D
>=3B >=3Bs=3D3DEC_EC_EC_Apple-style-span=> > style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helv=3D
>=3B >=3Betica=> >=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT:=> > 0px=3D
>=3B >=3B=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: norm=> >al=3D3B BORDER-COLLAPSE: separ=3D
>=3B >=3Bate">=3B<=3BSPAN clas=> >s=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B =3D
&g=> >t=3B >=3BFONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=> >=3D2C0=3D2C0)=3D3B TE=3D
>=3B >=3BXT-INDENT: 0px=3D3B WHITE-SPACE: n=> >ormal=3D3B LETTER-SPACING: normal=3D3B BORDER-C=3D
>=3B >=3BOLLAPSE:=> > separate">=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-span style=3D3D"W=> >ORD-SP=3D
>=3B >=3BACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TR=> >ANSFORM: none=3D3B COLOR: rgb(0=3D
>=3B >=3B=3D2C0=3D2C0)=3D3B TEXT-=> >INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: nor=3D
>=3B => >>=3Bmal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=3D3DEC_EC_E=> >C_Apple-style-span s=3D
>=3B >=3Btyle=3D3D"WORD-SPACING: 0px=3D3B FO=> >NT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D
>=3B >=3B=3D3B COLOR=> >: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LE=> >T=3D
>=3B >=3BTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate">=> >=3B<=3BSPAN class=3D3DEC_EC_EC_Ap=3D
>=3B >=3Bple-style-span style=> >=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-T=3D
>=3B => >>=3BRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=> >=3D3B WHITE-SPACE:=3D
>=3B >=3B normal=3D3B LETTER-SPACING: normal=> >=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=3D
>=3B >=3B=> >=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px=> > Helve=3D
>=3B >=3Btica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=> >=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D
>=3B >=3B=3D3B WHITE-SPACE: n=> >ormal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separ=3D
>=3B => >>=3Bate">=3B
>=3B >=3B<=3BDIV>=3B<=3BFONT class=3D3DEC_EC_=> >EC_Apple-style-span color=3D3D#0000ff>=3B<=3BFONT class=3D3D=3D
>=> >=3B >=3BEC_EC_EC_Apple-style-span face=3D3D"Gill Sans">=3B<=3BSPAN cl=> >ass=3D3DEC_EC_EC_Apple-s=3D
>=3B >=3Btyle-span style=3D3D"COLOR: rgb=> >(0=3D2C0=3D2C255)=3D3B FONT-FAMILY: 'Gill Sans'">=3B<=3BSP=3D
>=3B=> > >=3BAN class=3D3DEC_EC_EC_Apple-style-span style=3D3D"COLOR: rgb(0=3D2C0=> >=3D2C255)=3D3B FO=3D
>=3B >=3BNT-FAMILY: 'Gill Sans'">=3BAntony Ho=> >sking<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/FONT>=3B<=3B/FONT>=3B&l=> >t=3BFONT cla=3D
>=3B >=3Bss=3D3DEC_EC_EC_Apple-style-span face=3D3D"=> >Gill Sans">=3B<=3BSPAN class=3D3DEC_EC_EC_Ap=3D
>=3B >=3Bple-sty=> >le-span style=3D3D"FONT-FAMILY: 'Gill Sans'">=3B<=3BSPAN class=3D3DEC_E=> >C_EC_Ap=3D
>=3B >=3Bple-style-span style=3D3D"FONT-FAMILY: 'Gill San=> >s'">=3B<=3BSPAN class=3D3DEC_EC_Apple=3D
>=3B >=3B-converted-spa=> >ce>=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B|<=3BSPAN class=3D3DEC_EC_Apple-=> >converted-space>=3B=3D
>=3B >=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B&=> >lt=3B/SPAN>=3B<=3B/SPAN>=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-=> >span style=3D
>=3B >=3B=3D3D"FONT-FAMILY: 'Gill Sans'">=3B<=3BSP=> >AN class=3D3DEC_EC_EC_Apple-style-span style=3D
>=3B >=3B=3D3D"FONT-=> >FAMILY: 'Gill Sans'">=3BAssociate Professor<=3B/SPAN>=3B<=3B/SPAN&g=> >t=3B<=3BSPAN class=3D
>=3B >=3B=3D3DEC_EC_EC_Apple-style-span styl=> >e=3D3D"FONT-FAMILY: 'Gill Sans'">=3B<=3BSPAN class=3D
>=3B >=3B=> >=3D3DEC_EC_EC_Apple-style-span style=3D3D"FONT-FAMILY: 'Gill Sans'">=3B&a=> >mp=3Bnbsp=3D3B| C=3D
>=3B >=3Bomputer Science | Purdue University<=> >=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/FONT>=3B<=3B/DIV>=3B
>=3B => >>=3B<=3BDIV>=3B<=3BFONT class=3D3DEC_EC_EC_Apple-style-span face=3D=> >3DGillSans-Light>=3B<=3BSPAN cl=3D
>=3B >=3Bass=3D3DEC_EC_EC_App=> >le-style-span style=3D3D"FONT-FAMILY: GillSans-Light">=3B305 N=3D
>=> >=3B >=3B. University Street | West Lafayette | IN 47907 | USA<=3B/SPAN&=> >gt=3B<=3B/FONT>=3B<=3B/DIV>=3B
>=3B >=3B<=3BDIV>=3B<=> >=3BFONT class=3D3DEC_EC_EC_Apple-style-span face=3D3D"Gill Sans" color=3D3D=> >#00=3D
>=3B >=3B00ff>=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-=> >span style=3D3D"COLOR: rgb(0=3D2C0=3D2C25=3D
>=3B >=3B5)=3D3B FONT-F=> >AMILY: 'Gill Sans'">=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-span sty=> >=3D
>=3B >=3Ble=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=3D3B FONT-FAMILY: '=> >Gill Sans'">=3BOffice<=3B/SPAN>=3B<=3B/S=3D
>=3B >=3BPAN>=> >=3B<=3B/FONT>=3B<=3BFONT class=3D3DEC_EC_EC_Apple-style-span face=3D3=> >DGillSans-Light>=3B<=3BS=3D
>=3B >=3BPAN class=3D3DEC_EC_EC_Appl=> >e-style-span style=3D3D"FONT-FAMILY: GillSans-Light"=3D
>=3B >=3B>=> >=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-span style=3D3D"FONT-FAMILY: G=> >illSans-Lig=3D
>=3B >=3Bht">=3B&=3Bnbsp=3D3B+1 765 494 6001 |&l=> >t=3BSPAN class=3D3DEC_EC_Apple-converted-space>=3B&=3Bnbs=3D
>=3B=> > >=3Bp=3D3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/FONT=> >>=3B<=3BFONT class=3D3DEC_EC_EC_Apple-style-span fac=3D
>=3B >=> >=3Be=3D3D"Gill Sans" color=3D3D#0000ff>=3B<=3BSPAN class=3D3DEC_EC_EC_A=> >pple-style-span sty=3D
>=3B >=3Ble=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=> >=3D3B FONT-FAMILY: 'Gill Sans'">=3B<=3BSPAN class=3D3DEC=3D
>=3B &=> >gt=3B_EC_EC_Apple-style-span style=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=3D3B FO=> >NT-FAMILY: 'G=3D
>=3B >=3Bill Sans'">=3BMobile<=3B/SPAN>=3B<=> >=3B/SPAN>=3B<=3B/FONT>=3B<=3BFONT class=3D3DEC_EC_EC_Apple-style-sp=> >=3D
>=3B >=3Ban face=3D3DGillSans-Light>=3B<=3BSPAN class=3D3DEC=> >_EC_EC_Apple-style-span style=3D3D"F=3D
>=3B >=3BONT-FAMILY: GillSan=> >s-Light">=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-span style=3D
&g=> >t=3B >=3B=3D3D"FONT-FAMILY: GillSans-Light">=3B<=3BSPAN class=3D3DEC_=> >EC_Apple-converted-space>=3B=3D
>=3B >=3B&=3Bnbsp=3D3B<=3B/SP=> >AN>=3B+1 765 427 5484<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/FONT>=3B&=> >lt=3B/DIV>=3B
>=3B >=3B<=3BDIV>=3B<=3BFONT class=3D3DEC_EC_E=> >C_Apple-style-span face=3D3DGillSans-Light>=3B<=3BBR clas=3D
>=3B => >>=3Bs=3D3DEC_EC_EC_khtml-block-placeholder>=3B<=3B/FONT>=3B<=3B/D=> >IV>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SP=3D
=> >>=3B >=3BAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=> >=3BBR class=3D3DEC_EC_EC_Apple-interchange-newline>=3B<=3B/SP=3D
>=> >=3B >=3BAN>=3B<=3B/DIV>=3B<=3B/SPAN>=3B<=3B/DIV>=3B<=3BBR=> >>=3B
>=3B >=3B<=3BDIV>=3B
>=3B >=3B<=3BDIV>=3BOn 12=> > Jan 2009=3D2C at 01:44=3D2C Jay wrote:<=3B/DIV>=3B<=3BBR class=3D3DE=> >C_EC_EC_App=3D
>=3B >=3Ble-interchange-newline>=3B
>=3B >=> >=3B<=3BBLOCKQUOTE>=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-span sty=> >le=3D3D"WORD-SPACING: =3D
>=3B >=3B0px=3D3B FONT: 12px Helvetica=3D3=> >B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0=3D
>=3B >=3B)=> >=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=> >=3D3B B=3D
>=3B >=3BORDER-COLLAPSE: separate">=3B
>=3B >=3B=> ><=3BDIV class=3D3DEC_EC_EC_hmmessage style=3D3D"FONT-SIZE: 10pt=3D3B FONT=> >-FAMILY: Ve=3D
>=3B >=3Brdana">=3BIs there a way in Modula-3 to de=> >clare that&=3Bnbsp=3D3Ba type exists=3D2C a=3D
>=3B >=3Bnd there => >are &=3Blt=3D3B*external*&=3Bgt=3D3B instances of it=3D2C without "fu=> >lly" decl=3D
>=3B >=3Baring it=3D2C so that no Modula-3 can instanti=> >ate it?<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3BI have d=3D
>=3B &g=> >t=3Bone this for sigset_t and sem_t=3D2C but they could erroneously be inst=> >antiat=3D
>=3B >=3Bed by Modula-3 and I'd like to remove that abilit=> >y to mess up so easily.<=3BBR=3D
>=3B >=3B>=3B&=3Bnbsp=3D3B&l=> >t=3BBR>=3B(* This type is not declared correctly. It is only instantiate=> >=3D
>=3B >=3Bd in C code. *)<=3BBR>=3B&=3Bnbsp=3D3B sigset_t => >=3D3D RECORD END=3D3B<=3BBR>=3B<=3BBR>=3B(* This type =3D
>=3B=> > >=3Bis not declared correctly. It is only instantiated in C code. *)<=> >=3BBR>=3B&=3Bnbsp=3D
>=3B >=3B=3D3B sem_t =3D3D RECORD END=3D3B=> ><=3BBR>=3B<=3BBR>=3BIn C I believe you can do this=3D2C like:<=3B=> >=3D
>=3B >=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3Btypedef struct => >foo foo_t=3D3B&=3Bnbsp=3D3B<=3BSPAN class=3D3DEC_EC_E=3D
>=3B >=> >=3BC_Apple-converted-space>=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BBR&g=> >t=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3Bextern foo_t foo=3D
>=3B >=3B=3D=> >3B&=3Bnbsp=3D3B<=3BSPAN class=3D3DEC_EC_EC_Apple-converted-space>=3B=> >&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BBR>=3B=3D
>=3B >=3B&=3Bn=> >bsp=3D3B<=3BBR>=3B&=3Bnbsp=3D3Bvoid UseFoo(foo_t*)=3D3B<=3BSPAN cl=> >ass=3D3DEC_EC_EC_Apple-conv=3D
>=3B >=3Berted-space>=3B&=3Bnbsp=> >=3D3B<=3B/SPAN>=3B<=3BBR>=3B&=3Bnbsp=3D3B foo_t* GetFoo(void)=3D=> >3B<=3BSPAN class=3D
>=3B >=3B=3D3DEC_EC_EC_Apple-converted-space&g=> >t=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR=> >>=3BThanks=3D2C<=3B=3D
>=3B >=3BBR>=3B&=3Bnbsp=3D3B- Jay<=> >=3BBR>=3B<=3BBR>=3B<=3BBR>=3B<=3BBR>=3B<=3B/DIV>=3B<=3B=> >/SPAN>=3B<=3B/BLOCKQUOTE>=3B<=3B/DIV>=3B<=3BBR>=3B<=3B/DIV&=> >gt=3B<=3B=3D
>=3B >=3B/DIV>=3B<=3B/SPAN>=3B<=3BBR class=3D=> >3DEC_EC_Apple-interchange-newline>=3B<=3B/BLOCKQUOTE>=3B<=3B/DIV>=> >=3B=3D
>=3B >=3B<=3BBR>=3B<=3B/DIV>=3B<=3B/SPAN>=3B<=> >=3BBR class=3D3DEC_Apple-interchange-newline>=3B<=3B/BLOCKQUOTE>=3B&l=> >t=3B/DI=3D
>=3B >=3BV>=3B<=3BBR>=3B<=3B/body>=3B
>=3B=> > >=3B<=3B/html>=3B=3D
>=3B >=3B
>=3B >=3B--_6117a048-91=> >85-4c03-badb-ef8f93402268_--

> >=> >> >--_2e194b09-14b6-4301-9116-a9e4d1e522b4_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 12:45:23 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 11:45:23 +0000 Subject: [M3devel] map/def files to limit exports to only functions in interfaces Message-ID: On Windows, a "def" file lists extra linker parameters, mainly a list of functions to export. On most Posix systems, a "map" serves the same purpose. On Windows, a "map" file is actually a linker output, that is roughly, a text file with some symbol information. On Windows, the default set of functions to export is empty. You can either decorate your source code with __declspec(dllexport), or write a .def file. Some build systems -- including cm3 -- grovel .obj files and put every symbol in the .def file. Typical Unix behavior is to export all symbols. More so, typical Unix behavior is to try to make "shared objects" very much like "objects". In particular, to treat all the shared objects within a process as containing one global/pooled namespace. Therefore, the first shared object loaded that exports a function named "open", is the target of any unresolved links to the symbol "open". This is a feature. It lets folks "interpose" and/or "preload" their own special shared object that implements whatever function in its own special way. Such dynamic resolution occurs by default for all non-static symbols. I'm not sure how it works out, but two shared objects might contain a function foo, that they each call, expecting to their own, but as I understand, they might both call the first loaded one. You can control linking presumably by declaring functions static, but that doesn't work if you have multiple source files in your shared object and want to call between them. There are some details I am uncertain of, to be sure. > This is a feature.. But, I believe it is more broadly understood to be a mistake. At some early point, like around 10.2, Apple changed from a "flat namespace" to "two level namespace". That is, when I link, on the development machine, "open" was found in e.g. "libc.so", so in my foo.exe, not just the symbol "open" is recorded, but "libc" is associated with it. So at load time, "open" is not looked at in all shared objects, but only in "libc" (could there be more than one, in different directories, I don't know). Is this just a "hint" or it "must be so"? I'm not sure. Solaris linker man pages give the "export everything" as the historical default, but not the recommended practise. There is a paper by the Linux ld.so maintainer -- Ulrich Drepper -- with advise I believe compatible with my thinking. Limit exports to only what you intend. Bind symbols locally that you implement. Don't leave all symbols "interposable", only ones you intend to import from somewhere else. When I was debugging AMD64_LINUX months ago, I found that even nested functions were exported and interposable, and the delayed resolution of them trashed the static link. So at the time I changed just their behavior. There is new syntax and command line flags to gcc to control what they call "visibility". Historical default, everything is visible/exported. Current guidance is, switch the default to not exported, and "decorate" source code with "__attribute__" or a wrapper macro thereof. SO...... Today we export "every" function -- including functions not defined in an .i3 file. This is inefficient. I strongly propose that we generate "def" files for Win32 and "map" files for "everyone else" (being sure to read up on the Solaris linker, GNU linker, BSD linkers, and later Irix, AIX, HP-UX, OSF, etc.) that list only functions in .i3 files, and the module_m3 and/or _i3 symbols, whatever is needed. I've already done some initial investigation here. It is doable in the front end but I believe m3linker is the right place. The front end visits interface/module at a time, whereas this work needs to be done once per "package" or "library", and cannot really be done incrementally, and it is small anyway. We don't need signatures, just lists of functions (and, on some systems..variables) in interfaces. Actually, I think this work could lead to "fixing data imports on Win32", but that's another subject and it is likely avoidable (you would change all cross-interface variable references to go through pointers, in case they are imported, then linker can synthesize the pointers if ends up not imported, kind of backwards from the way importing functions where, where the default is a direct call and linker can synthesize thunks for imports). Reasonable? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 15:05:34 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 14:05:34 +0000 Subject: [M3devel] a note on user thread -- *context not 'universal' Message-ID: just a note, that make/get/set/swapcontext are not available on Darwin (10.4) and OpenBSD.I didn't check NetBSD. It is on Linux, Solaris, FreeBSD. A "dual" approach where some ports use setjmp/longjmp, some use *context, probably reasonable. Another approach that would probably work is you double up the jmpbuf.Always make a copy before setjmp and setjmp to the copy.That way if longjmp "scrambles" it, no matter.If you can't even copy them, well, setjmp to the "original", copy it away, and thenrecopy before any setjmp. However, this is inefficient and using *context is probably better, where it is available. question: On Windows, you can "reserve" virtual memory, and "commit" it."reserve" is allocating just the address space."commit" I think is ensuring there is room in a pagefile.Reserve is cheaper. You can overrreserve but I guess not long-term overcommit.Usually stacks are only ever at first reserved, and then commited gradually,like a page at a time. Whatever *context documentation I could find, didn't talk about this.They either used a local char array, or a called mmap.On at least some platforms, there a flag to mmap to indicate you are creating a stack. Do we really need the assembly _fpsetjmp? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Jan 12 15:30:20 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 12 Jan 2009 15:30:20 +0100 Subject: [M3devel] a note on user thread -- *context not 'universal' In-Reply-To: References: Message-ID: <20090112153020.qff8fc7eioc8kocs@mail.elegosoft.com> Quoting Jay : > Do we really need the assembly _fpsetjmp? IIRC, I introduced fpsetjmp/fplongjmp when I made the first FreeBSD code, as FreeBSD does not care about storing the floating point state, and spurious FP errors occured when switching threads by longjmp. I think Bruce Evans contributed the FreeBSD assembler code. It may be that Darwin, which is derived from FreeBSD in certain areas, has inherited this problem (I don't remember offhand, and I haven't done much BSD or M3 programming in recent months). I think no other systems needed to use specially crafted setjmp/longjmp pairs to accomodate the M3 user threads. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Mon Jan 12 22:04:02 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 13 Jan 2009 08:04:02 +1100 Subject: [M3devel] a note on user thread -- *context not 'universal' In-Reply-To: <20090112153020.qff8fc7eioc8kocs@mail.elegosoft.com> References: <20090112153020.qff8fc7eioc8kocs@mail.elegosoft.com> Message-ID: <9C37CD59-A42F-4B4F-BE9D-2295817B1C71@cs.purdue.edu> makecontext/getcontext/setcontext and friends are both available on Darwin and should do FP state properly. On 13 Jan 2009, at 01:30, Olaf Wagner wrote: > Quoting Jay : > >> Do we really need the assembly _fpsetjmp? > > IIRC, I introduced fpsetjmp/fplongjmp when I made the first FreeBSD > code, > as FreeBSD does not care about storing the floating point state, > and spurious FP errors occured when switching threads by longjmp. > I think Bruce Evans contributed the FreeBSD assembler code. > > It may be that Darwin, which is derived from FreeBSD in certain areas, > has inherited this problem (I don't remember offhand, and I haven't > done much BSD or M3 programming in recent months). I think no other > systems needed to use specially crafted setjmp/longjmp pairs to > accomodate the M3 user threads. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hosking at cs.purdue.edu Mon Jan 12 22:01:33 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 13 Jan 2009 08:01:33 +1100 Subject: [M3devel] a note on user thread -- *context not 'universal' In-Reply-To: References: Message-ID: <19C99B21-4997-4ABB-8BD2-4992FD0513AE@cs.purdue.edu> They *are* available on Darwin 10.5 and I am pretty sure they were there on 10.4. Have you installed the developer kit (with man pages)? On 13 Jan 2009, at 01:05, Jay wrote: > just a note, that make/get/set/swapcontext are not available on > Darwin (10.4) and OpenBSD. > I didn't check NetBSD. It is on Linux, Solaris, FreeBSD. > > > A "dual" approach where some ports use setjmp/longjmp, some use > *context, probably reasonable. > > > Another approach that would probably work is you double up the jmpbuf. > Always make a copy before setjmp and setjmp to the copy. > That way if longjmp "scrambles" it, no matter. > If you can't even copy them, well, setjmp to the "original", copy it > away, and then > recopy before any setjmp. > > > However, this is inefficient and using *context is probably better, > where it is available. > > > question: > > > On Windows, you can "reserve" virtual memory, and "commit" it. > "reserve" is allocating just the address space. > "commit" I think is ensuring there is room in a pagefile. > Reserve is cheaper. You can overrreserve but I guess not long-term > overcommit. > Usually stacks are only ever at first reserved, and then commited > gradually, > like a page at a time. > > > Whatever *context documentation I could find, didn't talk about this. > They either used a local char array, or a called mmap. > On at least some platforms, there a flag to mmap to indicate you are > creating a stack. > > > Do we really need the assembly _fpsetjmp? > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 23:20:24 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 22:20:24 +0000 Subject: [M3devel] a note on user thread -- *context not 'universal' In-Reply-To: <19C99B21-4997-4ABB-8BD2-4992FD0513AE@cs.purdue.edu> References: <19C99B21-4997-4ABB-8BD2-4992FD0513AE@cs.purdue.edu> Message-ID: They really don't seem to be there, on 10.4. I haven't check the libs yet but they are not in the headers or man pages. Do you have installed the "multiple SDKs" (headers/libs for multiple OS versions)? Look at in /Developer/SDKs. Anyway, they also aren't on OpenBSD so a dual approach will be needed which I think is ok. Heck, probably one set of Modula-3 but #ifdefed C. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Tue, 13 Jan 2009 08:01:33 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] a note on user thread -- *context not 'universal' They *are* available on Darwin 10.5 and I am pretty sure they were there on 10.4. Have you installed the developer kit (with man pages)? On 13 Jan 2009, at 01:05, Jay wrote: just a note, that make/get/set/swapcontext are not available on Darwin (10.4) and OpenBSD.I didn't check NetBSD. It is on Linux, Solaris, FreeBSD. A "dual" approach where some ports use setjmp/longjmp, some use *context, probably reasonable. Another approach that would probably work is you double up the jmpbuf.Always make a copy before setjmp and setjmp to the copy.That way if longjmp "scrambles" it, no matter.If you can't even copy them, well, setjmp to the "original", copy it away, and thenrecopy before any setjmp. However, this is inefficient and using *context is probably better, where it is available. question: On Windows, you can "reserve" virtual memory, and "commit" it."reserve" is allocating just the address space."commit" I think is ensuring there is room in a pagefile.Reserve is cheaper. You can overrreserve but I guess not long-term overcommit.Usually stacks are only ever at first reserved, and then commited gradually,like a page at a time. Whatever *context documentation I could find, didn't talk about this.They either used a local char array, or a called mmap.On at least some platforms, there a flag to mmap to indicate you are creating a stack. Do we really need the assembly _fpsetjmp? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 23:39:01 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 22:39:01 +0000 Subject: [M3devel] cygwin/pthread still broken fyi Message-ID: Just fyi, I tried cygwin with pthreads and it crashes in "startup" (well, it gets as far as sysutils entry which is pretty far) Switched back to Wni32 threads, no crash. I will debug more later. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Jan 13 00:23:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 13 Jan 2009 10:23:36 +1100 Subject: [M3devel] a note on user thread -- *context not 'universal' In-Reply-To: References: <19C99B21-4997-4ABB-8BD2-4992FD0513AE@cs.purdue.edu> Message-ID: <8FA8E456-79FB-40CE-A7CA-D53DE0E88980@cs.purdue.edu> Hmm, weird -- I am sure I looked at that a long time back. On 13 Jan 2009, at 09:20, Jay wrote: > They really don't seem to be there, on 10.4. > I haven't check the libs yet but they are not in the headers or man > pages. > Do you have installed the "multiple SDKs" (headers/libs for multiple > OS versions)? > Look at in /Developer/SDKs. > Anyway, they also aren't on OpenBSD so a dual approach will be needed > which I think is ok. > Heck, probably one set of Modula-3 but #ifdefed C. > > - Jay > > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 13 Jan 2009 08:01:33 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] a note on user thread -- *context not > 'universal' > > > They *are* available on Darwin 10.5 and I am pretty sure they were > there on 10.4. Have you installed the developer kit (with man pages)? > > On 13 Jan 2009, at 01:05, Jay wrote: > > just a note, that make/get/set/swapcontext are not available on > Darwin (10.4) and OpenBSD. > I didn't check NetBSD. It is on Linux, Solaris, FreeBSD. > > > A "dual" approach where some ports use setjmp/longjmp, some use > *context, probably reasonable. > > > Another approach that would probably work is you double up the jmpbuf. > Always make a copy before setjmp and setjmp to the copy. > That way if longjmp "scrambles" it, no matter. > If you can't even copy them, well, setjmp to the "original", copy it > away, and then > recopy before any setjmp. > > > However, this is inefficient and using *context is probably better, > where it is available. > > > question: > > > On Windows, you can "reserve" virtual memory, and "commit" it. > "reserve" is allocating just the address space. > "commit" I think is ensuring there is room in a pagefile. > Reserve is cheaper. You can overrreserve but I guess not long-term > overcommit. > Usually stacks are only ever at first reserved, and then commited > gradually, > like a page at a time. > > > Whatever *context documentation I could find, didn't talk about this. > They either used a local char array, or a called mmap. > On at least some platforms, there a flag to mmap to indicate you are > creating a stack. > > > Do we really need the assembly _fpsetjmp? > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eiserlohpp at yahoo.com Tue Jan 13 08:31:27 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Mon, 12 Jan 2009 23:31:27 -0800 (PST) Subject: [M3devel] dynamic chose between user/kernel threads? Message-ID: <486480.21981.qm@web56801.mail.re3.yahoo.com> >> [Jay] Some programs "better" with user threads >> [Tony] Is this still true for modern kernel thread systems? > >I really don't know. >Olaf /kind of/ indicated so (just in saying that it'd be a nice option to have). > >> [Jay] small stacks for many threads vs. larger stacks for calls to "the system" >> [Tony] In a systems programming language like Modula-3 shouldn't threads have a relationship to the system? >> Is it a boolean or an enum? >> Cygwin might conceivably get pthreads support (Cygwin has it, but >> Modula-3/Cygwin does not). >> Therefore, is the choice among "posix" threads, "pthreads" and "NT" >> threads? >> Or just user vs. kernel? > >I would argue for user vs. kernel. Correct me if I am wrong, but don't user threads all run in the same process, and therefore, can't make use of multi-processors (ie, SMP machines). Many people now even have dual core machines, or even quad core, let alone motherboards with many processors on them. At least with Linux, the old system thread library (I forgot its name, it been a number of years) used user level threads. Then Linus invented the clone() system call, which acted similarly to a fork(), but kept the same virtual memory and file contexts. This allowed threads to act like processes, and migrate to other processors of an SMP machine. This is what the Linux implementation of the pthread library currently uses, to take advantage of modern machine architectures. This is a kernel thread under Linux. This should be significant reason for prefering the pthread threading library, and should probably be the default. Default to "kernel" theads. Allow "user" threads. Don't make it a binary choice. If a port wants to make available a third (or fourth) threading option they should be able to do so. Just don't expect many people to jump up and down for joy. If a platform does not support kernel threads, (eg, PalmOS) uh ... (what we don't support it yet), then only support user threads. If a port were to be built that ran on bare hardware (such as the "SPIN" OS) they would have to implement their own thread mechanism, and must not include any support for a thread library which expects to be in user space with a kernel providing OS support. BTW: I think putting IF statements in all the threading code looks ugly. Couldn't you implement it as an OBJECT ThreadMechanism, and derive the specific mechanisms: ThreadUserMechanism, ThreadPThreadMechanism, ThreadWinNTMechanism, ThreadDoItYourselfMechanism. The startup code would choose which one to instantiate. All thread and mutex calls would use that object to perform its action. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Tue Jan 13 09:19:17 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 13 Jan 2009 08:19:17 +0000 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: <486480.21981.qm@web56801.mail.re3.yahoo.com> References: <486480.21981.qm@web56801.mail.re3.yahoo.com> Message-ID: > Terminology wrong, but your point is correct. A "process" is an "address space" and isolation boundary for security. A thread is a unit of scheduling, a stack and register context. "Straightforward" user threads indeed, you would only ever run one at a time, per process, even on a multi threaded systems. People speak of N:M 1:1 or N:1 One number is number of user threads. The other is kernel threads. You can have a hybrid where some number of user threads are scheduled on some smaller number of kernel threads. You can have one to one. You can have one kernel thread (e.g. on a system without kernel threads-- just processes) that you use to run multiple user threads. Historically N:1 was the only option. Then some people moved to N:M. Such as older releases of Solaris. These days almost everything is 1:1. However some people still don't think this is clearly and always best. And on rare occasion, perhaps it is not. N:M is an interesting hybrid, it gives user threads a chance to scale on a multiprocessor. But it is probably the most difficult to implement. If you read near the beginning of the 2nd edition of "Solaris Internals" they talk about some of this, and how Solaris 10 (9?) improved things by making it all "1:1". I consider user threads extremely uninteresting but folks here are vocally interested in them. And right there are systems without kernel threads. Like, I've been thinking of making a I386_MSDOS_DJGPP or such release. It appears to have sufficient support for the user threads -- alarm(). > IF looks ugly. Couldn't you implement it as an OBJECT I said function pointers at one point. Same thing. If it was IF, it'd be an extra layer outside all of the "real" code and so wouldn't be ugly at all. But maybe slower. Something I've been meaning to ask. The old Linux library was "LinuxThreads". "NPTL" is the Native PThread Library. Modula-3 only seemed to switch to pthreads with NPTL widely available. But I assume the pthreads interface was implemented over LinuxThreads? Couldn't Modula-3 have used that, earlier? That is, couldn't Modula-3 using pthreads claim to work to older versions?There's a comment in thread/m3makefile that suggests NPTL is required. I guess it is moot. NPTL is here and nobody probably runs the older stuff?? (I ran Modula-3/LINUXELF briefly on 1.2. Imho binary compatibility mandates that it should still work... certainly I continue to use Windows software from the same time period every day.) - Jay> Date: Mon, 12 Jan 2009 23:31:27 -0800> From: eiserlohpp at yahoo.com> To: m3devel at elegosoft.com> Subject: [M3devel] dynamic chose between user/kernel threads?> > >> [Jay] Some programs "better" with user threads> >> [Tony] Is this still true for modern kernel thread systems?> >> >I really don't know.> >Olaf /kind of/ indicated so (just in saying that it'd be a nice option to have).> >> >> [Jay] small stacks for many threads vs. larger stacks for calls to "the system"> >> [Tony] In a systems programming language like Modula-3 shouldn't threads have a relationship to the system?> > > >> Is it a boolean or an enum?> >> Cygwin might conceivably get pthreads support (Cygwin has it, but > >> Modula-3/Cygwin does not).> >> Therefore, is the choice among "posix" threads, "pthreads" and "NT" > >> threads?> >> Or just user vs. kernel?> >> >I would argue for user vs. kernel.> > > Correct me if I am wrong, but don't user threads all run> in the same process, and therefore, can't make use of> multi-processors (ie, SMP machines). Many people now even> have dual core machines, or even quad core, let alone > motherboards with many processors on them.> > At least with Linux, the old system thread library (I> forgot its name, it been a number of years) used user> level threads. Then Linus invented the clone() system> call, which acted similarly to a fork(), but kept the> same virtual memory and file contexts. This allowed> threads to act like processes, and migrate to other> processors of an SMP machine.> > This is what the Linux implementation of the pthread> library currently uses, to take advantage of modern> machine architectures. This is a kernel thread under> Linux.> > This should be significant reason for prefering the pthread> threading library, and should probably be the default.> > Default to "kernel" theads. Allow "user" threads. Don't> make it a binary choice. If a port wants to make available> a third (or fourth) threading option they should be able> to do so. Just don't expect many people to jump up and> down for joy.> > If a platform does not support kernel threads, (eg, PalmOS)> uh ... (what we don't support it yet), then only support> user threads. > > If a port were to be built that ran on bare hardware (such> as the "SPIN" OS) they would have to implement their own> thread mechanism, and must not include any support for a> thread library which expects to be in user space with a> kernel providing OS support.> > BTW: I think putting IF statements in all the threading> code looks ugly. Couldn't you implement it as an OBJECT> ThreadMechanism, and derive the specific mechanisms:> ThreadUserMechanism, > ThreadPThreadMechanism, > ThreadWinNTMechanism,> ThreadDoItYourselfMechanism.> > The startup code would choose which one to instantiate.> All thread and mutex calls would use that object to > perform its action.> > > +--------------------------------------------------------+> | Peter P. Eiserloh |> +--------------------------------------------------------+> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jan 13 15:54:38 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 13 Jan 2009 14:54:38 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: > fix for old compilers that can't compile LONGINT: define LongRep.T = INTEGER Is that what bootstrapping should do? Automate that little patch for the first pass and undo it in the second? Then always building in dependency order? Tonight I was trying to build from PPC_DARWIN 5.5.0. I figured, heck, maybe it supports LONGINT already, maybe I should just try building up in dependency order. But then I hit the problem of Compiler.i3 mismatch due to new targets. So...is that correct? Does building in dependency order predictably fail if compiler has fewer targets than runtime? But starting with existing m3core/libm3 and first building the compiler against them predictably works? I've added targets a bunch and usually don't have a problem, but I can't say for certain what order I do things when I do this. Certainly "upgrade.py skipgcc" is something I run fairly often. It is very fast on NT386 (and unlike upgrade.sh, it doesn't build all of std). For now I put in two small hacks to sysutils, so it works with old m3core. I was stuck otherwise. The hacks are: - assume kernel threads or "single threaded" That is -- always pass 0 for the waitpid option. If sysutils client is multithreaded (always the case), and parent threads depend on child processes (not always the case), and user threads (really not always the case), then there risk of deadlock. - if status is non zero but lower 8 bits are zero, set it to 1, to ensure non-zero in lower bits This could be done correctly by copying the current Uexec code into sysutils. Maybe Compiler.i3 can somehow be implemented to "just work"? And eliminate the redundancy as well? Have the compiler inject its definition into m3core/libm3? - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Mon, 12 Jan 2009 19:22:13 +1100 CC: jkrell at elego.de; m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 I think there is a straightforward fix for old compilers that can't compile LONGINT: define LongRep.T = INTEGER. Most everything should compile from there. That's what I recall doing to upgrade my compiler to handle LONGINT. LONGINT is not used anywhere else in m3core, so nothing depends on it working. On 12 Jan 2009, at 19:02, Jay wrote:If old compiler can't build m3core, such as if old compiler predates LONGINT. You already know this. Are we "past" such compilers? - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Mon, 12 Jan 2009 18:51:08 +1100 CC: jkrell at elego.de; m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Why do you not build in the following order to get a new compiler? (You may need to downgrade Compiler.tmpl for use with an old compiler so that you don't get a mismatch between m3core and libm3, but otherwise the following sequence should work). m3corelibm3sysutilsm3middlem3objfilem3linkerm3backm3frontm3quakecm3 On 12 Jan 2009, at 18:25, Jay wrote:The compiler uses sysutils. The first pass builds against an old package store, which might not have sysutils at all, if it is that old. Again, once new m3core is around, no problem. I could/should have put in the m3core change and just waited on the sysutils change, rather than go ahead and do the quake stuff, and we can do that now (or your change that moots it, which I haven't looked into yet). I was browsing the docs and it appears there is an "import_pkg" directive for like, copying in a package contents, instead of linking. That might also solve this. I found that relatively late and never looked into it. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Mon, 12 Jan 2009 18:19:55 +1100 CC: jkrell at elego.de; m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Not true. sysutils should be built against the m3core with which it will be linked. I don't think this is correct. On 12 Jan 2009, at 17:58, Jay wrote:To bootstrap I believe. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Mon, 12 Jan 2009 17:53:02 +1100 CC: jkrell at elego.de; m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Why does sysutils need to be compatible with both old and new versions of m3core? On 12 Jan 2009, at 17:39, Jay wrote:ThreadPosix is basically unaffected -- I never provided user threads on Cygwin. I guess it got a slight reduction regarding DoesWaitPidYield, but its SchedulerPosix implementation was unchanged. The code in ThreadPosix is similar to but different than ThreadPThread. It is possible they could be merged but it wasn't trivial so I left ThreadPosix alone. > You are smearing implementation details across multiple files and directories You really think it is bad to have SchedulerPosix implemented in a small separate file? On top of what happens to be common implementation details of ThreadPThread.m3 and ThreadWin32.m3? ThreadPScheduler.m3 is just basically three functions: IOWait, IOAlertWait, XIOWait Plus the little internal utility, UTimeFromTime, the one liner DoesWaitPidYield, and non-trivial functions nested in XIOWait: TestFDS, CallSelect. I mean, you know, an alternative is to copy out very large chunks of ThreadWin32.m3 and ThreadPThread.m3 and merge them into ThreadCygwin.m3. That would be worse imho. "Directories" hardly. Or I can try debugging cygwin pthreads again. - Jay CC: jkrell at elego.de; m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Date: Mon, 12 Jan 2009 12:46:54 +1100 You are smearing implementation details across multiple files and directories. Up until now, ThreadPThread has been nicely self-contained, and captured all the basic pieces of the thread implementation. Also, how does all of this fit with the ThreadPosix implementation? On 12 Jan 2009, at 12:19, Jay wrote:btw, I don't think it's that hairy, I merely split it into two or three files, and added interfaces so they can reuse code with each other. Movement between files is hard to track though (depending on version control, but with all I've used). The SchedulerPosix implementation moved to ThreadPScheduler.m3. What is shared between it and ThreadPThread/Win32.m3 is ThreadInternal.i3, which maybe should be in ThreadF.i3, though that's exposed outside m3core, and ThreadInternal.i3 includes a variable. I can try again to debug Cygwin pthreads though. - Jay > From: hosking at cs.purdue.edu > To: jkrell at elego.de > Date: Mon, 12 Jan 2009 11:03:33 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Jay, > > Can you remind me again why Cygwin was unable to use pthreads? It > seems you have introduced a bunch of hair into the PTHREADS > implementation to deal with broken Cygwin pthreads. As many of us > have already pointed out, Cygwin should be a port that tries as much > as possible to be like a standard POSIX platform (pthread-based) as > opposed to a weird Windows/POSIX hybrid. > > I have a bunch of code that will be going into the PTHREADS base that > I am now at a loss to integrate with the changes you have made. > > Help! > > -- Tony > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Jan 13 16:06:21 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 13 Jan 2009 16:06:21 +0100 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: References: <486480.21981.qm@web56801.mail.re3.yahoo.com> Message-ID: <20090113160621.07cnshm5cgc0s0w8@mail.elegosoft.com> If I remember correctly, until Antony Hosking provided the PThreads implementation, M3 only used its own user-level threads on all POSIX platforms (but not on Windows). The ability to use system pthread libraries has been added rather late. (M3's) user level threads are extremely fast and use little resources (configurable stack sizes). External system threads have a little more overhead due to the extra user/kernel mode switches for all scheduling related activies. They have got the advantage that they can be used for scaling across multiple processors (which wasn't possible with M3 on Unix until recently). I agree that these days kernel threads should be the default, as they are available on almost every system and usually reasonably stable and fast (which was not so when M3 was created). Nonetheless M3's user level threads can have advantages for certain uses and should not be discarded, as they have proven to be mature and useful. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Jan 13 16:08:45 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 13 Jan 2009 16:08:45 +0100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: <20090113160845.y5ucq4et28o484cs@mail.elegosoft.com> Quoting Jay : > > > fix for old compilers that can't compile LONGINT: define > LongRep.T = INTEGER > > Is that what bootstrapping should do? > Automate that little patch for the first pass and undo it in the second? > Then always building in dependency order? > > > Tonight I was trying to build from PPC_DARWIN 5.5.0. > I figured, heck, maybe it supports LONGINT already, maybe I should just try > building up in dependency order. > But then I hit the problem of Compiler.i3 mismatch due to new targets. > > > So...is that correct? > Does building in dependency order predictably fail if compiler has > fewer targets than runtime? > But starting with existing m3core/libm3 and first building the > compiler against them predictably works? As far as I remember it has always been this way with (C)M3. Runtime and compiler must agree wrt. target platforms. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Jan 13 19:45:43 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 13 Jan 2009 18:45:43 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20090113160845.y5ucq4et28o484cs@mail.elegosoft.com> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> <20090113160845.y5ucq4et28o484cs@mail.elegosoft.com> Message-ID: > As far as I remember it has always been this way with (C)M3.> Runtime and compiler must agree wrt. target platforms.> > Olaf I /think/ they can disagree, as long as you don't build the runtime. That is, when you add new platforms, you build the updated compiler first, against an old runtime, then build the updated runtime. I'm just speculating though based on my being stuck last night trying to build m3core first, vs. that I often build the compiler first. I also wonder if it must be this way -- if the compiler can't inject into the runtime its list of targets. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 14 00:11:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 14 Jan 2009 10:11:36 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: On 14 Jan 2009, at 01:54, Jay wrote: > > fix for old compilers that can't compile LONGINT: define > LongRep.T = INTEGER > > Is that what bootstrapping should do? > Automate that little patch for the first pass and undo it in the > second? > Then always building in dependency order? I would prefer to get all the bootstrap archives LONGINT-capable. Just do the patch by hand to build the initial archives and then forget about it. > Tonight I was trying to build from PPC_DARWIN 5.5.0. > I figured, heck, maybe it supports LONGINT already, maybe I should > just try > building up in dependency order. > But then I hit the problem of Compiler.i3 mismatch due to new targets. > So...is that correct? > Does building in dependency order predictably fail if compiler has > fewer targets than runtime? > But starting with existing m3core/libm3 and first building the > compiler against them predictably works? Yes, it works. > I've added targets a bunch and usually don't have a problem, but I > can't say for certain what > order I do things when I do this. > Certainly "upgrade.py skipgcc" is something I run fairly often. > It is very fast on NT386 (and unlike upgrade.sh, it doesn't build > all of std). Sounds like your upgrade script > For now I put in two small hacks to sysutils, so it works with old > m3core. No! I did not want to do have this hack. Let's just fix the boot archives to handle new m3core and have sysutils work as expected. The alternative is to fold sysutils into m3core, where it can be used directly. That might be a better solution given the dependency. Thoughts? > I was stuck otherwise. > > > The hacks are: > - assume kernel threads or "single threaded" > That is -- always pass 0 for the waitpid option. > If sysutils client is multithreaded (always the case), > and parent threads depend on child processes (not always the > case), > and user threads (really not always the case), > then there risk of deadlock. > > - if status is non zero but lower 8 bits are zero, set it to 1, to > ensure non-zero in lower bits > This could be done correctly by copying the current Uexec code > into sysutils. > > > Maybe Compiler.i3 can somehow be implemented to "just work"? > And eliminate the redundancy as well? > Have the compiler inject its definition into m3core/libm3? > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 19:22:13 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > I think there is a straightforward fix for old compilers that can't > compile LONGINT: define LongRep.T = INTEGER. Most everything should > compile from there. That's what I recall doing to upgrade my > compiler to handle LONGINT. LONGINT is not used anywhere else in > m3core, so nothing depends on it working. > > On 12 Jan 2009, at 19:02, Jay wrote: > > If old compiler can't build m3core, such as if old compiler predates > LONGINT. > You already know this. > Are we "past" such compilers? > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 18:51:08 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > Why do you not build in the following order to get a new compiler? > (You may need to downgrade Compiler.tmpl for use with an old > compiler so that you don't get a mismatch between m3core and libm3, > but otherwise the following sequence should work). > > m3core > libm3 > sysutils > m3middle > m3objfile > m3linker > m3back > m3front > m3quake > cm3 > > On 12 Jan 2009, at 18:25, Jay wrote: > > The compiler uses sysutils. The first pass builds against an old > package store, which might not have sysutils at all, if it is that > old. > > Again, once new m3core is around, no problem. > I could/should have put in the m3core change and just waited on the > sysutils change, rather than go ahead and do the quake stuff, and we > can do that now (or your change that moots it, which I haven't > looked into yet). > > I was browsing the docs and it appears there is an "import_pkg" > directive for like, copying in a package contents, instead of > linking. That might also solve this. I found that relatively late > and never looked into it. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 18:19:55 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Not true. sysutils should be built against the m3core with which it > will be linked. I don't think this is correct. > > On 12 Jan 2009, at 17:58, Jay wrote: > > To bootstrap I believe. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 17:53:02 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Why does sysutils need to be compatible with both old and new > versions of m3core? > > On 12 Jan 2009, at 17:39, Jay wrote: > > ThreadPosix is basically unaffected -- I never provided user threads > on Cygwin. > I guess it got a slight reduction regarding DoesWaitPidYield, but > its SchedulerPosix implementation was unchanged. > > The code in ThreadPosix is similar to but different than > ThreadPThread. > It is possible they could be merged but it wasn't trivial so I left > ThreadPosix alone. > > > You are smearing implementation details across multiple files and > directories > > You really think it is bad to have SchedulerPosix implemented in a > small separate file? > On top of what happens to be common implementation details of > ThreadPThread.m3 and ThreadWin32.m3? > > ThreadPScheduler.m3 is just basically three functions: IOWait, > IOAlertWait, XIOWait > Plus the little internal utility, UTimeFromTime, the one liner > DoesWaitPidYield, and non-trivial functions nested in XIOWait: > TestFDS, CallSelect. > > I mean, you know, an alternative is to copy out very large chunks of > ThreadWin32.m3 and ThreadPThread.m3 and merge them into > ThreadCygwin.m3. That would be worse imho. > > "Directories" hardly. > > Or I can try debugging cygwin pthreads again. > > - Jay > > > CC: jkrell at elego.de; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Mon, 12 Jan 2009 12:46:54 +1100 > > You are smearing implementation details across multiple files and > directories. Up until now, ThreadPThread has been nicely self- > contained, and captured all the basic pieces of the thread > implementation. Also, how does all of this fit with the ThreadPosix > implementation? > > On 12 Jan 2009, at 12:19, Jay wrote: > > btw, I don't think it's that hairy, I merely split it into two or > three files, and added interfaces so they can reuse code with each > other. Movement between files is hard to track though (depending on > version control, but with all I've used). > > The SchedulerPosix implementation moved to ThreadPScheduler.m3. > What is shared between it and ThreadPThread/Win32.m3 is > ThreadInternal.i3, which maybe should be in ThreadF.i3, though > that's exposed outside m3core, and ThreadInternal.i3 includes a > variable. > > I can try again to debug Cygwin pthreads though. > > - Jay > > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:03:33 +1100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay, > > > > Can you remind me again why Cygwin was unable to use pthreads? It > > seems you have introduced a bunch of hair into the PTHREADS > > implementation to deal with broken Cygwin pthreads. As many of us > > have already pointed out, Cygwin should be a port that tries as much > > as possible to be like a standard POSIX platform (pthread-based) as > > opposed to a weird Windows/POSIX hybrid. > > > > I have a bunch of code that will be going into the PTHREADS base > that > > I am now at a loss to integrate with the changes you have made. > > > > Help! > > > > -- Tony > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jan 14 01:09:03 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 14 Jan 2009 00:09:03 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: > Sounds like your upgrade script Based on someone else's upgrade.sh. > The alternative is to fold sysutils into m3core, where it can be used directly Merging sysutils into m3core doesn't quite work, again only or due to bootstrapping from older builds. The compiler uses sysutils. Older builds don't have it at all, and can't build m3core...but maybe again, make that hand patch Long.Rep = INTEGER? Or have an up to date compiler. Pointless statement I'm making though, it devolves to: - have an up to date m3core in bootstrap - or have sysutils in bootstrap, which implies up to date m3core - or merge sysutils with m3core, which implies up to date m3core (and the second) => "have an up to date m3core" (and LONGINT capable compiler) And I think merging them is a fine idea. I generally like fewer larger pieces of reusable code, though the counterpoint is to have more smaller independently changable pieces. Probably the scripts and/or m3makefiles should probe the compiler version and/or m3core version and/or sysutils presence and error clearly if it is too old/absent. Possibly some "feature detection" feature is needed. The compiler can just define Quake variables willy/nilly. if defined("HAS_LONGINT") Less clear how to probe m3core capability. Can try compiling a little program against the old WaitProcess signature. I'm leary of anything that resembles autoconf though (though I have autoconf-ish stuff in my config files already, probing some cm3cg and cm3 behavior). Oh...I looked at WaitProcess history. It looks like I introduced it, in 2008. So..while it never returned the full status word, there also wasn't much history to change. Compiler could expose m3core functionality via variables too, though that..is wrong. It could only expose the m3core it is linked to, not the one it is building. I guess the only way really is to define a version or date constant and folks can write constant expressions based on it, though that doesn't get you very far. Less clear how to correctly probe for package existance. Easy to do ad-hoc by probing package store files, not sure what is the right way. I also want to try this "import_pkg" directive I see in the docs. It might help a lot here, if I understand it, and if it actually exists and resembles the doc I read. It sounds like it recompiles a package's source as part of another package, statically linking it. It would be bloating in the absence of build_standalone(), but not in its presence. > No! I did not want to do have this hack Are the hacks this time in sysutils really so bad? m3core is left unadulterated. sysutils assumes waitpid(0) won't deadlock, which is true of kernel threads and cm3's use. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Wed, 14 Jan 2009 10:11:36 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3 On 14 Jan 2009, at 01:54, Jay wrote: > fix for old compilers that can't compile LONGINT: define LongRep.T = INTEGERIs that what bootstrapping should do? Automate that little patch for the first pass and undo it in the second? Then always building in dependency order? I would prefer to get all the bootstrap archives LONGINT-capable. Just do the patch by hand to build the initial archives and then forget about it. Tonight I was trying to build from PPC_DARWIN 5.5.0.I figured, heck, maybe it supports LONGINT already, maybe I should just trybuilding up in dependency order.But then I hit the problem of Compiler.i3 mismatch due to new targets. So...is that correct?Does building in dependency order predictably fail if compiler has fewer targets than runtime?But starting with existing m3core/libm3 and first building the compiler against them predictably works? Yes, it works. I've added targets a bunch and usually don't have a problem, but I can't say for certain whatorder I do things when I do this.Certainly "upgrade.py skipgcc" is something I run fairly often.It is very fast on NT386 (and unlike upgrade.sh, it doesn't build all of std). Sounds like your upgrade script For now I put in two small hacks to sysutils, so it works with old m3core. No! I did not want to do have this hack. Let's just fix the boot archives to handle new m3core and have sysutils work as expected. The alternative is to fold sysutils into m3core, where it can be used directly. That might be a better solution given the dependency. Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 14 02:49:41 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 14 Jan 2009 12:49:41 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: <2FFBEA2D-98BF-4268-977C-4A4B38664B08@cs.purdue.edu> The current hack is not so bad, I suppose. I would prefer to come up with a solution that simply defines Process.Wait and System.Wait as returning a BOOLEAN indicating if the process terminated successfully or not. Are there any clients of these procedures that decode the bits in any more detail than simply testing non-zero? On 14 Jan 2009, at 11:09, Jay wrote: > > Sounds like your upgrade script > > Based on someone else's upgrade.sh. > > > > The alternative is to fold sysutils into m3core, where it can be > used directly > > Merging sysutils into m3core doesn't quite work, > again only or due to bootstrapping from older builds. > > The compiler uses sysutils. Older builds don't have it at all, > and can't build m3core...but maybe again, make that hand patch > Long.Rep = INTEGER? Or have an up to date compiler. > > > > Pointless statement I'm making though, it devolves to: > > > - have an up to date m3core in bootstrap > - or have sysutils in bootstrap, which implies up to date m3core > - or merge sysutils with m3core, which implies up to date m3core > (and the second) > => "have an up to date m3core" (and LONGINT capable compiler) > > And I think merging them is a fine idea. > I generally like fewer larger pieces of reusable code, though > the counterpoint is to have more smaller independently changable > pieces. > > > Probably the scripts and/or m3makefiles should probe the compiler > version > and/or m3core version and/or sysutils presence and error clearly if > it is too old/absent. > > Possibly some "feature detection" feature is needed. > > The compiler can just define Quake variables willy/nilly. > if defined("HAS_LONGINT") > Less clear how to probe m3core capability. > Can try compiling a little program against the old WaitProcess > signature. > I'm leary of anything that resembles autoconf though (though I > have autoconf-ish > stuff in my config files already, probing some cm3cg and cm3 > behavior). > Oh...I looked at WaitProcess history. It looks like I introduced > it, in 2008. > So..while it never returned the full status word, there also > wasn't much history > to change. > Compiler could expose m3core functionality via variables too, > though that..is wrong. > It could only expose the m3core it is linked to, not the one it > is building. > I guess the only way really is to define a version or date > constant and folks > can write constant expressions based on it, though that doesn't > get you very far. > > Less clear how to correctly probe for package existance. > Easy to do ad-hoc by probing package store files, not sure what is > the right way. > > > I also want to try this "import_pkg" directive I see in the docs. > It might help a lot here, > if I understand it, and if it actually exists and resembles the > doc I read. > It sounds like it recompiles a package's source as part of another > package, statically > linking it. It would be bloating in the absence of > build_standalone(), but not in its presence. > > > > No! I did not want to do have this hack > > Are the hacks this time in sysutils really so bad? > m3core is left unadulterated. > sysutils assumes waitpid(0) won't deadlock, which is true of kernel > threads and cm3's use. > > - Jay > > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Wed, 14 Jan 2009 10:11:36 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > On 14 Jan 2009, at 01:54, Jay wrote: > > > fix for old compilers that can't compile LONGINT: define > LongRep.T = INTEGER > > Is that what bootstrapping should do? > Automate that little patch for the first pass and undo it in the > second? > Then always building in dependency order? > > I would prefer to get all the bootstrap archives LONGINT-capable. > Just do the patch by hand to build the initial archives and then > forget about it. > > Tonight I was trying to build from PPC_DARWIN 5.5.0. > I figured, heck, maybe it supports LONGINT already, maybe I should > just try > building up in dependency order. > But then I hit the problem of Compiler.i3 mismatch due to new targets. > > So...is that correct? > Does building in dependency order predictably fail if compiler has > fewer targets than runtime? > But starting with existing m3core/libm3 and first building the > compiler against them predictably works? > > Yes, it works. > > I've added targets a bunch and usually don't have a problem, but I > can't say for certain what > order I do things when I do this. > Certainly "upgrade.py skipgcc" is something I run fairly often. > It is very fast on NT386 (and unlike upgrade.sh, it doesn't build > all of std). > > Sounds like your upgrade script > > For now I put in two small hacks to sysutils, so it works with old > m3core. > > No! I did not want to do have this hack. Let's just fix the boot > archives to handle new m3core and have sysutils work as expected. > The alternative is to fold sysutils into m3core, where it can be > used directly. That might be a better solution given the > dependency. Thoughts? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jan 14 03:33:53 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 14 Jan 2009 02:33:53 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <2FFBEA2D-98BF-4268-977C-4A4B38664B08@cs.purdue.edu> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> <2FFBEA2D-98BF-4268-977C-4A4B38664B08@cs.purdue.edu> Message-ID: I /think/ cm3/quake exposes the integer but I'll try to peek around, and at the other clients, and my own uses of try_exec/q_exec. There is /some/ validity to a "rich" exit code, more than 1 bit, but I realize it is controversial. Windows has a 32 bit exit code. Perl on Windows truncates it to 8 bits. When a process exits with a negative exit code, Perl on Windows gets confused and issues a strange error or runs it a second time (as if negative means CreateProcess failed, for a possible reason that the path was wrong.) - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Wed, 14 Jan 2009 12:49:41 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3 The current hack is not so bad, I suppose. I would prefer to come up with a solution that simply defines Process.Wait and System.Wait as returning a BOOLEAN indicating if the process terminated successfully or not. Are there any clients of these procedures that decode the bits in any more detail than simply testing non-zero? On 14 Jan 2009, at 11:09, Jay wrote: > Sounds like your upgrade script Based on someone else's upgrade.sh. > The alternative is to fold sysutils into m3core, where it can be used directly Merging sysutils into m3core doesn't quite work, again only or due to bootstrapping from older builds. The compiler uses sysutils. Older builds don't have it at all, and can't build m3core...but maybe again, make that hand patch Long.Rep = INTEGER? Or have an up to date compiler. Pointless statement I'm making though, it devolves to: - have an up to date m3core in bootstrap - or have sysutils in bootstrap, which implies up to date m3core - or merge sysutils with m3core, which implies up to date m3core (and the second) => "have an up to date m3core" (and LONGINT capable compiler) And I think merging them is a fine idea.I generally like fewer larger pieces of reusable code, thoughthe counterpoint is to have more smaller independently changable pieces. Probably the scripts and/or m3makefiles should probe the compiler version and/or m3core version and/or sysutils presence and error clearly if it is too old/absent. Possibly some "feature detection" feature is needed. The compiler can just define Quake variables willy/nilly. if defined("HAS_LONGINT") Less clear how to probe m3core capability. Can try compiling a little program against the old WaitProcess signature. I'm leary of anything that resembles autoconf though (though I have autoconf-ish stuff in my config files already, probing some cm3cg and cm3 behavior). Oh...I looked at WaitProcess history. It looks like I introduced it, in 2008. So..while it never returned the full status word, there also wasn't much history to change. Compiler could expose m3core functionality via variables too, though that..is wrong. It could only expose the m3core it is linked to, not the one it is building. I guess the only way really is to define a version or date constant and folks can write constant expressions based on it, though that doesn't get you very far. Less clear how to correctly probe for package existance. Easy to do ad-hoc by probing package store files, not sure what is the right way. I also want to try this "import_pkg" directive I see in the docs. It might help a lot here, if I understand it, and if it actually exists and resembles the doc I read. It sounds like it recompiles a package's source as part of another package, statically linking it. It would be bloating in the absence of build_standalone(), but not in its presence. > No! I did not want to do have this hack Are the hacks this time in sysutils really so bad? m3core is left unadulterated. sysutils assumes waitpid(0) won't deadlock, which is true of kernel threads and cm3's use. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Wed, 14 Jan 2009 10:11:36 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3 On 14 Jan 2009, at 01:54, Jay wrote: > fix for old compilers that can't compile LONGINT: define LongRep.T = INTEGERIs that what bootstrapping should do? Automate that little patch for the first pass and undo it in the second? Then always building in dependency order? I would prefer to get all the bootstrap archives LONGINT-capable. Just do the patch by hand to build the initial archives and then forget about it. Tonight I was trying to build from PPC_DARWIN 5.5.0.I figured, heck, maybe it supports LONGINT already, maybe I should just trybuilding up in dependency order.But then I hit the problem of Compiler.i3 mismatch due to new targets. So...is that correct?Does building in dependency order predictably fail if compiler has fewer targets than runtime?But starting with existing m3core/libm3 and first building the compiler against them predictably works? Yes, it works. I've added targets a bunch and usually don't have a problem, but I can't say for certain whatorder I do things when I do this.Certainly "upgrade.py skipgcc" is something I run fairly often.It is very fast on NT386 (and unlike upgrade.sh, it doesn't build all of std). Sounds like your upgrade script For now I put in two small hacks to sysutils, so it works with old m3core. No! I did not want to do have this hack. Let's just fix the boot archives to handle new m3core and have sysutils work as expected. The alternative is to fold sysutils into m3core, where it can be used directly. That might be a better solution given the dependency. Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jan 14 03:57:51 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 14 Jan 2009 02:57:51 +0000 Subject: [M3devel] building all platforms regularly? Message-ID: Hi. On my system I can cd m3-sys/m3cc cm3 -DM3CC_TARGET=platform cd scripts/python ./do-cm3-all.py realclean skipgcc ./do-cm3-std.py platform boot skipgcc ./boot1.py platform and for pretty much "any" platform it pretty much works. Ok, on a 32bit host with a 64bit target, there is an error in JV.i3 or such because, like TextLiteralF.i3, there is a declaration of a maximally sized integer. This is an easy to fix compiler bug, soon. Ratchet it down to just "min" and it works more, since JV.i3 isn't there. The result of this is a .tar.gz containing assembly source for all the Modula-3 code, some .h and .c files, and a Makefile and alternate make.sh. One can takes this to the target system, with a C development environment, and finish the build, giving you a current cm3, which you can then use to build cm3cg, and so on. (Some source files are also in the archive and updatesource.sh, but that's not relevant to this email; they are typically edited files when doing a new port.) So, my point is, maybe this should be run kind of like the Tinderboxes? Spitting out current archives of all "active" platforms, regularly? It is not as "good" as the Tinderbox. There might still be errors in the C, link errors, test failures. But it is pretty good. It gets a bit more testing across platforms and provides a good up to date start. And then, the list of "active" targets needs to be identified. Oh, I forgot to mention, this only currently works for platforms for which there is m3-sys/cminstall/src/config-no-install/platform, and NT386. The others give an error about not liking the "unconfigured" config files in the neighboring config directory. Also, the .tar.gz is presently put at the root, which isn't right. It works ok on Windows. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jan 14 05:16:43 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 14 Jan 2009 04:16:43 +0000 Subject: [M3devel] FW: building all platforms regularly? Message-ID: [was truncated] From: jayTo: m3develSubject: building all platforms regularly?Date: Wed, 14 Jan 2009 02:57:51 +0000 Hi. On my system I can cd m3-sys/m3cc cm3 -DM3CC_TARGET=platform cd scripts/python ./do-cm3-all.py realclean skipgcc ./do-cm3-std.py platform boot skipgcc ./boot1.py platform and for pretty much "any" platform it pretty much works.Ok, on a 32bit host with a 64bit target, there is an error in JV.i3 or such because,like TextLiteralF.i3, there is a declaration of a maximally sized integer.This is an easy to fix compiler bug, soon. Ratchet it down to just "min" and it works more, since JV.i3 isn't there. The result of this is a .tar.gz containing assembly source for all the Modula-3 code,some .h and .c files, and a Makefile and alternate make.sh.One can takes this to the target system, with a C development environment,and finish the build, giving you a current cm3, which you can then use to build cm3cg,and so on. (Some source files are also in the archive and updatesource.sh, but that'snot relevant to this email; they are typically edited files when doing a new port.) So, my point is, maybe this should be run kind of like the Tinderboxes?Spitting out current archives of all "active" platforms, regularly? It is not as "good" as the Tinderbox.There might still be errors in the C, link errors, test failures.But it is pretty good. It gets a bit more testing across platforms and provides a good up to date start. And then, the list of "active" targets needs to be identified. Oh, I forgot to mention, this only currently works for platforms for whichthere is m3-sys/cminstall/src/config-no-install/platform, and NT386.The others give an error about not liking the "unconfigured" config filesin the neighboring config directory. Also, the .tar.gz is presently put at the root, which isn't right.It works ok on Windows. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jan 14 07:53:08 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 14 Jan 2009 06:53:08 +0000 Subject: [M3devel] building all platforms regularly? Message-ID: On the other hand, this is increasingly redundant, what with the increased portability in the system and coming to the system :). And increasingly insufficient, since it doesn't test compilability of the C code. - Jay From: jay.krell at cornell.eduTo: m3devel at elegosoft.comSubject: FW: building all platforms regularly?Date: Wed, 14 Jan 2009 04:16:43 +0000 [was truncated] From: jayTo: m3develSubject: building all platforms regularly?Date: Wed, 14 Jan 2009 02:57:51 +0000 Hi. On my system I can cd m3-sys/m3cc cm3 -DM3CC_TARGET=platform cd scripts/python ./do-cm3-all.py realclean skipgcc ./do-cm3-std.py platform boot skipgcc ./boot1.py platform and for pretty much "any" platform it pretty much works.Ok, on a 32bit host with a 64bit target, there is an error in JV.i3 or such because,like TextLiteralF.i3, there is a declaration of a maximally sized integer.This is an easy to fix compiler bug, soon. Ratchet it down to just "min" and it works more, since JV.i3 isn't there. The result of this is a .tar.gz containing assembly source for all the Modula-3 code,some .h and .c files, and a Makefile and alternate make.sh.One can takes this to the target system, with a C development environment,and finish the build, giving you a current cm3, which you can then use to build cm3cg,and so on. (Some source files are also in the archive and updatesource.sh, but that'snot relevant to this email; they are typically edited files when doing a new port.) So, my point is, maybe this should be run kind of like the Tinderboxes?Spitting out current archives of all "active" platforms, regularly? It is not as "good" as the Tinderbox.There might still be errors in the C, link errors, test failures.But it is pretty good. It gets a bit more testing across platforms and provides a good up to date start. And then, the list of "active" targets needs to be identified. Oh, I forgot to mention, this only currently works for platforms for whichthere is m3-sys/cminstall/src/config-no-install/platform, and NT386.The others give an error about not liking the "unconfigured" config filesin the neighboring config directory. Also, the .tar.gz is presently put at the root, which isn't right.It works ok on Windows. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jan 14 10:14:19 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 14 Jan 2009 09:14:19 +0000 Subject: [M3devel] how to switch between user and kernel threads.. Message-ID: Are people really against using function pointers for this? Either changing the interface to have function pointer variables (I'm not sure Modula-3 allows this, but in C you can fairly transparently replace functions with function pointers; client code just keeps working; it breaks down in C++ with overloading), or having a set of functions that just call/jump through function pointers? There would be no if, no conditional branches. Dynamic linking on Windows always goes through function pointers already. So while yes it adds another instruction, it is already never getting inlined. Don't other platforms do that too? Or they patch every call site? I'm not sure otherwise of a simple method. Easiest might be to have a parallel directory structure to m3core, with just m3core files. That would wastefully rebuild all of m3core a second time, for just a small amount of variation. I think function pointers are the way to go here. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 14 11:31:22 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 14 Jan 2009 21:31:22 +1100 Subject: [M3devel] how to switch between user and kernel threads.. In-Reply-To: References: Message-ID: I don't want dynamic switching. A link-time switch is just fine. Also, please don't go messing about with this right now -- I have changes pending for the threads system that will be harder to integrate if you change with it further. On 14 Jan 2009, at 20:14, Jay wrote: > Are people really against using function pointers for this? > Either changing the interface to have function pointer variables > (I'm not sure Modula-3 allows this, but in C you can fairly > transparently replace functions with function pointers; client code > just keeps working; it breaks down in C++ with overloading), or > having a set of functions that just call/jump through function > pointers? There would be no if, no conditional branches. > > Dynamic linking on Windows always goes through function pointers > already. > So while yes it adds another instruction, it is already never > getting inlined. > Don't other platforms do that too? > Or they patch every call site? > > I'm not sure otherwise of a simple method. > Easiest might be to have a parallel directory structure to m3core, > with just m3core files. > That would wastefully rebuild all of m3core a second time, for just > a small amount of variation. > > I think function pointers are the way to go here. > > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jan 14 22:30:59 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 14 Jan 2009 21:30:59 +0000 Subject: [M3devel] how to switch between user and kernel threads.. In-Reply-To: References: Message-ID: I'll wait. So, build two different m3core.lib/a/so/dylib? m3core and m3coreuserthreads Compile both thread directories, if the platform supports it, and call quake make_lib twice with slightly different parameters? An m3core specific hack in the config file or cm3? Easy enough in the config file. Very m3core specific. I suppose you could argue that quake isn't a generic build system, but it is Modula-3's build system, and that m3core is really special. The result btw, would likely be no change at all to any *.i3 or *.m3 file. I still think function pointers are the way to go. Even with function pointers, the changes to *.i3 and *.m3 would be very minor. Just the export list would vary. And new *.i3 files introduced. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Wed, 14 Jan 2009 21:31:22 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] how to switch between user and kernel threads..I don't want dynamic switching. A link-time switch is just fine. Also, please don't go messing about with this right now -- I have changes pending for the threads system that will be harder to integrate if you change with it further. On 14 Jan 2009, at 20:14, Jay wrote: Are people really against using function pointers for this?Either changing the interface to have function pointer variables (I'm not sure Modula-3 allows this, but in C you can fairly transparently replace functions with function pointers; client code just keeps working; it breaks down in C++ with overloading), or having a set of functions that just call/jump through function pointers? There would be no if, no conditional branches. Dynamic linking on Windows always goes through function pointers already. So while yes it adds another instruction, it is already never getting inlined.Don't other platforms do that too?Or they patch every call site? I'm not sure otherwise of a simple method.Easiest might be to have a parallel directory structure to m3core, with just m3core files.That would wastefully rebuild all of m3core a second time, for just a small amount of variation. I think function pointers are the way to go here. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jan 14 22:34:20 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 14 Jan 2009 21:34:20 +0000 Subject: [M3devel] FW: how to switch between user and kernel threads.. In-Reply-To: References: Message-ID: [truncated again] From: jayTo: hoskingCC: m3develSubject: RE: [M3devel] how to switch between user and kernel threads..Date: Wed, 14 Jan 2009 21:30:59 +0000 I'll wait.So, build two different m3core.lib/a/so/dylib?m3core and m3coreuserthreads Compile both thread directories, if the platform supports it, andcall quake make_lib twice with slightly different parameters?An m3core specific hack in the config file or cm3?Easy enough in the config file.Very m3core specific.I suppose you could argue that quake isn't a generic build system,but it is Modula-3's build system, and that m3core is really special. The result btw, would likely be no change at all to any *.i3 or *.m3 file. I still think function pointers are the way to go.Even with function pointers, the changes to *.i3 and *.m3 would be very minor.Just the export list would vary.And new *.i3 files introduced. - Jay From: hoskingTo: jayDate: Wed, 14 Jan 2009 21:31:22 +1100CC: m3deveSubject: Re: [M3devel] how to switch between user and kernel threads..I don't want dynamic switching. A link-time switch is just fine. Also, please don't go messing about with this right now -- I have changes pending for the threads system that will be harder to integrate if you change with it further. On 14 Jan 2009, at 20:14, Jay wrote: Are people really against using function pointers for this?Either changing the interface to have function pointer variables (I'm not sure Modula-3 allows this, but in C you can fairly transparently replace functions with function pointers; client code just keeps working; it breaks down in C++ with overloading), or having a set of functions that just call/jump through function pointers? There would be no if, no conditional branches. Dynamic linking on Windows always goes through function pointers already. So while yes it adds another instruction, it is already never getting inlined.Don't other platforms do that too?Or they patch every call site? I'm not sure otherwise of a simple method.Easiest might be to have a parallel directory structure to m3core, with just m3core files.That would wastefully rebuild all of m3core a second time, for just a small amount of variation. I think function pointers are the way to go here. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jan 15 01:31:17 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 15 Jan 2009 11:31:17 +1100 Subject: [M3devel] how to switch between user and kernel threads.. In-Reply-To: References: Message-ID: <56CF4A94-6620-4A69-B4DC-D72268811AEA@cs.purdue.edu> No function pointers please. Let the installer decide whether to use native or user threads. On 15 Jan 2009, at 08:30, Jay wrote: > I'll wait. > So, build two different m3core.lib/a/so/dylib? > m3core and m3coreuserthreads > > Compile both thread directories, if the platform supports it, and > call quake make_lib twice with slightly different parameters? > An m3core specific hack in the config file or cm3? > Easy enough in the config file. > Very m3core specific. > I suppose you could argue that quake isn't a generic build system, > but it is Modula-3's build system, and that m3core is really special. > > The result btw, would likely be no change at all to any *.i3 or *.m3 > file. > > I still think function pointers are the way to go. > Even with function pointers, the changes to *.i3 and *.m3 would be > very minor. > Just the export list would vary. > And new *.i3 files introduced. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Wed, 14 Jan 2009 21:31:22 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] how to switch between user and kernel threads.. > > I don't want dynamic switching. A link-time switch is just fine. > > Also, please don't go messing about with this right now -- I have > changes pending for the threads system that will be harder to > integrate if you change with it further. > > On 14 Jan 2009, at 20:14, Jay wrote: > > Are people really against using function pointers for this? > Either changing the interface to have function pointer variables > (I'm not sure Modula-3 allows this, but in C you can fairly > transparently replace functions with function pointers; client code > just keeps working; it breaks down in C++ with overloading), or > having a set of functions that just call/jump through function > pointers? There would be no if, no conditional branches. > > Dynamic linking on Windows always goes through function pointers > already. > So while yes it adds another instruction, it is already never > getting inlined. > Don't other platforms do that too? > Or they patch every call site? > > I'm not sure otherwise of a simple method. > Easiest might be to have a parallel directory structure to m3core, > with just m3core files. > That would wastefully rebuild all of m3core a second time, for just > a small amount of variation. > > I think function pointers are the way to go here. > > - Jay > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 15 04:03:23 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 15 Jan 2009 03:03:23 +0000 Subject: [M3devel] how to switch between user and kernel threads.. In-Reply-To: <56CF4A94-6620-4A69-B4DC-D72268811AEA@cs.purdue.edu> References: <56CF4A94-6620-4A69-B4DC-D72268811AEA@cs.purdue.edu> Message-ID: The installer? I thought the granularity was at the time of linking an executable. I personally thought a command line parameter would be reasonable. Why not function pointers? It is a simple straightforward method to implement. It should add one instruction per call. It does reduce inlinability but I'm sure we aren't getting any such such inlinability anyway. Dynamic linking already kills inlinability, as does separate compilation of modules in most systems. I'm not sure how the types work out in such a scheme, but probably assuming Thread.T is already a reference type, it can become ADDRESS and then loopholed to ThreadPosix.T or ThreadPThread.T. Function pointers are also the easiest method to build. I'm not sure what the others are. I can try making m3-libs/m3coreuserthreads that contains only m3makefiles. Probably it can say: LibraryName = "m3coreuserthreads" include_dir("../m3core/m3makefile") and m3core/m3makefile can say if not defined("LibraryName") LibraryName = "m3core" end Library(LibraryName) If that works, not bad. And then cm3 or the config file can translate m3core to m3coreuserthreads at some point. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Thu, 15 Jan 2009 11:31:17 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] how to switch between user and kernel threads.. No function pointers please. Let the installer decide whether to use native or user threads. On 15 Jan 2009, at 08:30, Jay wrote: I'll wait.So, build two different m3core.lib/a/so/dylib?m3core and m3coreuserthreads Compile both thread directories, if the platform supports it, andcall quake make_lib twice with slightly different parameters?An m3core specific hack in the config file or cm3?Easy enough in the config file.Very m3core specific.I suppose you could argue that quake isn't a generic build system,but it is Modula-3's build system, and that m3core is really special. The result btw, would likely be no change at all to any *.i3 or *.m3 file. I still think function pointers are the way to go.Even with function pointers, the changes to *.i3 and *.m3 would be very minor.Just the export list would vary.And new *.i3 files introduced. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Wed, 14 Jan 2009 21:31:22 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] how to switch between user and kernel threads..I don't want dynamic switching. A link-time switch is just fine. Also, please don't go messing about with this right now -- I have changes pending for the threads system that will be harder to integrate if you change with it further. On 14 Jan 2009, at 20:14, Jay wrote: Are people really against using function pointers for this?Either changing the interface to have function pointer variables (I'm not sure Modula-3 allows this, but in C you can fairly transparently replace functions with function pointers; client code just keeps working; it breaks down in C++ with overloading), or having a set of functions that just call/jump through function pointers? There would be no if, no conditional branches. Dynamic linking on Windows always goes through function pointers already. So while yes it adds another instruction, it is already never getting inlined.Don't other platforms do that too?Or they patch every call site? I'm not sure otherwise of a simple method.Easiest might be to have a parallel directory structure to m3core, with just m3core files.That would wastefully rebuild all of m3core a second time, for just a small amount of variation. I think function pointers are the way to go here. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jan 15 04:18:16 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 15 Jan 2009 14:18:16 +1100 Subject: [M3devel] how to switch between user and kernel threads.. In-Reply-To: References: <56CF4A94-6620-4A69-B4DC-D72268811AEA@cs.purdue.edu> Message-ID: We do get inlining within modules by virtue of the gcc-backend at -O3. On 15 Jan 2009, at 14:03, Jay wrote: > The installer? > I thought the granularity was at the time of linking an executable. > I personally thought a command line parameter would be reasonable. > > > Why not function pointers? > It is a simple straightforward method to implement. > It should add one instruction per call. > It does reduce inlinability but I'm sure we aren't getting any such > such inlinability anyway. > Dynamic linking already kills inlinability, as does separate > compilation of modules in most systems. > > > I'm not sure how the types work out in such a scheme, but probably > assuming Thread.T is already a reference type, it can become ADDRESS > and then loopholed to ThreadPosix.T or ThreadPThread.T. > > > Function pointers are also the easiest method to build. I'm not sure > what the others are. > I can try making m3-libs/m3coreuserthreads that contains only > m3makefiles. > Probably it can say: > LibraryName = "m3coreuserthreads" > include_dir("../m3core/m3makefile") > > > and m3core/m3makefile can say > if not defined("LibraryName") > LibraryName = "m3core" > end > Library(LibraryName) > > > If that works, not bad. > > > And then cm3 or the config file can translate m3core to > m3coreuserthreads at some point. > > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Thu, 15 Jan 2009 11:31:17 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] how to switch between user and kernel threads.. > > > No function pointers please. Let the installer decide whether to > use native or user threads. > > On 15 Jan 2009, at 08:30, Jay wrote: > > I'll wait. > So, build two different m3core.lib/a/so/dylib? > m3core and m3coreuserthreads > > Compile both thread directories, if the platform supports it, and > call quake make_lib twice with slightly different parameters? > An m3core specific hack in the config file or cm3? > Easy enough in the config file. > Very m3core specific. > I suppose you could argue that quake isn't a generic build system, > but it is Modula-3's build system, and that m3core is really special. > > The result btw, would likely be no change at all to any *.i3 or *.m3 > file. > > I still think function pointers are the way to go. > Even with function pointers, the changes to *.i3 and *.m3 would be > very minor. > Just the export list would vary. > And new *.i3 files introduced. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Wed, 14 Jan 2009 21:31:22 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] how to switch between user and kernel threads.. > > I don't want dynamic switching. A link-time switch is just fine. > > Also, please don't go messing about with this right now -- I have > changes pending for the threads system that will be harder to > integrate if you change with it further. > > On 14 Jan 2009, at 20:14, Jay wrote: > > Are people really against using function pointers for this? > Either changing the interface to have function pointer variables > (I'm not sure Modula-3 allows this, but in C you can fairly > transparently replace functions with function pointers; client code > just keeps working; it breaks down in C++ with overloading), or > having a set of functions that just call/jump through function > pointers? There would be no if, no conditional branches. > > Dynamic linking on Windows always goes through function pointers > already. > So while yes it adds another instruction, it is already never > getting inlined. > Don't other platforms do that too? > Or they patch every call site? > > I'm not sure otherwise of a simple method. > Easiest might be to have a parallel directory structure to m3core, > with just m3core files. > That would wastefully rebuild all of m3core a second time, for just > a small amount of variation. > > I think function pointers are the way to go here. > > - Jay > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 15 05:15:43 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 15 Jan 2009 04:15:43 +0000 Subject: [M3devel] how to switch between user and kernel threads.. In-Reply-To: References: <56CF4A94-6620-4A69-B4DC-D72268811AEA@cs.purdue.edu> Message-ID: That would't affected here. All the calls within ThreadPThread to within ThreadPThread would remain direct and inlinable. They would be to the "ThreadPThread" interface, and not the "Thread" interface, would be my intent. How about across modules? I expect any call from outside ThreadPThread to within ThreadPThread to never be inlined, at least not when dynamic linking and with static linking (or within the package/library) not unless there is "whole program optimization" aka "link time code generation" with static linking, which does exist out there. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Thu, 15 Jan 2009 14:18:16 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] how to switch between user and kernel threads..We do get inlining within modules by virtue of the gcc-backend at -O3. On 15 Jan 2009, at 14:03, Jay wrote: The installer?I thought the granularity was at the time of linking an executable.I personally thought a command line parameter would be reasonable. Why not function pointers?It is a simple straightforward method to implement.It should add one instruction per call.It does reduce inlinability but I'm sure we aren't getting any such such inlinability anyway.Dynamic linking already kills inlinability, as does separate compilation of modules in most systems. I'm not sure how the types work out in such a scheme, but probably assuming Thread.T is already a reference type, it can become ADDRESS and then loopholed to ThreadPosix.T or ThreadPThread.T. Function pointers are also the easiest method to build. I'm not sure what the others are.I can try making m3-libs/m3coreuserthreads that contains only m3makefiles.Probably it can say:LibraryName = "m3coreuserthreads"include_dir("../m3core/m3makefile") and m3core/m3makefile can sayif not defined("LibraryName") LibraryName = "m3core"endLibrary(LibraryName) If that works, not bad. And then cm3 or the config file can translate m3core to m3coreuserthreads at some point. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Thu, 15 Jan 2009 11:31:17 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] how to switch between user and kernel threads.. No function pointers please. Let the installer decide whether to use native or user threads. On 15 Jan 2009, at 08:30, Jay wrote: I'll wait.So, build two different m3core.lib/a/so/dylib?m3core and m3coreuserthreads Compile both thread directories, if the platform supports it, andcall quake make_lib twice with slightly different parameters?An m3core specific hack in the config file or cm3?Easy enough in the config file.Very m3core specific.I suppose you could argue that quake isn't a generic build system,but it is Modula-3's build system, and that m3core is really special. The result btw, would likely be no change at all to any *.i3 or *.m3 file. I still think function pointers are the way to go.Even with function pointers, the changes to *.i3 and *.m3 would be very minor.Just the export list would vary.And new *.i3 files introduced. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Wed, 14 Jan 2009 21:31:22 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] how to switch between user and kernel threads..I don't want dynamic switching. A link-time switch is just fine. Also, please don't go messing about with this right now -- I have changes pending for the threads system that will be harder to integrate if you change with it further. On 14 Jan 2009, at 20:14, Jay wrote: Are people really against using function pointers for this?Either changing the interface to have function pointer variables (I'm not sure Modula-3 allows this, but in C you can fairly transparently replace functions with function pointers; client code just keeps working; it breaks down in C++ with overloading), or having a set of functions that just call/jump through function pointers? There would be no if, no conditional branches. Dynamic linking on Windows always goes through function pointers already. So while yes it adds another instruction, it is already never getting inlined.Don't other platforms do that too?Or they patch every call site? I'm not sure otherwise of a simple method.Easiest might be to have a parallel directory structure to m3core, with just m3core files.That would wastefully rebuild all of m3core a second time, for just a small amount of variation. I think function pointers are the way to go here. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinbishop at bellsouth.net Fri Jan 16 03:25:04 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Thu, 15 Jan 2009 20:25:04 -0600 Subject: [M3devel] Percent to REAL? Message-ID: <496FF000.1030506@bellsouth.net> I'm feeling silly, but I need to convert a percentage (stored as an INTEGER) into a REAL, so I tried FLOAT(num) / 100.0 but that doesn't work. I tried using FLOAT(num DIV 100) but that doesn't work either. I also tried FLOAT(num MOD 100) just to try everything, and that didn't work either. How can I convert a percentage into a REAL? For example, 70% -> 0.70 From rcoleburn at scires.com Fri Jan 16 03:47:54 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 15 Jan 2009 21:47:54 -0500 Subject: [M3devel] Percent to REAL? In-Reply-To: <496FF000.1030506@bellsouth.net> References: <496FF000.1030506@bellsouth.net> Message-ID: <496FAE9F.1E75.00D7.1@scires.com> Martin: The following works for me: VAR i: INTEGER; r: REAL; BEGIN i := 70; r := FLOAT(i) / 100.0; END; Regards, Randy >>> Martin Bishop 1/15/2009 9:25 PM >>> I'm feeling silly, but I need to convert a percentage (stored as an INTEGER) into a REAL, so I tried FLOAT(num) / 100.0 but that doesn't work. I tried using FLOAT(num DIV 100) but that doesn't work either. I also tried FLOAT(num MOD 100) just to try everything, and that didn't work either. How can I convert a percentage into a REAL? For example, 70% -> 0.70 -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinbishop at bellsouth.net Fri Jan 16 03:37:28 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Thu, 15 Jan 2009 20:37:28 -0600 Subject: [M3devel] Percent to REAL? In-Reply-To: <496FF000.1030506@bellsouth.net> References: <496FF000.1030506@bellsouth.net> Message-ID: <496FF2E8.5050801@bellsouth.net> Martin Bishop wrote: > I'm feeling silly, but I need to convert a percentage (stored as an > INTEGER) into a REAL, so I tried FLOAT(num) / 100.0 but that doesn't > work. I tried using FLOAT(num DIV 100) but that doesn't work either. I > also tried FLOAT(num MOD 100) just to try everything, and that didn't > work either. > > How can I convert a percentage into a REAL? For example, 70% -> 0.70 > Disregard that, I knew I was feeling silly, FLOAT(num) / 100.0 DOES work. From jay.krell at cornell.edu Fri Jan 16 10:28:46 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 16 Jan 2009 09:28:46 +0000 Subject: [M3devel] how to switch between user and kernel threads.. In-Reply-To: References: <56CF4A94-6620-4A69-B4DC-D72268811AEA@cs.purdue.edu> Message-ID: I was able to easily build this alternate library, just by creating one small m3makefile and optionally editing one other very little. I wasn't able to find a way to get it used, other than maybe shipping it on top of the "real" m3core. A compiler hack that knows to replace package "m3core" with "m3coreuserthreads" may be appropriate. I can look into that. But I still don't know why not function pointers. Plenty else to do in the meantime (Cygwin/pthreads, portability, a bunch of ports..). - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] how to switch between user and kernel threads..Date: Thu, 15 Jan 2009 04:15:43 +0000 That would't affected here. All the calls within ThreadPThread to within ThreadPThread would remain direct and inlinable. They would be to the "ThreadPThread" interface, and not the "Thread" interface, would be my intent. How about across modules? I expect any call from outside ThreadPThread to within ThreadPThread to never be inlined, at least not when dynamic linking and with static linking (or within the package/library) not unless there is "whole program optimization" aka "link time code generation" with static linking, which does exist out there. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Thu, 15 Jan 2009 14:18:16 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] how to switch between user and kernel threads..We do get inlining within modules by virtue of the gcc-backend at -O3. On 15 Jan 2009, at 14:03, Jay wrote: The installer?I thought the granularity was at the time of linking an executable.I personally thought a command line parameter would be reasonable. Why not function pointers?It is a simple straightforward method to implement.It should add one instruction per call.It does reduce inlinability but I'm sure we aren't getting any such such inlinability anyway.Dynamic linking already kills inlinability, as does separate compilation of modules in most systems. I'm not sure how the types work out in such a scheme, but probably assuming Thread.T is already a reference type, it can become ADDRESS and then loopholed to ThreadPosix.T or ThreadPThread.T. Function pointers are also the easiest method to build. I'm not sure what the others are.I can try making m3-libs/m3coreuserthreads that contains only m3makefiles.Probably it can say:LibraryName = "m3coreuserthreads"include_dir("../m3core/m3makefile") and m3core/m3makefile can sayif not defined("LibraryName") LibraryName = "m3core"endLibrary(LibraryName) If that works, not bad. And then cm3 or the config file can translate m3core to m3coreuserthreads at some point. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Thu, 15 Jan 2009 11:31:17 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] how to switch between user and kernel threads.. No function pointers please. Let the installer decide whether to use native or user threads. On 15 Jan 2009, at 08:30, Jay wrote: I'll wait.So, build two different m3core.lib/a/so/dylib?m3core and m3coreuserthreads Compile both thread directories, if the platform supports it, andcall quake make_lib twice with slightly different parameters?An m3core specific hack in the config file or cm3?Easy enough in the config file.Very m3core specific.I suppose you could argue that quake isn't a generic build system,but it is Modula-3's build system, and that m3core is really special. The result btw, would likely be no change at all to any *.i3 or *.m3 file. I still think function pointers are the way to go.Even with function pointers, the changes to *.i3 and *.m3 would be very minor.Just the export list would vary.And new *.i3 files introduced. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Wed, 14 Jan 2009 21:31:22 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] how to switch between user and kernel threads..I don't want dynamic switching. A link-time switch is just fine. Also, please don't go messing about with this right now -- I have changes pending for the threads system that will be harder to integrate if you change with it further. On 14 Jan 2009, at 20:14, Jay wrote: Are people really against using function pointers for this?Either changing the interface to have function pointer variables (I'm not sure Modula-3 allows this, but in C you can fairly transparently replace functions with function pointers; client code just keeps working; it breaks down in C++ with overloading), or having a set of functions that just call/jump through function pointers? There would be no if, no conditional branches. Dynamic linking on Windows always goes through function pointers already. So while yes it adds another instruction, it is already never getting inlined.Don't other platforms do that too?Or they patch every call site? I'm not sure otherwise of a simple method.Easiest might be to have a parallel directory structure to m3core, with just m3core files.That would wastefully rebuild all of m3core a second time, for just a small amount of variation. I think function pointers are the way to go here. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jan 16 14:05:17 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 16 Jan 2009 13:05:17 +0000 Subject: [M3devel] "new old" ports, or no ports at all? Message-ID: Would people mind "new" ports like: HPPA32_HPUX (HPPA_HPUX? There is "HPPA")I386_FREEBSD (There is FreeBSD4.)I386_NETBSD (There is NetBSD2_i386.)MIPS32_IRIX (MIPS_IRIX? There is IRIX5.)ALPHA_FREEBSD (There FBSD_ALPHA.) and then for that matter:SPARC32_SOLARIS, I386_LINUX Or some mix?This is not hypothetical. I do now have HPPA, Alpha, SGI hardware. :) I can either do the little bit of correct testable valid small etc. work of using my "more portable" approach to these platforms, which gets things up and running easily and fast and perfectly acceptably, or I could "proofread" all the gunk, I mean cloned headers, fix them for current system, worry if they break old system, or delete them, possibly doing some hypothetical damage to the old ports. It seems easier and a better result to "start over" and leave the old stuff alone, maybe delete it, depending on what people think of history preservation and history vs. deletes (deleted stuff isn't very visible). Or maybe hardly any of this matters. Nobody uses these platforms or anything like them? (I recall Randy saying he is still using 4.1 on HP-UX though. I'm on a fun little long running errand here of getting not ancient but not current systems.. :) ) The "4", "2", "5" in FreeBSD4, NetBSD2_i386, IRIX5 make them seen somewhat "wrong". The "4" in FreeBSD4 (err, in i686-freebsd4) does have a surprising semantic, in the backend..but maybe not. C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(53): builtin_define_with_int_value ("__FreeBSD__", FBSD_MAJOR); \ C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(122):#if FBSD_MAJOR < 5 C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(141):#if FBSD_MAJOR < 6 though I think if you look closely, these don't matter to us.They affect the gcc driver and the C/C++ front end, but maybe not the m3cg backend. Even the "LIBC6" in "LINUXLIBC6" seems dubious, because, for example, I amtempted to make "ARM_LINUX_UCLIBC", which suggests either thatthere might be an "I386_LINUX_UCLIBC" or "generic" "I386_LINUX" thatis portable across libc6/uclibc/dietlibc/newlib either by seeingwhat they have in common, or skipping them and using the kernel interfacesmore directly. There is another angle here.To what extent is the compiler platform specific? (I mostly know the answer to this. It is a leading question.)Could ports go away?Almost? Historically there were a bunch of platform-specific .i3 files.That is dwindling much in some platforms and could dwindle much overall.A little more C code in the system and the Modula-3 .i3 files are all "portable". It ends up being, roughly, that there is: endian, and even this is often not an issue; I saw like one reference in the compiler to it, and there is a little bit in m3core/libm3 The byte swap functions and maybe the Float stuff (there is endian specific and generic stuff, not all is used). It would affect e.g. the layout of the Uexec types, but they are gone. Such endian-specificity could occur anywhere but maybe "cm3 -generic" errors for it? word size -- 32bit or 64bit. There is no escaping this, as long as there are any 32bit platforms. So ok, two ports, 32bit and 64bit. That's a small matrix. IEEE or not -- everything is IEEE now. I don't plan on getting a VAX. :) (The compiler seems suspicious here wrt cross building.) The name of setjmp. However this could be made the same everywhere -- m3_setjmp or M3Try or M3SaveState, and use an #ifdef .c file to decide. The size of the jmpbuf. Ah, there's the rub. A "generic" platform could blow up the size of the jmpbuf to something that works on all known platforms. Very very wasteful. Some platforms have tiny, some have huge. I'm not sure where stack layout is done. If the front end does it or not. You could imagine something like M3Try allocating the same..but this seems bad. If the front end defers enough work to the backend, you could introduce an abstracted notion of the jmpbuf and leave it to m3cg to fill in? Leave it to #ifdef on the target? m3cg, in its current form as gcc based is always going to have be configured to be target specific. Or all platforms could have stack walkers and this platform-specificity would go away. But that is a very long ways off, if ever. My point is, you know, can we in fact eliminate the notion of porting? At least of cm3 knowing anything about the target, and only m3cg? Because the system is nearly portable enough? All that is left is configuring gcc? It seems very close to possible. Like, "have gcc, will travel"?And nothing else changes?No value then in doing any porting work up front? You know..think of the author of hello world..some highly portable program. Or more realistic example such as bash, awk, make, ld and gcc on a particular host (not target), etc.They don't go around much and port to this or that or the other system. They do a mix of "just try to be portable" and "leave autoconf to figure out". Modula-3 is almost in the same boat? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Jan 16 17:04:53 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 16 Jan 2009 11:04:53 -0500 Subject: [M3devel] "new old" ports, or no ports at all? In-Reply-To: References: Message-ID: <49706962.1E75.00D7.1@scires.com> Jay: I do have some HP-UX machines that I could use to test whatever you come up with for HPPA. You are correct that right now I run cm3 v4.1 on these. I have not tried to move beyond 4.1 on them yet. Regards, Randy >>> Jay 1/16/2009 8:05 AM >>> Would people mind "new" ports like: HPPA32_HPUX (HPPA_HPUX? There is "HPPA") I386_FREEBSD (There is FreeBSD4.) I386_NETBSD (There is NetBSD2_i386.) MIPS32_IRIX (MIPS_IRIX? There is IRIX5.) ALPHA_FREEBSD (There FBSD_ALPHA.) and then for that matter: SPARC32_SOLARIS, I386_LINUX Or some mix? This is not hypothetical. I do now have HPPA, Alpha, SGI hardware. :) I can either do the little bit of correct testable valid small etc. work of using my "more portable" approach to these platforms, which gets things up and running easily and fast and perfectly acceptably, or I could "proofread" all the gunk, I mean cloned headers, fix them for current system, worry if they break old system, or delete them, possibly doing some hypothetical damage to the old ports. It seems easier and a better result to "start over" and leave the old stuff alone, maybe delete it, depending on what people think of history preservation and history vs. deletes (deleted stuff isn't very visible). Or maybe hardly any of this matters. Nobody uses these platforms or anything like them? (I recall Randy saying he is still using 4.1 on HP-UX though. I'm on a fun little long running errand here of getting not ancient but not current systems.. :) ) The "4", "2", "5" in FreeBSD4, NetBSD2_i386, IRIX5 make them seen somewhat "wrong". The "4" in FreeBSD4 (err, in i686-freebsd4) does have a surprising semantic, in the backend..but maybe not. C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(53): builtin_define_with_int_value ("__FreeBSD__", FBSD_MAJOR); \ C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(122):#if FBSD_MAJOR < 5 C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(141):#if FBSD_MAJOR < 6 though I think if you look closely, these don't matter to us. They affect the gcc driver and the C/C++ front end, but maybe not the m3cg backend. Even the "LIBC6" in "LINUXLIBC6" seems dubious, because, for example, I am tempted to make "ARM_LINUX_UCLIBC", which suggests either that there might be an "I386_LINUX_UCLIBC" or "generic" "I386_LINUX" that is portable across libc6/uclibc/dietlibc/newlib either by seeing what they have in common, or skipping them and using the kernel interfaces more directly. There is another angle here. To what extent is the compiler platform specific? (I mostly know the answer to this. It is a leading question.) Could ports go away? Almost? Historically there were a bunch of platform-specific .i3 files. That is dwindling much in some platforms and could dwindle much overall. A little more C code in the system and the Modula-3 .i3 files are all "portable". It ends up being, roughly, that there is: endian, and even this is often not an issue; I saw like one reference in the compiler to it, and there is a little bit in m3core/libm3 The byte swap functions and maybe the Float stuff (there is endian specific and generic stuff, not all is used). It would affect e.g. the layout of the Uexec types, but they are gone. Such endian-specificity could occur anywhere but maybe "cm3 -generic" errors for it? word size -- 32bit or 64bit. There is no escaping this, as long as there are any 32bit platforms. So ok, two ports, 32bit and 64bit. That's a small matrix. IEEE or not -- everything is IEEE now. I don't plan on getting a VAX. :) (The compiler seems suspicious here wrt cross building.) The name of setjmp. However this could be made the same everywhere -- m3_setjmp or M3Try or M3SaveState, and use an #ifdef .c file to decide. The size of the jmpbuf. Ah, there's the rub. A "generic" platform could blow up the size of the jmpbuf to something that works on all known platforms. Very very wasteful. Some platforms have tiny, some have huge. I'm not sure where stack layout is done. If the front end does it or not. You could imagine something like M3Try allocating the same..but this seems bad. If the front end defers enough work to the backend, you could introduce an abstracted notion of the jmpbuf and leave it to m3cg to fill in? Leave it to #ifdef on the target? m3cg, in its current form as gcc based is always going to have be configured to be target specific. Or all platforms could have stack walkers and this platform-specificity would go away. But that is a very long ways off, if ever. My point is, you know, can we in fact eliminate the notion of porting? At least of cm3 knowing anything about the target, and only m3cg? Because the system is nearly portable enough? All that is left is configuring gcc? It seems very close to possible. Like, "have gcc, will travel"? And nothing else changes? No value then in doing any porting work up front? You know..think of the author of hello world..some highly portable program. Or more realistic example such as bash, awk, make, ld and gcc on a particular host (not target), etc. They don't go around much and port to this or that or the other system. They do a mix of "just try to be portable" and "leave autoconf to figure out". Modula-3 is almost in the same boat? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Jan 17 05:06:18 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 17 Jan 2009 15:06:18 +1100 Subject: [M3devel] how to switch between user and kernel threads.. In-Reply-To: References: <56CF4A94-6620-4A69-B4DC-D72268811AEA@cs.purdue.edu> Message-ID: Please leave it the way it is as an install-time option. -DNOPTHREAD enables user threads. On 16 Jan 2009, at 20:28, Jay wrote: > I was able to easily build this alternate library, just by creating > one small m3makefile and optionally editing one other very little. > I wasn't able to find a way to get it used, other than maybe > shipping it on top of the "real" m3core. > A compiler hack that knows to replace package "m3core" with > "m3coreuserthreads" may be appropriate. > I can look into that. > But I still don't know why not function pointers. > Plenty else to do in the meantime (Cygwin/pthreads, portability, a > bunch of ports..). > > - Jay > > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] how to switch between user and kernel threads.. > Date: Thu, 15 Jan 2009 04:15:43 +0000 > > That would't affected here. > All the calls within ThreadPThread to within ThreadPThread would > remain direct and inlinable. > They would be to the "ThreadPThread" interface, and not the > "Thread" interface, would be my intent. > > How about across modules? > I expect any call from outside ThreadPThread to within > ThreadPThread to never be inlined, at least not when dynamic linking > and with static linking (or within the package/library) not unless > there is "whole program optimization" aka "link time code > generation" with static linking, which does exist out there. > > - Jay > > > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Thu, 15 Jan 2009 14:18:16 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] how to switch between user and kernel threads.. > > We do get inlining within modules by virtue of the gcc-backend at -O3. > > > On 15 Jan 2009, at 14:03, Jay wrote: > > The installer? > I thought the granularity was at the time of linking an executable. > I personally thought a command line parameter would be reasonable. > > > Why not function pointers? > It is a simple straightforward method to implement. > It should add one instruction per call. > It does reduce inlinability but I'm sure we aren't getting any such > such inlinability anyway. > Dynamic linking already kills inlinability, as does separate > compilation of modules in most systems. > > > I'm not sure how the types work out in such a scheme, but probably > assuming Thread.T is already a reference type, it can become ADDRESS > and then loopholed to ThreadPosix.T or ThreadPThread.T. > > > Function pointers are also the easiest method to build. I'm not sure > what the others are. > I can try making m3-libs/m3coreuserthreads that contains only > m3makefiles. > Probably it can say: > LibraryName = "m3coreuserthreads" > include_dir("../m3core/m3makefile") > > > and m3core/m3makefile can say > if not defined("LibraryName") > LibraryName = "m3core" > end > Library(LibraryName) > > > If that works, not bad. > > > And then cm3 or the config file can translate m3core to > m3coreuserthreads at some point. > > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Thu, 15 Jan 2009 11:31:17 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] how to switch between user and kernel threads.. > > > No function pointers please. Let the installer decide whether to > use native or user threads. > > On 15 Jan 2009, at 08:30, Jay wrote: > > I'll wait. > So, build two different m3core.lib/a/so/dylib? > m3core and m3coreuserthreads > > Compile both thread directories, if the platform supports it, and > call quake make_lib twice with slightly different parameters? > An m3core specific hack in the config file or cm3? > Easy enough in the config file. > Very m3core specific. > I suppose you could argue that quake isn't a generic build system, > but it is Modula-3's build system, and that m3core is really special. > > The result btw, would likely be no change at all to any *.i3 or *.m3 > file. > > I still think function pointers are the way to go. > Even with function pointers, the changes to *.i3 and *.m3 would be > very minor. > Just the export list would vary. > And new *.i3 files introduced. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Wed, 14 Jan 2009 21:31:22 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] how to switch between user and kernel threads.. > > I don't want dynamic switching. A link-time switch is just fine. > > Also, please don't go messing about with this right now -- I have > changes pending for the threads system that will be harder to > integrate if you change with it further. > > On 14 Jan 2009, at 20:14, Jay wrote: > > Are people really against using function pointers for this? > Either changing the interface to have function pointer variables > (I'm not sure Modula-3 allows this, but in C you can fairly > transparently replace functions with function pointers; client code > just keeps working; it breaks down in C++ with overloading), or > having a set of functions that just call/jump through function > pointers? There would be no if, no conditional branches. > > Dynamic linking on Windows always goes through function pointers > already. > So while yes it adds another instruction, it is already never > getting inlined. > Don't other platforms do that too? > Or they patch every call site? > > I'm not sure otherwise of a simple method. > Easiest might be to have a parallel directory structure to m3core, > with just m3core files. > That would wastefully rebuild all of m3core a second time, for just > a small amount of variation. > > I think function pointers are the way to go here. > > - Jay > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinbishop at bellsouth.net Sat Jan 17 06:19:51 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Fri, 16 Jan 2009 23:19:51 -0600 Subject: [M3devel] What is M3SU? Message-ID: <49716A77.60405@bellsouth.net> I was reading the FAQ for Modula-3, and noticed they mentioned a program called "m3su". The link they give to an ftp server is no longer available, but with a little poking around I found where it is located at, however they do not have 'm3su' on it anymore. What is (or was?) m3su? From hosking at cs.purdue.edu Sat Jan 17 12:03:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 17 Jan 2009 22:03:19 +1100 Subject: [M3devel] "new old" ports, or no ports at all? In-Reply-To: References: Message-ID: <715A8E4A-CDC4-453B-96F8-67E377E8EDF2@cs.purdue.edu> Historically, there have been non-gcc-based backends. We would not want to preclude those. On 17 Jan 2009, at 00:05, Jay wrote: > Would people mind "new" ports like: > > > HPPA32_HPUX (HPPA_HPUX? There is "HPPA") > I386_FREEBSD (There is FreeBSD4.) > I386_NETBSD (There is NetBSD2_i386.) > MIPS32_IRIX (MIPS_IRIX? There is IRIX5.) > ALPHA_FREEBSD (There FBSD_ALPHA.) > and then for that matter: > SPARC32_SOLARIS, I386_LINUX > > > Or some mix? > This is not hypothetical. I do now have HPPA, Alpha, SGI hardware. :) > > > I can either do the little bit of correct testable valid small etc. > work > of using my "more portable" approach to these platforms, which > gets things up and running easily and fast and perfectly acceptably, > or I could "proofread" all the gunk, I mean cloned headers, fix them > for current system, worry if they break old system, or delete them, > possibly doing some hypothetical damage to the old ports. > > > It seems easier and a better result to "start over" and leave the > old stuff alone, > maybe delete it, depending on what people think of history > preservation and > history vs. deletes (deleted stuff isn't very visible). > > > Or maybe hardly any of this matters. Nobody uses these platforms or > anything like them? > (I recall Randy saying he is still using 4.1 on HP-UX though. I'm on > a fun little > long running errand here of getting not ancient but not current > systems.. :) ) > > > The "4", "2", "5" in FreeBSD4, NetBSD2_i386, IRIX5 make them seen > somewhat "wrong". > > > The "4" in FreeBSD4 (err, in i686-freebsd4) does have a surprising > semantic, in the backend..but maybe not. > C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(53): > builtin_define_with_int_value ("__FreeBSD__", FBSD_MAJOR); \ > C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(122):#if > FBSD_MAJOR < 5 > C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(141):#if > FBSD_MAJOR < 6 > > > though I think if you look closely, these don't matter to us. > They affect the gcc driver and the C/C++ front end, but maybe not > the m3cg backend. > > > Even the "LIBC6" in "LINUXLIBC6" seems dubious, because, for > example, I am > tempted to make "ARM_LINUX_UCLIBC", which suggests either that > there might be an "I386_LINUX_UCLIBC" or "generic" "I386_LINUX" that > is portable across libc6/uclibc/dietlibc/newlib either by seeing > what they have in common, or skipping them and using the kernel > interfaces > more directly. > > > There is another angle here. > To what extent is the compiler platform specific? > (I mostly know the answer to this. It is a leading question.) > Could ports go away? > Almost? > > > Historically there were a bunch of platform-specific .i3 files. > That is dwindling much in some platforms and could dwindle much > overall. > A little more C code in the system and the Modula-3 .i3 files are > all "portable". > > > It ends up being, roughly, that there is: > > > endian, and even this is often not an issue; I saw like > one reference in the compiler to it, and there is a little bit in > m3core/libm3 > The byte swap functions and maybe the Float stuff (there is > endian specific > and generic stuff, not all is used). > It would affect e.g. the layout of the Uexec types, but they are > gone. > Such endian-specificity could occur anywhere but maybe "cm3 - > generic" errors for it? > > > word size -- 32bit or 64bit. There is no escaping this, as long as > there are any 32bit platforms. > So ok, two ports, 32bit and 64bit. That's a small matrix. > > > IEEE or not -- everything is IEEE now. I don't plan on getting a > VAX. :) > (The compiler seems suspicious here wrt cross building.) > > > The name of setjmp. > However this could be made the same everywhere -- m3_setjmp or > M3Try or M3SaveState, > and use an #ifdef .c file to decide. > > > The size of the jmpbuf. Ah, there's the rub. > A "generic" platform could blow up the size of the jmpbuf to > something that works > on all known platforms. Very very wasteful. Some platforms have > tiny, some have huge. > > > I'm not sure where stack layout is done. If the front end does it > or not. > You could imagine something like M3Try allocating the same..but > this seems bad. > If the front end defers enough work to the backend, you could > introduce an abstracted > notion of the jmpbuf and leave it to m3cg to fill in? Leave it to > #ifdef on the target? > m3cg, in its current form as gcc based is always going to have be > configured to be > target specific. > > > Or all platforms could have stack walkers and this platform- > specificity would go away. > But that is a very long ways off, if ever. > > > My point is, you know, can we in fact eliminate the notion of > porting? > At least of cm3 knowing anything about the target, and only m3cg? > Because the system is nearly portable enough? All that is left is > configuring gcc? > It seems very close to possible. > > > Like, "have gcc, will travel"? > And nothing else changes? > No value then in doing any porting work up front? > > > You know..think of the author of hello world..some highly portable > program. > Or more realistic example such as bash, awk, make, ld and gcc on a > particular host (not target), etc. > They don't go around much and port to this or that or the other > system. > They do a mix of "just try to be portable" and "leave autoconf to > figure out". > > > Modula-3 is almost in the same boat? > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jan 17 12:36:39 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 17 Jan 2009 11:36:39 +0000 Subject: [M3devel] "new old" ports, or no ports at all? In-Reply-To: <715A8E4A-CDC4-453B-96F8-67E377E8EDF2@cs.purdue.edu> References: <715A8E4A-CDC4-453B-96F8-67E377E8EDF2@cs.purdue.edu> Message-ID: Ah -- you mean if there more integrated backends written in Modula-3, then it would become "impossible" to push such knowledge of the target as its processor, endianness, etc. out of cm3? Or rather, it would be /possible/, but it would be counterproductive. That makes sense. Good point. But that could be added back. if platform = "nt386" UseIntegratedBackend(); else if ... ... else gcc backend handles it (almost) all ? No need, perhaps, for a big enum and switch. Just about. You know..as it stands..cm3 knows just a little about each target, and it doesn't even use all it knows kinda. Word size it uses in computing layout. Endianness it uses rarely I think. "aligned procedures" it uses in about one place. Some of the data in Target.i3 was unused and I removed it. I guess nevermind. I'm just thinking about, you know, declaring all ports either done, or so trivial that there is little point in doing one until someone needs it, merely tedium. That isn't actually the case yet -- there should be C program(s) to generate the "residue", Usysdep.i3, Csetjmp.i3, etc. The other backends are the NT386 one, and it adapted to Linux/x86, right? And maybe what used to generate C? (Can someone give me details as to why C generation isn't a great idea?) - Jay ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] "new old" ports, or no ports at all? > Date: Sat, 17 Jan 2009 22:03:19 +1100 > > Historically, there have been non-gcc-based backends. We would not want to preclude those. > > On 17 Jan 2009, at 00:05, Jay wrote: > > Would people mind "new" ports like: > > > HPPA32_HPUX (HPPA_HPUX? There is "HPPA") > I386_FREEBSD (There is FreeBSD4.) > I386_NETBSD (There is NetBSD2_i386.) > MIPS32_IRIX (MIPS_IRIX? There is IRIX5.) > ALPHA_FREEBSD (There FBSD_ALPHA.) > and then for that matter: > SPARC32_SOLARIS, I386_LINUX > > > Or some mix? > This is not hypothetical. I do now have HPPA, Alpha, SGI hardware. :) > > > I can either do the little bit of correct testable valid small etc. work > of using my "more portable" approach to these platforms, which > gets things up and running easily and fast and perfectly acceptably, > or I could "proofread" all the gunk, I mean cloned headers, fix them > for current system, worry if they break old system, or delete them, > possibly doing some hypothetical damage to the old ports. > > > It seems easier and a better result to "start over" and leave the old stuff alone, > maybe delete it, depending on what people think of history preservation and > history vs. deletes (deleted stuff isn't very visible). > > > Or maybe hardly any of this matters. Nobody uses these platforms or anything like them? > (I recall Randy saying he is still using 4.1 on HP-UX though. I'm on a fun little > long running errand here of getting not ancient but not current systems.. :) ) > > > The "4", "2", "5" in FreeBSD4, NetBSD2_i386, IRIX5 make them seen somewhat "wrong". > > > The "4" in FreeBSD4 (err, in i686-freebsd4) does have a surprising semantic, in the backend..but maybe not. > C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(53): builtin_define_with_int_value ("__FreeBSD__", FBSD_MAJOR); \ > C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(122):#if FBSD_MAJOR < 5 > C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(141):#if FBSD_MAJOR < 6 > > > though I think if you look closely, these don't matter to us. > They affect the gcc driver and the C/C++ front end, but maybe not the m3cg backend. > > > Even the "LIBC6" in "LINUXLIBC6" seems dubious, because, for example, I am > tempted to make "ARM_LINUX_UCLIBC", which suggests either that > there might be an "I386_LINUX_UCLIBC" or "generic" "I386_LINUX" that > is portable across libc6/uclibc/dietlibc/newlib either by seeing > what they have in common, or skipping them and using the kernel interfaces > more directly. > > > There is another angle here. > To what extent is the compiler platform specific? > (I mostly know the answer to this. It is a leading question.) > Could ports go away? > Almost? > > > Historically there were a bunch of platform-specific .i3 files. > That is dwindling much in some platforms and could dwindle much overall. > A little more C code in the system and the Modula-3 .i3 files are all "portable". > > > It ends up being, roughly, that there is: > > > endian, and even this is often not an issue; I saw like > one reference in the compiler to it, and there is a little bit in m3core/libm3 > The byte swap functions and maybe the Float stuff (there is endian specific > and generic stuff, not all is used). > It would affect e.g. the layout of the Uexec types, but they are gone. > Such endian-specificity could occur anywhere but maybe "cm3 -generic" errors for it? > > > word size -- 32bit or 64bit. There is no escaping this, as long as there are any 32bit platforms. > So ok, two ports, 32bit and 64bit. That's a small matrix. > > > IEEE or not -- everything is IEEE now. I don't plan on getting a VAX. :) > (The compiler seems suspicious here wrt cross building.) > > > The name of setjmp. > However this could be made the same everywhere -- m3_setjmp or M3Try or M3SaveState, > and use an #ifdef .c file to decide. > > > The size of the jmpbuf. Ah, there's the rub. > A "generic" platform could blow up the size of the jmpbuf to something that works > on all known platforms. Very very wasteful. Some platforms have tiny, some have huge. > > > I'm not sure where stack layout is done. If the front end does it or not. > You could imagine something like M3Try allocating the same..but this seems bad. > If the front end defers enough work to the backend, you could introduce an abstracted > notion of the jmpbuf and leave it to m3cg to fill in? Leave it to #ifdef on the target? > m3cg, in its current form as gcc based is always going to have be configured to be > target specific. > > > Or all platforms could have stack walkers and this platform-specificity would go away. > But that is a very long ways off, if ever. > > > My point is, you know, can we in fact eliminate the notion of porting? > At least of cm3 knowing anything about the target, and only m3cg? > Because the system is nearly portable enough? All that is left is configuring gcc? > It seems very close to possible. > > > Like, "have gcc, will travel"? > And nothing else changes? > No value then in doing any porting work up front? > > > You know..think of the author of hello world..some highly portable program. > Or more realistic example such as bash, awk, make, ld and gcc on a particular host (not target), etc. > They don't go around much and port to this or that or the other system. > They do a mix of "just try to be portable" and "leave autoconf to figure out". > > > Modula-3 is almost in the same boat? > > > - Jay > > From hosking at cs.purdue.edu Sat Jan 17 12:45:30 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 17 Jan 2009 22:45:30 +1100 Subject: [M3devel] What is M3SU? In-Reply-To: <49716A77.60405@bellsouth.net> References: <49716A77.60405@bellsouth.net> Message-ID: <1548D817-74A6-4411-8DBB-2CACA3C744CA@cs.purdue.edu> Never heard of it. 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 17 Jan 2009, at 16:19, Martin Bishop wrote: > I was reading the FAQ for Modula-3, and noticed they mentioned a > program > called "m3su". The link they give to an ftp server is no longer > available, but with a little poking around I found where it is located > at, however they do not have 'm3su' on it anymore. > > What is (or was?) m3su? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Jan 17 12:48:33 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 17 Jan 2009 22:48:33 +1100 Subject: [M3devel] "new old" ports, or no ports at all? In-Reply-To: References: <715A8E4A-CDC4-453B-96F8-67E377E8EDF2@cs.purdue.edu> Message-ID: <58149067-89DE-4D73-A4E4-BF48C1A9A776@cs.purdue.edu> There were BURS backends too. And C is not good for source-level debugging. On 17 Jan 2009, at 22:36, Jay wrote: > > Ah -- you mean if there more integrated backends written in > Modula-3, then it would become "impossible" to push such knowledge > of the target as its processor, endianness, etc. out of cm3? > Or rather, it would be /possible/, but it would be counterproductive. > That makes sense. Good point. > But that could be added back. > > > if platform = "nt386" > UseIntegratedBackend(); > else if ... > ... > else > gcc backend handles it (almost) all ? > > > No need, perhaps, for a big enum and switch. > Just about. > > > You know..as it stands..cm3 knows just a little about each target, > and it doesn't even use all it knows kinda. Word size it uses in > computing layout. Endianness it uses rarely I think. "aligned > procedures" it uses in about one place. Some of the data in > Target.i3 was unused and I removed it. I guess nevermind. I'm just > thinking about, you know, declaring all ports either done, or so > trivial that there is little point in doing one until someone needs > it, merely tedium. That isn't actually the case yet -- there should > be C program(s) to generate the "residue", Usysdep.i3, Csetjmp.i3, > etc. > > > The other backends are the NT386 one, and it adapted to Linux/x86, > right? > And maybe what used to generate C? > (Can someone give me details as to why C generation isn't a great > idea?) > > > - Jay > > > > ________________________________ >> CC: m3devel at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Subject: Re: [M3devel] "new old" ports, or no ports at all? >> Date: Sat, 17 Jan 2009 22:03:19 +1100 >> >> Historically, there have been non-gcc-based backends. We would not >> want to preclude those. >> >> On 17 Jan 2009, at 00:05, Jay wrote: >> >> Would people mind "new" ports like: >> >> >> HPPA32_HPUX (HPPA_HPUX? There is "HPPA") >> I386_FREEBSD (There is FreeBSD4.) >> I386_NETBSD (There is NetBSD2_i386.) >> MIPS32_IRIX (MIPS_IRIX? There is IRIX5.) >> ALPHA_FREEBSD (There FBSD_ALPHA.) >> and then for that matter: >> SPARC32_SOLARIS, I386_LINUX >> >> >> Or some mix? >> This is not hypothetical. I do now have HPPA, Alpha, SGI hardware. :) >> >> >> I can either do the little bit of correct testable valid small etc. >> work >> of using my "more portable" approach to these platforms, which >> gets things up and running easily and fast and perfectly acceptably, >> or I could "proofread" all the gunk, I mean cloned headers, fix them >> for current system, worry if they break old system, or delete them, >> possibly doing some hypothetical damage to the old ports. >> >> >> It seems easier and a better result to "start over" and leave the >> old stuff alone, >> maybe delete it, depending on what people think of history >> preservation and >> history vs. deletes (deleted stuff isn't very visible). >> >> >> Or maybe hardly any of this matters. Nobody uses these platforms or >> anything like them? >> (I recall Randy saying he is still using 4.1 on HP-UX though. I'm >> on a fun little >> long running errand here of getting not ancient but not current >> systems.. :) ) >> >> >> The "4", "2", "5" in FreeBSD4, NetBSD2_i386, IRIX5 make them seen >> somewhat "wrong". >> >> >> The "4" in FreeBSD4 (err, in i686-freebsd4) does have a surprising >> semantic, in the backend..but maybe not. >> C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(53): >> builtin_define_with_int_value ("__FreeBSD__", FBSD_MAJOR); \ >> C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(122):#if >> FBSD_MAJOR < 5 >> C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(141):#if >> FBSD_MAJOR < 6 >> >> >> though I think if you look closely, these don't matter to us. >> They affect the gcc driver and the C/C++ front end, but maybe not >> the m3cg backend. >> >> >> Even the "LIBC6" in "LINUXLIBC6" seems dubious, because, for >> example, I am >> tempted to make "ARM_LINUX_UCLIBC", which suggests either that >> there might be an "I386_LINUX_UCLIBC" or "generic" "I386_LINUX" that >> is portable across libc6/uclibc/dietlibc/newlib either by seeing >> what they have in common, or skipping them and using the kernel >> interfaces >> more directly. >> >> >> There is another angle here. >> To what extent is the compiler platform specific? >> (I mostly know the answer to this. It is a leading question.) >> Could ports go away? >> Almost? >> >> >> Historically there were a bunch of platform-specific .i3 files. >> That is dwindling much in some platforms and could dwindle much >> overall. >> A little more C code in the system and the Modula-3 .i3 files are >> all "portable". >> >> >> It ends up being, roughly, that there is: >> >> >> endian, and even this is often not an issue; I saw like >> one reference in the compiler to it, and there is a little bit in >> m3core/libm3 >> The byte swap functions and maybe the Float stuff (there is endian >> specific >> and generic stuff, not all is used). >> It would affect e.g. the layout of the Uexec types, but they are >> gone. >> Such endian-specificity could occur anywhere but maybe "cm3 - >> generic" errors for it? >> >> >> word size -- 32bit or 64bit. There is no escaping this, as long as >> there are any 32bit platforms. >> So ok, two ports, 32bit and 64bit. That's a small matrix. >> >> >> IEEE or not -- everything is IEEE now. I don't plan on getting a >> VAX. :) >> (The compiler seems suspicious here wrt cross building.) >> >> >> The name of setjmp. >> However this could be made the same everywhere -- m3_setjmp or >> M3Try or M3SaveState, >> and use an #ifdef .c file to decide. >> >> >> The size of the jmpbuf. Ah, there's the rub. >> A "generic" platform could blow up the size of the jmpbuf to >> something that works >> on all known platforms. Very very wasteful. Some platforms have >> tiny, some have huge. >> >> >> I'm not sure where stack layout is done. If the front end does it >> or not. >> You could imagine something like M3Try allocating the same..but >> this seems bad. >> If the front end defers enough work to the backend, you could >> introduce an abstracted >> notion of the jmpbuf and leave it to m3cg to fill in? Leave it to >> #ifdef on the target? >> m3cg, in its current form as gcc based is always going to have be >> configured to be >> target specific. >> >> >> Or all platforms could have stack walkers and this platform- >> specificity would go away. >> But that is a very long ways off, if ever. >> >> >> My point is, you know, can we in fact eliminate the notion of >> porting? >> At least of cm3 knowing anything about the target, and only m3cg? >> Because the system is nearly portable enough? All that is left is >> configuring gcc? >> It seems very close to possible. >> >> >> Like, "have gcc, will travel"? >> And nothing else changes? >> No value then in doing any porting work up front? >> >> >> You know..think of the author of hello world..some highly portable >> program. >> Or more realistic example such as bash, awk, make, ld and gcc on a >> particular host (not target), etc. >> They don't go around much and port to this or that or the other >> system. >> They do a mix of "just try to be portable" and "leave autoconf to >> figure out". >> >> >> Modula-3 is almost in the same boat? >> >> >> - Jay >> >> From eiserlohpp at yahoo.com Sun Jan 18 04:09:35 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sat, 17 Jan 2009 19:09:35 -0800 (PST) Subject: [M3devel] Multiple CM3_ROOTs Message-ID: <495761.443.qm@web56802.mail.re3.yahoo.com> Hi Tony and Gang, The hypothetical scenario is a system providing multiple user accounts. The sysadmin will install a released version of CM3, not a daily snapshot. Any user should be able to install a daily snapshot, and old one, or a custom version, for their particular use. This would go within a directory of their choosing (within their personal HOME). These users, may have many customized versions of libm3 (and m3core), and hence many installations of an M3 compiler. A git repository has already been imported from the main CVS repository at elego. Any user (at the moment thats just me) may create any number of branches and play with the code. How can I ship to a different CM3_ROOT, than the one that built it? When using a different CM3_ROOT than the standard one, the user would obviously have to set their PATH and CM3 environment variables appropriately. How does the cm3 compiler frontend know the path to its config file? Does it walk argv[0] up the directory chain, and use the PATH to find itself, or is the path build-in? Does it use the environment variable CM3 if found? +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From dabenavidesd at yahoo.es Sun Jan 18 05:50:16 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 17 Jan 2009 20:50:16 -0800 (PST) Subject: [M3devel] Multiple CM3_ROOTs In-Reply-To: <495761.443.qm@web56802.mail.re3.yahoo.com> Message-ID: <224644.55641.qm@web24707.mail.ird.yahoo.com> Hi Peter: what I learned is that the cm3 compiler finds it's config file in the same directory of the cm3 compiler executable, otherwise it reports an error (about it). I know from cm3 -? that: from http://www.opencm3.net/doc/help/cm3/cm3-quickref.html environment variables: M3CONFIG platform dependent configuration file to use (cm3.cfg) used if no suitable file is found in the local packageHowever I don't how can be used the compiler to ship and compile according the abstracted config files made by Jay specially in the NT386 and derived platforms (I guess would be nice to set that in the command itself like select to alternative not common configurations of graphic libs? or back ends, etc, ...) with the same libm3 and m3core. Thanks in advance --- El s?b, 17/1/09, Peter Eiserloh escribi?: De: Peter Eiserloh Asunto: [M3devel] Multiple CM3_ROOTs Para: m3devel at elegosoft.com Fecha: s?bado, 17 enero, 2009 10:09 Hi Tony and Gang, The hypothetical scenario is a system providing multiple user accounts. The sysadmin will install a released version of CM3, not a daily snapshot. Any user should be able to install a daily snapshot, and old one, or a custom version, for their particular use. This would go within a directory of their choosing (within their personal HOME). These users, may have many customized versions of libm3 (and m3core), and hence many installations of an M3 compiler. A git repository has already been imported from the main CVS repository at elego. Any user (at the moment thats just me) may create any number of branches and play with the code. How can I ship to a different CM3_ROOT, than the one that built it? When using a different CM3_ROOT than the standard one, the user would obviously have to set their PATH and CM3 environment variables appropriately. How does the cm3 compiler frontend know the path to its config file? Does it walk argv[0] up the directory chain, and use the PATH to find itself, or is the path build-in? Does it use the environment variable CM3 if found? +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 18 10:04:57 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 18 Jan 2009 09:04:57 +0000 Subject: [M3devel] Multiple CM3_ROOTs In-Reply-To: <224644.55641.qm@web24707.mail.ird.yahoo.com> References: <495761.443.qm@web56802.mail.re3.yahoo.com> <224644.55641.qm@web24707.mail.ird.yahoo.com> Message-ID: I didn't change how the compiler "starts", how it finds the first config file. Config files can go off and include others. The below sounds slightly wrong. I believe the M3CONFIG environment variable is checked before the cm3.cfg file "next to" cm3 is used. What I do is my cm3.cfg "next to" cm3 then goes and looks for the "real" config file. It is guided by - knowing where the source tree is, via the environment variable CM3_ROOT - knowing the host, via the HOST variable that I added to cm3 - if HOST isn't defined, it generally fails, except on NT it can use the OS environment variable. CM3_INSTALL or INSTALLROOT is the root of the cm3 installation. CM3_ROOT or ROOT is the root of the cm3 source tree. I don't find these names ideal, but I also am not super keen on changing them. Clearer and more consistent would be CM3_INSTALL_ROOT and CM3_SOURCE_ROOT. Within quake are available variables without the leading "CM3_". Environment variables with leading "CM3_" I think are the way to go. And that is /generally/ how it works, but not necessarily exactly. Also, my cm3.cfg sets INSTALLROOT based on its own location. To learn how to ship to another root... My make-dist.py accomplishes this. I think the way it works though is it copies cm3 out to a new location and runs it from there. And the cm3.cfg. INSTALLROOT or CM3_INSTALL is therefore the location of wherever cm3 is copied to and run from. Personally I think the system is somewhat misdesigned. Regarding link output and shipped output, there should just be one place. The only point in a two step link and ship/install is if you are installing over a live system. A simpler better approach is to always use a new or staging area for the link output, and if you are happy with it, you merely do a recursive copy on top of your live system. Or, you change PATH to point to the new cm3 and adopt it as your new system. This also addresses the problem that cm3 can't ship itself. This also could be part of giving an alternate location for the "intermediate" outputs that never shipped -- the .obj file. They should not litter the source tree. You know, on a package basis, Modula-3 is/was progressive in that not only does it support "out of source" builds, but it only supports them. And you can cons up arbitrary new intermediate locations on demand by changing BUILD_DIR. Though sometimes assumptions creep in that BUILD_DIR == TARGET. However, if you consider multiple packages, then the intermediate outputs actually are in the source tree. There aren't many very visible analogs in the world. However one is how gcc builds. It ties together multiple packages (optionally) and all the outputs go outside of the entire source tree. - Jay ________________________________ > Date: Sat, 17 Jan 2009 20:50:16 -0800 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com; eiserlohpp at yahoo.com > Subject: Re: [M3devel] Multiple CM3_ROOTs > > Hi Peter: > what I learned is that the cm3 compiler finds it's config file in the same directory of the cm3 compiler executable, otherwise it reports an error (about it). > I know from cm3 -? that: > from http://www.opencm3.net/doc/help/cm3/cm3-quickref.html > environment variables: > > M3CONFIG platform dependent configuration file to use (cm3.cfg) > used if no suitable file is found in the local package > > However I don't how can be used the compiler to ship and compile according the abstracted config files made by Jay specially in the NT386 and derived platforms (I guess would be nice to set that in the command itself like select to alternative not common configurations of graphic libs or back ends, etc, ...) with the same libm3 and m3core. > > Thanks in advance > --- El s?b, 17/1/09, Peter Eiserloh > escribi?: > De: Peter Eiserloh > Asunto: [M3devel] Multiple CM3_ROOTs > Para: m3devel at elegosoft.com > Fecha: s?bado, 17 enero, 2009 10:09 > > > Hi Tony and Gang, > > The hypothetical scenario is a system providing multiple > user accounts. The sysadmin will install a released > version of CM3, not a daily snapshot. Any user should be > able to install a daily snapshot, and old one, or a custom > version, for their particular use. This would go within > a directory of their choosing (within their personal HOME). > > These users, may have many customized versions of libm3 > (and m3core), and hence many installations of an M3 > compiler. > > A git repository has already been imported from the main > CVS repository at elego. Any user (at the moment > thats > just me) may create any number of branches and play with > the code. > > How can I ship to a different CM3_ROOT, than the one that > built it? > > When using a different CM3_ROOT than the standard one, the > user would obviously have to set their PATH and CM3 > environment variables appropriately. How does the cm3 > compiler frontend know the path to its config file? > Does it walk argv[0] up the directory chain, and use the > PATH to find itself, or is the path build-in? Does it use > the environment variable CM3 if found? > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > > > From jay.krell at cornell.edu Mon Jan 19 13:47:15 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 19 Jan 2009 12:47:15 +0000 Subject: [M3devel] "new old" ports, or no ports at all? In-Reply-To: <49706962.1E75.00D7.1@scires.com> References: <49706962.1E75.00D7.1@scires.com> Message-ID: I assume they can run 64bit? My system can/is. I have to research if 1.1 is 32bit, 2.0 is 64bit, or if there is a larger matrix. Any preference among "HPPA64_HPUX" vs. "PA64_HPUX" -- the double "HP" is kind of redundant. The minimum gcc configuration names I found to work are hppa64-hpux11 and presumably hppa-hpux11. The major version is required, else configure errors out "unsupported". Similarly: reusing existing "HPPA" or introduce "HPPA32_HPUX" or "PA32_HPUX"? My inclination is PA32_HPUX, PA64_HPUX, but any is ok. "PA" is shorter, but "HPPA64" is not record settingly long -- we have "SPARC64", and "SPARC32" that I introduced. The names will then apply to *_LINUX as well. Also you must have GNU as for this port. m3cc/src/m3makefile indicates that was already the case for the old HPPA. gcc 3.3.6 is ok with the HP assembler, though I don't remember if -g worked. But gcc 4.3.2 is not ok with the HP assembler. - Jay ________________________________ > Date: Fri, 16 Jan 2009 11:04:53 -0500 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] "new old" ports, or no ports at all? > > > > > > > > > > Jay: > > > > I do have some HP-UX machines that I could use to test whatever you come up with for HPPA. You are correct that right now I run cm3 v4.1 on these. I have not tried to move beyond 4.1 on them yet. > > > > Regards, > > Randy > >>>> Jay 1/16/2009 8:05 AM>>> > Would people mind "new" ports like: > > > HPPA32_HPUX (HPPA_HPUX? There is "HPPA") > I386_FREEBSD (There is FreeBSD4.) > I386_NETBSD (There is NetBSD2_i386.) > MIPS32_IRIX (MIPS_IRIX? There is IRIX5.) > ALPHA_FREEBSD (There FBSD_ALPHA.) > and then for that matter: > SPARC32_SOLARIS, I386_LINUX > > > Or some mix? > This is not hypothetical. I do now have HPPA, Alpha, SGI hardware. :) > > > I can either do the little bit of correct testable valid small etc. work > of using my "more portable" approach to these platforms, which > gets things up and running easily and fast and perfectly acceptably, > or I could "proofread" all the gunk, I mean cloned headers, fix them > for current system, worry if they break old system, or delete them, > possibly doing some hypothetical damage to the old ports. > > > It seems easier and a better result to "start over" and leave the old stuff alone, > maybe delete it, depending on what people think of history preservation and > history vs. deletes (deleted stuff isn't very visible). > > > Or maybe hardly any of this matters. Nobody uses these platforms or anything like them? > (I recall Randy saying he is still using 4.1 on HP-UX though. I'm on a fun little > long running errand here of getting not ancient but not current systems.. :) ) > > > The "4", "2", "5" in FreeBSD4, NetBSD2_i386, IRIX5 make them seen somewhat "wrong". > > > The "4" in FreeBSD4 (err, in i686-freebsd4) does have a surprising semantic, in the backend..but maybe not. > C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(53): builtin_define_with_int_value ("__FreeBSD__", FBSD_MAJOR); \ > C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(122):#if FBSD_MAJOR < 5 > C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(141):#if FBSD_MAJOR < 6 > > > though I think if you look closely, these don't matter to us. > They affect the gcc driver and the C/C++ front end, but maybe not the m3cg backend. > > > Even the "LIBC6" in "LINUXLIBC6" seems dubious, because, for example, I am > tempted to make "ARM_LINUX_UCLIBC", which suggests either that > there might be an "I386_LINUX_UCLIBC" or "generic" "I386_LINUX" that > is portable across libc6/uclibc/dietlibc/newlib either by seeing > what they have in common, or skipping them and using the kernel interfaces > more directly. > > > There is another angle here. > To what extent is the compiler platform specific? > (I mostly know the answer to this. It is a leading question.) > Could ports go away? > Almost? > > > Historically there were a bunch of platform-specific .i3 files. > That is dwindling much in some platforms and could dwindle much overall. > A little more C code in the system and the Modula-3 .i3 files are all "portable". > > > It ends up being, roughly, that there is: > > > endian, and even this is often not an issue; I saw like > one reference in the compiler to it, and there is a little bit in m3core/libm3 > The byte swap functions and maybe the Float stuff (there is endian specific > and generic stuff, not all is used). > It would affect e.g. the layout of the Uexec types, but they are gone. > Such endian-specificity could occur anywhere but maybe "cm3 -generic" errors for it? > > > word size -- 32bit or 64bit. There is no escaping this, as long as there are any 32bit platforms. > So ok, two ports, 32bit and 64bit. That's a small matrix. > > > IEEE or not -- everything is IEEE now. I don't plan on getting a VAX. :) > (The compiler seems suspicious here wrt cross building.) > > > The name of setjmp. > However this could be made the same everywhere -- m3_setjmp or M3Try or M3SaveState, > and use an #ifdef .c file to decide. > > > The size of the jmpbuf. Ah, there's the rub. > A "generic" platform could blow up the size of the jmpbuf to something that works > on all known platforms. Very very wasteful. Some platforms have tiny, some have huge. > > > I'm not sure where stack layout is done. If the front end does it or not. > You could imagine something like M3Try allocating the same..but this seems bad. > If the front end defers enough work to the backend, you could introduce an abstracted > notion of the jmpbuf and leave it to m3cg to fill in? Leave it to #ifdef on the target? > m3cg, in its current form as gcc based is always going to have be configured to be > target specific. > > > Or all platforms could have stack walkers and this platform-specificity would go away. > But that is a very long ways off, if ever. > > > My point is, you know, can we in fact eliminate the notion of porting? > At least of cm3 knowing anything about the target, and only m3cg? > Because the system is nearly portable enough? All that is left is configuring gcc? > It seems very close to possible. > > > Like, "have gcc, will travel"? > And nothing else changes? > No value then in doing any porting work up front? > > > You know..think of the author of hello world..some highly portable program. > Or more realistic example such as bash, awk, make, ld and gcc on a particular host (not target), etc. > They don't go around much and port to this or that or the other system. > They do a mix of "just try to be portable" and "leave autoconf to figure out". > > > Modula-3 is almost in the same boat? > > > - Jay > From wagner at elegosoft.com Mon Jan 19 16:09:21 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 19 Jan 2009 16:09:21 +0100 Subject: [M3devel] What is M3SU? In-Reply-To: <49716A77.60405@bellsouth.net> References: <49716A77.60405@bellsouth.net> Message-ID: <20090119160921.s5v4nsv3j4g4g0oo@mail.elegosoft.com> Quoting Martin Bishop : > I was reading the FAQ for Modula-3, and noticed they mentioned a program > called "m3su". The link they give to an ftp server is no longer > available, but with a little poking around I found where it is located > at, however they do not have 'm3su' on it anymore. > > What is (or was?) m3su? The FAQ says it is an emcas macro package; I've never used it AFAIK. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jan 19 23:39:34 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 19 Jan 2009 22:39:34 +0000 Subject: [M3devel] move to version 5.7.1? Message-ID: 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 rcoleburn at scires.com Tue Jan 20 00:50:40 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 19 Jan 2009 18:50:40 -0500 Subject: [M3devel] move to version 5.7.1? In-Reply-To: References: Message-ID: <4974CB61.1E75.00D7.1@scires.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jan 20 03:28:07 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 20 Jan 2009 02:28:07 +0000 Subject: [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: 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 jay.krell at cornell.edu Tue Jan 20 07:03:09 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 20 Jan 2009 06:03:09 +0000 Subject: [M3devel] ship vs. where build outputs go, etc.? In-Reply-To: References: <4974CB61.1E75.00D7.1@scires.com> Message-ID: > [was truncated and forward to m3commit instead of m3devel, now more content/drivel..] ps: >> 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. "Clean" doesn't really work imho..I guess it deletes the output files that the compiler knows about? Perhaps it is a bug when the config file doesn't tell it about all the outputs? "realclean" deletes the entire output directory, no matter what files it thinks it produced. It does assume they are all in the particular directory that they strongly tend to be in. It's dumb imho. Clean should probably be fixed. The m3-sys/m3cc directory and probably m3gdb also have their own special in-between state of "configure having been one", that they create a marker file to indicate. And then there is an environment variable to override that. Quake is a fairly general purpose language including the ability to read environment variables, so various directories are free to do whatever they want. m3cc and m3gdb are two of the longest to build package and configuration is also a slow step, that "rarely" has different output, so going back only to this "partly built" state perhaps is interesting. I rarely do that, at least on purpose. The Linux kernel and ucLibc (an alternative C runtime) do something similar. They store their configuration in file starting with a dot, so that on Unix rm -rf * won't delete it, because it skips "hidden" "dot" files. As well you can define arbitrary things on the cm3 command line, to guide arbitrary decisions around the tree, such as kernel vs. user threads. Given foo\src build outputs are generally in foo\target where "outputs" include "intermediate" files such as object files and "final" outputs such as executables and .dlls. You know...really I think, it's just that the Modula-3 folks knew/thought they were smarter than everyone else and made up their own terminology. In many other projects you have "make" and "make install". "ship" is "make install". I think that is all people need to know: "ship" == "install". It copies some of the outputs from foo\target to the installroot. Just as "make install" copies some of the outputs from the "intermediate" tree to the "live" tree. They can both be "dangerous" on a live system, and they can both be pointed at "new" empty location for safety (typical GNU make/automake/autoconf install option is make install DESTDIR=somewhere). I propose a different model. Always put the "final" outputs directly in a "live" tree, BUT for the case where you are doing something "risky" and would not immediately "ship" / "install", you would be encouraged to define a new clean output root, or an existing "test" root. "Actual install" would then be just a recursive copy from one root to another. Perhaps that is too inefficient? cm3 tries to do an incremental copy for example. I'm not sure if it is timestamp based or if they compare entire file contents. The downside to this proposal is that source files also get shipped, and doing that for every compile/link is wasteful. This is optional though and maybe can/should be turned off except when "making a distribution"? I'm not sure how optional it is. I'll try out turning it off locally. An upside to this proposal is it supercedes the "override" mechanism. You would never need to "override". "override" imho is broken because today, in order to keep "override" working, you are expected to encode the source tree structure all over the place. This seems redundant. Perhaps another idea would be for CM3_INSTALL to be colon/semicolon delimited? Search multiple package stores? That offers functionality not in the current model. A related proposal I have is that even the intermediate files be relocated. As I said, on a package-by-package basis, they are not in the source tree. Good. But on a multi-package basis, they are. Not good. I want the source tree to have no outputs, to stay "clean", unless I edit a file. Concretely this all looks like: 1) There is already the CM3_INSTALL environment variable. That is where "binaries" should be output, in the same structure that "ship" uses today. 2) There shall be a new environment variable, something like CM3_OBJECT_ROOT. 3) The existing CM3_ROOT that is the root of the source tree shall come into play. Given building in CM3_ROOT/foo/bar output shall go into: CM3_OBJECT_ROOT/foo/bar/target or maybe CM3_OBJECT_ROOT/target/foo/bar or maybe CM3_OBJECT_ROOT/foo/bar instead of CM3_ROOT/foo/bar/target. If you are not building under CM3_ROOT, there are a few viable options. 1) Do things as they are today. 2) Form up a form of CM3_OBJECT_ROOT/the path you are building that is valid and predictable. For example, in Windows, given a full path with a colon in it, remove the colon and you have a valid relative path you can append to another root. 3) Give user a way to specify what their "root" or "relative path from root" is. Because outputs litter the source tree today..unless you engage in changing BUILD_DIR, which maybe is the way in a few ways actually..you can't do multiple concurrent builds of the same target, such as with a different %PATH% to a different cm3.exe. Now, there is already BUILD_DIR. Perhaps all this is as simple as a change in the config file, changing BUILD_DIR to something like CM3_ROOT/path_of(foo.m3)/TARGET. I'll try that later. Maybe it just works. ? I'm not confident it'll work but maybe. Am I crazy? Wrong? Too disruptive? Most likely the last. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3commit at elegosoft.com; rcoleburn at scires.com > Date: Tue, 20 Jan 2009 05:40:07 +0000 > Subject: [M3commit] FW: [M3devel] move to version 5.7.1? > > > [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 jay.krell at cornell.edu Tue Jan 20 13:20:03 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 20 Jan 2009 12:20:03 +0000 Subject: [M3devel] win32 vs. Posix struct_linger code backwards?? Message-ID: Isn't this highly suspicious? It looks like Win32 turns "linger" off, and Posix turns it on. Win32: PROCEDURE InitSock (sock: WinSock.SOCKET) = (* We assume that the runtime ignores SIGPIPE signals *) (* LL = mu *) VAR one := 1; linger := WinSock.struct_linger{0, 0}; BEGIN (***** EVAL WinSock.setsockopt (sock, WinSock.SOL_SOCKET, WinSock.SO_SNDBUF, ADR(SysSendBufSize), BYTESIZE(SysSendBufSize)); EVAL WinSock.setsockopt (sock, WinSock.SOL_SOCKET, WinSock.SO_RCVBUF, ADR(SysRcvBufSize), BYTESIZE(SysRcvBufSize)); ******) EVAL WinSock.setsockopt (sock, WinSock.SOL_SOCKET, WinSock.SO_LINGER, ADR(linger), BYTESIZE(linger)); (**** WinSock documentation warns that this may cause problems ****) EVAL WinSock.setsockopt (sock, WinSock.IPPROTO_TCP, WinSock.TCP_NODELAY, ADR(one), BYTESIZE(one)); END InitSock; Posix: PROCEDURE InitStream (fd: CARDINAL) RAISES {OSError.E} = (* We assume that the runtime ignores SIGPIPE signals *) VAR one := 1; linger := Usocket.struct_linger{1, 1}; BEGIN (***** EVAL Usocket.setsockopt(fd, Usocket.SOL_SOCKET, Usocket.SO_SNDBUF, ADR(SysSendBufSize), BYTESIZE(SysSendBufSize)); EVAL Usocket.setsockopt(fd, Usocket.SOL_SOCKET, Usocket.SO_RCVBUF, ADR(SysRcvBufSize), BYTESIZE(SysRcvBufSize)); ******) EVAL Usocket.setsockopt(fd, Usocket.SOL_SOCKET, Usocket.SO_LINGER, ADR(linger), BYTESIZE(linger)); EVAL Usocket.setsockopt(fd, Uin.IPPROTO_TCP, TCP_NODELAY, ADR(one), BYTESIZE(one)); MakeNonBlocking (fd); END InitStream; From jay.krell at cornell.edu Tue Jan 20 15:12:55 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 20 Jan 2009 14:12:55 +0000 Subject: [M3devel] chosing SIG_SUSPEND? Message-ID: What is the algorithm for chosing SIG_SUSPEND? Something like: #include #ifdef __APPLE__ /* nothing -- SIG_SUSPEND not used */ #elif defined(NSIG) #define SIG_SUSPEND (NSIG - 1) #elif defined(_NSIG) #define SIG_SUSPEND (_NSIG - 1) #elif defined(SIGRTMAX) #define SIG_SUSPEND SIGRTMAX #else #define SIG_SUSPEND SIGUSR2 #endif ? Whatever it is, I think it should be in RTSignalC.c. - Jay From mika at async.caltech.edu Tue Jan 20 15:39:20 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 20 Jan 2009 06:39:20 -0800 Subject: [M3devel] [M3commit] FW: move to version 5.7.1? In-Reply-To: Your message of "Tue, 20 Jan 2009 05:40:07 GMT." Message-ID: <200901201439.n0KEdKr0094091@camembert.async.caltech.edu> Jay writes: ... >---------------------------------------- >> 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 ... >> >> 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. How about in Scheme? I have written/am writing a Scheme interpreter in Modula-3 that I am happy to release with CM3; it's very easily extensible (that's sort of the point of it), so one can easily add low-level features to it as necessary. The system would be self-contained with that interpreter. Maybe writing scripts in Scheme is a little "weird"... (but I do it :-) ) Mika From hosking at cs.purdue.edu Tue Jan 20 17:42:01 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 21 Jan 2009 03:42:01 +1100 Subject: [M3devel] chosing SIG_SUSPEND? In-Reply-To: References: Message-ID: Choose SIGRTMAX first if defined, then SIGUSR2. I don't thing NSIG-1 is reliable, but just works on some systems. On 21 Jan 2009, at 01:12, Jay wrote: > > What is the algorithm for chosing SIG_SUSPEND? > > Something like: > > #include > > #ifdef __APPLE__ > /* nothing -- SIG_SUSPEND not used */ > #elif defined(NSIG) > #define SIG_SUSPEND (NSIG - 1) > #elif defined(_NSIG) > #define SIG_SUSPEND (_NSIG - 1) > #elif defined(SIGRTMAX) > #define SIG_SUSPEND SIGRTMAX > #else > #define SIG_SUSPEND SIGUSR2 > #endif > > ? > > Whatever it is, I think it should be in RTSignalC.c. > > - Jay From rcoleburn at scires.com Tue Jan 20 18:07:01 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 20 Jan 2009 12:07:01 -0500 Subject: [M3devel] ship vs. where build outputs go, etc.? In-Reply-To: References: <4974CB61.1E75.00D7.1@scires.com> Message-ID: <4975BE3A.1E75.00D7.1@scires.com> Jay: I think your email illustrates part of what I was trying to say in that there are a lot of things that aren't documented very well at this point that differ from the current documentation and practice that we've followed over the years. I'm not sure I agree with some of the proposals you offer. To be fair though, I think we should single out one proposal at a time for discussion. As for m3overrides and private vs. public repositories, I think you are going to get a lot of push-back on the idea to always ship everything to the public repository. I for one, don't like this idea. I do agree that the compiler's idea of certain options, e.g., clean, may not match what everyone expects. Of course, many of us have written scripts, etc. that invoke the compiler with certain options and that do other "stuff" using some of the same terminology (e.g. clean, ship, build, buildship, realclean, zap, etc.). I am arguing that the terminology should be standardized to have a consistent meaning across all of these. Depending on the definitions, some code will need to change make the implementation match the definition. Regards, Randy >>> Jay 1/20/2009 1:03 AM >>> > [was truncated and forward to m3commit instead of m3devel, now more content/drivel..] ps: >> 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. "Clean" doesn't really work imho..I guess it deletes the output files that the compiler knows about? Perhaps it is a bug when the config file doesn't tell it about all the outputs? "realclean" deletes the entire output directory, no matter what files it thinks it produced. It does assume they are all in the particular directory that they strongly tend to be in. It's dumb imho. Clean should probably be fixed. The m3-sys/m3cc directory and probably m3gdb also have their own special in-between state of "configure having been one", that they create a marker file to indicate. And then there is an environment variable to override that. Quake is a fairly general purpose language including the ability to read environment variables, so various directories are free to do whatever they want. m3cc and m3gdb are two of the longest to build package and configuration is also a slow step, that "rarely" has different output, so going back only to this "partly built" state perhaps is interesting. I rarely do that, at least on purpose. The Linux kernel and ucLibc (an alternative C runtime) do something similar. They store their configuration in file starting with a dot, so that on Unix rm -rf * won't delete it, because it skips "hidden" "dot" files. As well you can define arbitrary things on the cm3 command line, to guide arbitrary decisions around the tree, such as kernel vs. user threads. Given foo\src build outputs are generally in foo\target where "outputs" include "intermediate" files such as object files and "final" outputs such as executables and .dlls. You know...really I think, it's just that the Modula-3 folks knew/thought they were smarter than everyone else and made up their own terminology. In many other projects you have "make" and "make install". "ship" is "make install". I think that is all people need to know: "ship" == "install". It copies some of the outputs from foo\target to the installroot. Just as "make install" copies some of the outputs from the "intermediate" tree to the "live" tree. They can both be "dangerous" on a live system, and they can both be pointed at "new" empty location for safety (typical GNU make/automake/autoconf install option is make install DESTDIR=somewhere). I propose a different model. Always put the "final" outputs directly in a "live" tree, BUT for the case where you are doing something "risky" and would not immediately "ship" / "install", you would be encouraged to define a new clean output root, or an existing "test" root. "Actual install" would then be just a recursive copy from one root to another. Perhaps that is too inefficient? cm3 tries to do an incremental copy for example. I'm not sure if it is timestamp based or if they compare entire file contents. The downside to this proposal is that source files also get shipped, and doing that for every compile/link is wasteful. This is optional though and maybe can/should be turned off except when "making a distribution"? I'm not sure how optional it is. I'll try out turning it off locally. An upside to this proposal is it supercedes the "override" mechanism. You would never need to "override". "override" imho is broken because today, in order to keep "override" working, you are expected to encode the source tree structure all over the place. This seems redundant. Perhaps another idea would be for CM3_INSTALL to be colon/semicolon delimited? Search multiple package stores? That offers functionality not in the current model. A related proposal I have is that even the intermediate files be relocated. As I said, on a package-by-package basis, they are not in the source tree. Good. But on a multi-package basis, they are. Not good. I want the source tree to have no outputs, to stay "clean", unless I edit a file. Concretely this all looks like: 1) There is already the CM3_INSTALL environment variable. That is where "binaries" should be output, in the same structure that "ship" uses today. 2) There shall be a new environment variable, something like CM3_OBJECT_ROOT. 3) The existing CM3_ROOT that is the root of the source tree shall come into play. Given building in CM3_ROOT/foo/bar output shall go into: CM3_OBJECT_ROOT/foo/bar/target or maybe CM3_OBJECT_ROOT/target/foo/bar or maybe CM3_OBJECT_ROOT/foo/bar instead of CM3_ROOT/foo/bar/target. If you are not building under CM3_ROOT, there are a few viable options. 1) Do things as they are today. 2) Form up a form of CM3_OBJECT_ROOT/the path you are building that is valid and predictable. For example, in Windows, given a full path with a colon in it, remove the colon and you have a valid relative path you can append to another root. 3) Give user a way to specify what their "root" or "relative path from root" is. Because outputs litter the source tree today..unless you engage in changing BUILD_DIR, which maybe is the way in a few ways actually..you can't do multiple concurrent builds of the same target, such as with a different %PATH% to a different cm3.exe. Now, there is already BUILD_DIR. Perhaps all this is as simple as a change in the config file, changing BUILD_DIR to something like CM3_ROOT/path_of(foo.m3)/TARGET. I'll try that later. Maybe it just works. ? I'm not confident it'll work but maybe. Am I crazy? Wrong? Too disruptive? Most likely the last. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3commit at elegosoft.com; rcoleburn at scires.com > Date: Tue, 20 Jan 2009 05:40:07 +0000 > Subject: [M3commit] FW: [M3devel] move to version 5.7.1? > > > [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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jan 20 19:32:46 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 20 Jan 2009 18:32:46 +0000 Subject: [M3devel] FW: move to version 5.7.1? In-Reply-To: <200901201439.n0KEdKr0094091@camembert.async.caltech.edu> References: Your message of "Tue, 20 Jan 2009 05:40:07 GMT." <200901201439.n0KEdKr0094091@camembert.async.caltech.edu> Message-ID: If it is part of the cm3 tree then I (for one) am ok with it. It would have to be part of the "min" set. Will it work on Windows or is it Posix-specific? Working on Windows is kind of the point in question, since the *.sh files are fine for Unix. JScript, Python, and maybe Quake should also do. Possible problem with Quake and Scheme is it won't work for bootstrapping from older release. Problem with JScript is it'll be Windows specific. Therefore you are stuck still with two (or three or four!) sets of files. Best to have one set that work "everywhere". Bash and Python don't have these problems, they work with older cm3 and on all platforms. (I reluctantly lump Bash in with Python as being good because I still haven't gotten around to get Python to compile on my MIPS64_OPENBSD system and use the Bash files on it.) Bootstrapping eventually isn't an issue, eventually. - Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Tue, 20 Jan 2009 06:39:20 -0800 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] FW: move to version 5.7.1? > > > Jay writes: > ... >>---------------------------------------- >>> 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 > ... >>> >>> 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. > > How about in Scheme? I have written/am writing a Scheme interpreter > in Modula-3 that I am happy to release with CM3; it's very easily > extensible (that's sort of the point of it), so one can easily add > low-level features to it as necessary. The system would be > self-contained with that interpreter. Maybe writing scripts in > Scheme is a little "weird"... (but I do it :-) ) > > Mika > From jay.krell at cornell.edu Tue Jan 20 19:50:40 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 20 Jan 2009 18:50:40 +0000 Subject: [M3devel] ship vs. where build outputs go, etc.? In-Reply-To: <4975BE3A.1E75.00D7.1@scires.com> References: <4974CB61.1E75.00D7.1@scires.com> <4975BE3A.1E75.00D7.1@scires.com> Message-ID: The point is it would not always be the "public" repositoy. Today we have two places, the source tree and the repository. They have different structures. Instead, you could just have multiple repositories. They would all have the same structure. "Install" or "ship" is just recursive copy from a "private" repository to the "public" repository, instead of arbitrary rearrangement of files. OR merely "blessing" a private repository and making it the new public repository, such as by setting and an environment variable or possibly delete/rename. You could get something closer to the current experience by having two environment variables, CM3_PUBLIC, CM3_PRIVATE. cm3 -buildship would output to CM3_PUBLIC. cm3 -build would output to CM3_PRIVATE. Ideally it would do no extra writes vs. the current scheme. "Upgrade" would look like: set CM3_PRIVATE= some new temporary place build everything if successful rm -rf CM3_PUBLIC mv CM3_PUBLIC CM3_PRIVATE See, today "upgrade" writes over the live system and is therefore "dangerous". In this new scheme, "ship" would lose much of its danger. Rather than making changes as it goes, the final "commit" would not occur until the end, and would be easier to keep backups and such. Granted, if you look at what make-dist does, this is already possible today, by twiddling with CM3_INSTALL and always shipping. Though that costs extra I/O and you do have to prepopulate CM3_INSTALL..at least with a compiler, eh, just two files. Also with m3core/libm3 in some bootstrapping scenarios. (make-dist assumes so, though it usually is not the case). Along with an alternate root for intermediate outputs, this would enable multiple concurrent builds as well. A similar proposal is that "CM3_PUBLIC" could be colon or semicolon delimited -- a "search path" for reads, write to the first location. This would probably be confusing if it contained more than two paths though. publlic/private is "limited" in that it only supports two, but you can always use recursive copy to merge. Fixing clean would not take away realclean as an option if that is necessary for compat (I forget if compiler even implements realclean; the scripts implement it and I always use that version). I find it hard to believe that anyone depends on that clean leaves a few files around. Which files does it even leave around? I'm not sure what is documented or not. Could be that a lot is? - Jay ________________________________ > Date: Tue, 20 Jan 2009 12:07:01 -0500 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] ship vs. where build outputs go, etc.? > > > > > > > > Jay: > > > > I think your email illustrates part of what I was trying to say in that there are a lot of things that aren't documented very well at this point that differ from the current documentation and practice that we've followed over the years. > > > > I'm not sure I agree with some of the proposals you offer. To be fair though, I think we should single out one proposal at a time for discussion. > > > > As for m3overrides and private vs. public repositories, I think you are going to get a lot of push-back on the idea to always ship everything to the public repository. I for one, don't like this idea. > > > > I do agree that the compiler's idea of certain options, e.g., clean, may not match what everyone expects. Of course, many of us have written scripts, etc. that invoke the compiler with certain options and that do other "stuff" using some of the same terminology (e.g. clean, ship, build, buildship, realclean, zap, etc.). I am arguing that the terminology should be standardized to have a consistent meaning across all of these. Depending on the definitions, some code will need to change make the implementation match the definition. > > > > Regards, > > Randy > >>>> Jay 1/20/2009 1:03 AM>>> > >> [was truncated and forward to m3commit instead of m3devel, now more content/drivel..] > > ps: > > >>> 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. > > > > "Clean" doesn't really work imho..I guess it deletes the output files > that the compiler knows about? Perhaps it is a bug when the > config file doesn't tell it about all the outputs? > > > "realclean" deletes the entire output directory, no matter what files it thinks it produced. > It does assume they are all in the particular directory that they strongly tend to be in. > > > It's dumb imho. > Clean should probably be fixed. > > > The m3-sys/m3cc directory and probably m3gdb also have their own special > in-between state of "configure having been one", that they create a marker > file to indicate. And then there is an environment variable to override that. > Quake is a fairly general purpose language including the ability to read > environment variables, so various directories are free to do whatever they want. > > > m3cc and m3gdb are two of the longest to build package and configuration is also a slow step, that "rarely" has different output, so going back only to this "partly built" state perhaps is interesting. I rarely do that, at least on purpose. > > > The Linux kernel and ucLibc (an alternative C runtime) do something similar. > They store their configuration in file starting with a dot, so that on Unix rm -rf * won't delete it, because it skips "hidden" "dot" files. > > > > As well you can define arbitrary things on the cm3 command line, to guide > arbitrary decisions around the tree, such as kernel vs. user threads. > > > Given > foo\src > build outputs are generally in > foo\target > > > where "outputs" include "intermediate" files such as object files and "final" outputs such as executables and .dlls. > > > You know...really I think, it's just that the Modula-3 folks knew/thought they were smarter than everyone else and made up their own terminology. > > > In many other projects you have "make" and "make install". > "ship" is "make install". I think that is all people need to know: "ship" == "install". > > > It copies some of the outputs from foo\target to the installroot. > Just as "make install" copies some of the outputs from the "intermediate" tree to the "live" tree. They can both be "dangerous" on a live system, and they can both be pointed at "new" empty location for safety (typical GNU make/automake/autoconf install option is make install DESTDIR=somewhere). > > > I propose a different model. > Always put the "final" outputs directly in a "live" tree, BUT for the case where you are doing something "risky" and would not immediately "ship" / "install", you would be encouraged to define a new clean output root, or an existing "test" root. > > > "Actual install" would then be just a recursive copy from one root to another. > Perhaps that is too inefficient? cm3 tries to do an incremental copy for example. > I'm not sure if it is timestamp based or if they compare entire file contents. > > > The downside to this proposal is that source files also get shipped, and doing that for every compile/link is wasteful. This is optional though and maybe can/should be turned off except when "making a distribution"? I'm not sure how optional it is. I'll try out turning it off locally. > > > An upside to this proposal is it supercedes the "override" mechanism. > You would never need to "override". > "override" imho is broken because today, in order to keep "override" working, you are expected to encode the source tree structure all over the place. This seems redundant. > > > Perhaps another idea would be for CM3_INSTALL to be colon/semicolon delimited? > Search multiple package stores? > That offers functionality not in the current model. > > > A related proposal I have is that even the intermediate files be relocated. > As I said, on a package-by-package basis, they are not in the source tree. > Good. But on a multi-package basis, they are. Not good. > > > I want the source tree to have no outputs, to stay "clean", unless I edit a file. > > > Concretely this all looks like: > 1) There is already the CM3_INSTALL environment variable. That is where "binaries" should be output, in the same structure that "ship" uses today. > > > 2) There shall be a new environment variable, something like CM3_OBJECT_ROOT. > > 3) The existing CM3_ROOT that is the root of the source tree shall come into play. > > > Given building in > CM3_ROOT/foo/bar > > > output shall go into: > CM3_OBJECT_ROOT/foo/bar/target > or maybe CM3_OBJECT_ROOT/target/foo/bar > or maybe CM3_OBJECT_ROOT/foo/bar > > > instead of CM3_ROOT/foo/bar/target. > > > If you are not building under CM3_ROOT, there are a few viable options. > 1) Do things as they are today. > 2) Form up a form of CM3_OBJECT_ROOT/the path you are building that is valid and predictable. For example, in Windows, given a full path with a colon in it, remove the colon and you have a valid relative path you can append to another root. > 3) Give user a way to specify what their "root" or "relative path from root" is. > > > Because outputs litter the source tree today..unless you engage in changing BUILD_DIR, which maybe is the way in a few ways actually..you can't do multiple concurrent builds of the same target, such as with a different %PATH% to a different cm3.exe. > > > Now, there is already BUILD_DIR. > Perhaps all this is as simple as a change in the config file, changing BUILD_DIR to something like CM3_ROOT/path_of(foo.m3)/TARGET. I'll try that later. > Maybe it just works. ? > I'm not confident it'll work but maybe. > > > Am I crazy? Wrong? Too disruptive? > Most likely the last. > > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3commit at elegosoft.com; rcoleburn at scires.com >> Date: Tue, 20 Jan 2009 05:40:07 +0000 >> Subject: [M3commit] FW: [M3devel] move to version 5.7.1? >> >> >> [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 rodney.bates at wichita.edu Tue Jan 20 22:04:34 2009 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Tue, 20 Jan 2009 15:04:34 -0600 Subject: [M3devel] [M3commit] FW: move to version 5.7.1? In-Reply-To: <200901201439.n0KEdKr0094091@camembert.async.caltech.edu> References: <200901201439.n0KEdKr0094091@camembert.async.caltech.edu> Message-ID: <49763C62.8050509@wichita.edu> I like the Scheme interpreter idea. I think Modula-3 partially refutes the oft-repeated argument that every programming language has a narrow range of suitability. Among the imperative languages, there's not a lot around that can beat it, even for specific application areas. Builtin complex and non-integer fixed-point arithmetic are about the only things I can think of. But the functional languages are an area Modula-3 doesn't cover. Actually, you can write a lot of code in functional style in Modula-3, including, I think, some polymorphic stuff, but it's syntactically an awfully lot more ponderous than in a traditional functional language. With a true functional language tied into the implementation, we could claim very broad coverage. Mika Nystrom wrote: > Jay writes: > ... >> ---------------------------------------- >>> 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 > ... >>> 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. > > How about in Scheme? I have written/am writing a Scheme interpreter > in Modula-3 that I am happy to release with CM3; it's very easily > extensible (that's sort of the point of it), so one can easily add > low-level features to it as necessary. The system would be > self-contained with that interpreter. Maybe writing scripts in > Scheme is a little "weird"... (but I do it :-) ) > > Mika > From jay.krell at cornell.edu Wed Jan 21 14:37:53 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 21 Jan 2009 13:37:53 +0000 Subject: [M3devel] chosing SIG_SUSPEND? In-Reply-To: References: Message-ID: Solaris at least currently has SIGRTMAX. I want to switch RTSignalC.c to "something" here. I can preserve compat, like #ifdef __sun SIGUSR2 #else.. or..? I could do #ifdef SIGUSR2 #define SIG_SUSPEND SIGUSR2 #elif defined(SIGRTMAX) #define SIG_SUSPEND SIGRTMAX #else #error #endif I'll go with a compatible version for now and you can change it if you want. I'll test on Linux/x86, FreeBSD (AMD64, but hopefully there is gcc -m32), Linux/PPC, Solaris, Cygwin, Darwin/PPC (uh, actually, no, Darwin isn't really relevant, but I'll make sure the result does what is intended.) It looks like SIGRTMAX is a function call on Solaris. This stuff is like broken, right? I mean, there's a small number of signals and there's no arbitration. People just take them over and hope nobody else cares. There's no way to just queue a function call to a thread, in portable/general? Windows has QueueUserAPC or SuspendThread (SuspendThread is dangerous, thread could be doing anything), QueueUserAPC only interrupts at certain times. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Wed, 21 Jan 2009 03:42:01 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] chosing SIG_SUSPEND? > > Choose SIGRTMAX first if defined, then SIGUSR2. I don't thing NSIG-1 > is reliable, but just works on some systems. > > On 21 Jan 2009, at 01:12, Jay wrote: > >> >> What is the algorithm for chosing SIG_SUSPEND? >> >> Something like: >> >> #include >> >> #ifdef __APPLE__ >> /* nothing -- SIG_SUSPEND not used */ >> #elif defined(NSIG) >> #define SIG_SUSPEND (NSIG - 1) >> #elif defined(_NSIG) >> #define SIG_SUSPEND (_NSIG - 1) >> #elif defined(SIGRTMAX) >> #define SIG_SUSPEND SIGRTMAX >> #else >> #define SIG_SUSPEND SIGUSR2 >> #endif >> >> ? >> >> Whatever it is, I think it should be in RTSignalC.c. >> >> - Jay > From jay.krell at cornell.edu Wed Jan 21 15:37:53 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 21 Jan 2009 14:37:53 +0000 Subject: [M3devel] FW: chosing SIG_SUSPEND? In-Reply-To: References: Message-ID: [truncated again] I'm almost done with this change..just trying to decide to put the constants in a new runtime/common/RTConstants.c or the existing unix/common/Uconstants.c. At first I had them in thread/PTHREAD/ThreadPThreadC.c, but that isn't compiled on user-thread only platforms. :( - Jay ---------------------------------------- > From: jay > To: hosking > CC: m3devel > Subject: RE: [M3devel] chosing SIG_SUSPEND? > Date: Wed, 21 Jan 2009 13:37:53 +0000 > > > Solaris at least currently has SIGRTMAX. > I want to switch RTSignalC.c to "something" here. > I can preserve compat, like > > #ifdef __sun > SIGUSR2 > #else.. > > or..? > > I could do > #ifdef SIGUSR2 > #define SIG_SUSPEND SIGUSR2 > #elif defined(SIGRTMAX) > #define SIG_SUSPEND SIGRTMAX > #else > #error > #endif > > I'll go with a compatible version for now and you can change it if you want. > I'll test on Linux/x86, FreeBSD (AMD64, but hopefully there is gcc -m32), > Linux/PPC, Solaris, Cygwin, Darwin/PPC (uh, actually, no, Darwin isn't > really relevant, but I'll make sure the result does what is intended.) > > It looks like SIGRTMAX is a function call on Solaris. > > This stuff is like broken, right? > I mean, there's a small number of signals and there's no arbitration. > People just take them over and hope nobody else cares. > > > There's no way to just queue a function call to a thread, in portable/general? > Windows has QueueUserAPC or SuspendThread (SuspendThread is dangerous, > thread could be doing anything), QueueUserAPC only interrupts at certain times. > > > - Jay > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Wed, 21 Jan 2009 03:42:01 +1100 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] chosing SIG_SUSPEND? >> >> Choose SIGRTMAX first if defined, then SIGUSR2. I don't thing NSIG-1 >> is reliable, but just works on some systems. >> >> On 21 Jan 2009, at 01:12, Jay wrote: >> >>> >>> What is the algorithm for chosing SIG_SUSPEND? >>> >>> Something like: >>> >>> #include >>> >>> #ifdef __APPLE__ >>> /* nothing -- SIG_SUSPEND not used */ >>> #elif defined(NSIG) >>> #define SIG_SUSPEND (NSIG - 1) >>> #elif defined(_NSIG) >>> #define SIG_SUSPEND (_NSIG - 1) >>> #elif defined(SIGRTMAX) >>> #define SIG_SUSPEND SIGRTMAX >>> #else >>> #define SIG_SUSPEND SIGUSR2 >>> #endif >>> >>> ? >>> >>> Whatever it is, I think it should be in RTSignalC.c. >>> >>> - Jay >> From jay.krell at cornell.edu Wed Jan 21 15:48:26 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 21 Jan 2009 14:48:26 +0000 Subject: [M3devel] FW: chosing SIG_SUSPEND? In-Reply-To: References: Message-ID: Oh partially nevermind -- user threads doesn't use SIG_SUSPEND. SIG_SUSPEND will go away and ThreadPThreadC.c will define SIG, which will be used by it and ThreadPThread.i3. No RTConstants.c, no change in Uconstants.c. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Date: Wed, 21 Jan 2009 14:37:53 +0000 > Subject: [M3devel] FW: chosing SIG_SUSPEND? > > > [truncated again] > > > I'm almost done with this change..just trying to decide > to put the constants in a new runtime/common/RTConstants.c > or the existing unix/common/Uconstants.c. > > At first I had them in thread/PTHREAD/ThreadPThreadC.c, > but that isn't compiled on user-thread only platforms. :( > > - Jay > > ---------------------------------------- >> From: jay >> To: hosking >> CC: m3devel >> Subject: RE: [M3devel] chosing SIG_SUSPEND? >> Date: Wed, 21 Jan 2009 13:37:53 +0000 >> >> >> Solaris at least currently has SIGRTMAX. >> I want to switch RTSignalC.c to "something" here. >> I can preserve compat, like >> >> #ifdef __sun >> SIGUSR2 >> #else.. >> >> or..? >> >> I could do >> #ifdef SIGUSR2 >> #define SIG_SUSPEND SIGUSR2 >> #elif defined(SIGRTMAX) >> #define SIG_SUSPEND SIGRTMAX >> #else >> #error >> #endif >> >> I'll go with a compatible version for now and you can change it if you want. >> I'll test on Linux/x86, FreeBSD (AMD64, but hopefully there is gcc -m32), >> Linux/PPC, Solaris, Cygwin, Darwin/PPC (uh, actually, no, Darwin isn't >> really relevant, but I'll make sure the result does what is intended.) >> >> It looks like SIGRTMAX is a function call on Solaris. >> >> This stuff is like broken, right? >> I mean, there's a small number of signals and there's no arbitration. >> People just take them over and hope nobody else cares. >> >> >> There's no way to just queue a function call to a thread, in portable/general? >> Windows has QueueUserAPC or SuspendThread (SuspendThread is dangerous, >> thread could be doing anything), QueueUserAPC only interrupts at certain times. >> >> >> - Jay >> >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Wed, 21 Jan 2009 03:42:01 +1100 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] chosing SIG_SUSPEND? >>> >>> Choose SIGRTMAX first if defined, then SIGUSR2. I don't thing NSIG-1 >>> is reliable, but just works on some systems. >>> >>> On 21 Jan 2009, at 01:12, Jay wrote: >>> >>>> >>>> What is the algorithm for chosing SIG_SUSPEND? >>>> >>>> Something like: >>>> >>>> #include >>>> >>>> #ifdef __APPLE__ >>>> /* nothing -- SIG_SUSPEND not used */ >>>> #elif defined(NSIG) >>>> #define SIG_SUSPEND (NSIG - 1) >>>> #elif defined(_NSIG) >>>> #define SIG_SUSPEND (_NSIG - 1) >>>> #elif defined(SIGRTMAX) >>>> #define SIG_SUSPEND SIGRTMAX >>>> #else >>>> #define SIG_SUSPEND SIGUSR2 >>>> #endif >>>> >>>> ? >>>> >>>> Whatever it is, I think it should be in RTSignalC.c. >>>> >>>> - Jay >>> From wagner at elegosoft.com Wed Jan 21 15:49:36 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 21 Jan 2009 15:49:36 +0100 Subject: [M3devel] ship vs. where build outputs go, etc.? In-Reply-To: References: <4974CB61.1E75.00D7.1@scires.com> <4975BE3A.1E75.00D7.1@scires.com> Message-ID: <20090121154936.64zgzaj280g884o0@mail.elegosoft.com> Quoting Jay : > > The point is it would not always be the "public" repositoy. > > > Today we have two places, the source tree and the repository. > They have different structures. > > > Instead, you could just have multiple repositories. > They would all have the same structure. > > > "Install" or "ship" is just recursive copy from a "private" > repository to the "public" repository, instead of > arbitrary rearrangement of files. This does only work reliably if you keep exact version info for all files in the derived package pools (I'd like to reserve the term repository for source repository). A repository contains the source code (complete with history), while package pools contain derived files (intermediate results). A third (complementing) notion would be a deployable package (an installable archive or package). CM3 checks the consistency of one build wrt. a package pool and allows shipping into this pool only if everything is OK. Thus any override must inhibit any shipping, as it is not guaranteed that the overriden packages are available in the pool (in this version). If you ship packages from one pool to the other, there is no consistency check at all, unless you know exactly what versions of packages are in both pools. > OR merely "blessing" a private repository and making it the new > public repository, such as by setting and an environment variable > or possibly delete/rename. > > You could get something closer to the current experience by having > two environment variables, CM3_PUBLIC, CM3_PRIVATE. > cm3 -buildship would output to CM3_PUBLIC. > cm3 -build would output to CM3_PRIVATE. > Ideally it would do no extra writes vs. the current scheme. I've got no problem with multiple package pools, but we need to consider carefully what operations will be needed and which ones are safe. > "Upgrade" would look like: > > set CM3_PRIVATE= some new temporary place > build everything > if successful > rm -rf CM3_PUBLIC > mv CM3_PUBLIC CM3_PRIVATE > > See, today "upgrade" writes over the live system and is therefore > "dangerous". In this new scheme, "ship" would lose much of its > danger. Rather than making changes as it goes, the final "commit" > would not occur until the end, and would be easier to keep backups > and such. Granted, if you look at what make-dist does, this is > already possible today, by twiddling with CM3_INSTALL and always > shipping. Though that costs extra I/O and you do have to prepopulate > CM3_INSTALL..at least with a compiler, eh, just two files. > Also with m3core/libm3 in some bootstrapping scenarios. > (make-dist assumes so, though it usually is not the case). You mix concepts from the base CM3 builder with concepts from the maintenance scripts. I never intended these scripts to be used as a general build system for the everyday M3 user. Indeed it does not keep any of the guarantees that M3 gives. > Along with an alternate root for intermediate outputs, this would > enable multiple concurrent builds as well. > > A similar proposal is that "CM3_PUBLIC" could be colon or semicolon > delimited -- a "search path" for reads, write to the first location. > This would probably be confusing if it contained more than two paths though. > publlic/private is "limited" in that it only supports two, but you can > always use recursive copy to merge. I could imagine the following extensions (without deep consideration of the consequences): o allow to ship to more than one package pool (but keep it consistent with the builds) o allow multiple package pools for imports (e.g. by using a package pool path) o allow shipping only if all imports come from the destination package pool (as it is now) > Fixing clean would not take away realclean as an option if that is necessary > for compat (I forget if compiler even implements realclean; the scripts > implement it and I always use that version). I find it hard to believe > that anyone depends on that clean leaves a few files around. > Which files does it even leave around? > > I'm not sure what is documented or not. Could be that a lot is? cm3 -clean should be correct insofar as it removes all derived files (that the compiler knows of). It only works if all imports can be found, which also means that cleaning must be done in the correct order. As the builder currently doesn't work on package sets but only on one package this turns out to be little useful for large projects. Thus the maintenance scripts introduced the realclean command. Again, this was not intended as a general end user solution. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Wed Jan 21 15:42:38 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 21 Jan 2009 09:42:38 -0500 Subject: [M3devel] chosing SIG_SUSPEND? In-Reply-To: References: Message-ID: <46D5FC1C-7F28-4C9B-83CD-8FE0E4290A56@cs.purdue.edu> Yes, we want a signal no-one else is using to stop the threads. On 21 Jan 2009, at 08:37, Jay wrote: > > Solaris at least currently has SIGRTMAX. > I want to switch RTSignalC.c to "something" here. > I can preserve compat, like > > #ifdef __sun > SIGUSR2 > #else.. > > or..? > > I could do > #ifdef SIGUSR2 > #define SIG_SUSPEND SIGUSR2 > #elif defined(SIGRTMAX) > #define SIG_SUSPEND SIGRTMAX > #else > #error > #endif > > I'll go with a compatible version for now and you can change it if > you want. > I'll test on Linux/x86, FreeBSD (AMD64, but hopefully there is gcc - > m32), > Linux/PPC, Solaris, Cygwin, Darwin/PPC (uh, actually, no, Darwin isn't > really relevant, but I'll make sure the result does what is intended.) > > It looks like SIGRTMAX is a function call on Solaris. > > This stuff is like broken, right? > I mean, there's a small number of signals and there's no arbitration. > People just take them over and hope nobody else cares. > > > There's no way to just queue a function call to a thread, in > portable/general? > Windows has QueueUserAPC or SuspendThread (SuspendThread is dangerous, > thread could be doing anything), QueueUserAPC only interrupts at > certain times. > > > - Jay > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Wed, 21 Jan 2009 03:42:01 +1100 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] chosing SIG_SUSPEND? >> >> Choose SIGRTMAX first if defined, then SIGUSR2. I don't thing NSIG-1 >> is reliable, but just works on some systems. >> >> On 21 Jan 2009, at 01:12, Jay wrote: >> >>> >>> What is the algorithm for chosing SIG_SUSPEND? >>> >>> Something like: >>> >>> #include >>> >>> #ifdef __APPLE__ >>> /* nothing -- SIG_SUSPEND not used */ >>> #elif defined(NSIG) >>> #define SIG_SUSPEND (NSIG - 1) >>> #elif defined(_NSIG) >>> #define SIG_SUSPEND (_NSIG - 1) >>> #elif defined(SIGRTMAX) >>> #define SIG_SUSPEND SIGRTMAX >>> #else >>> #define SIG_SUSPEND SIGUSR2 >>> #endif >>> >>> ? >>> >>> Whatever it is, I think it should be in RTSignalC.c. >>> >>> - 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: [M3devel] m3commit not working? Message-ID: I'm not seeing m3commit mail. - Jay From jay.krell at cornell.edu Thu Jan 22 02:19:43 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 22 Jan 2009 01:19:43 +0000 Subject: [M3devel] dependency on platform list removed Message-ID: I removed the dependency libm3 had on the list of platforms that the compiler has. This should make the system easier to build. You'll no longer get the error about SocketPosix and Compiler disagreeing. I thought m3core had a dependency that would harder to remove but I'm not sure. The SOLgnu Tinderbox had been failing due to this dependency but about the time I made the change, it started succeeding. (I thought Tinderbox ran "upgrade.sh" first, which gets around this.) Removing the dependency should actually be a /little/ more efficient as well, not noticably. A bunch of unused strings are removed from libm3. Even the ones remaining are a dubious error fallback. This could be viewed as a bad thing, since before there was a "check" that you had things up to date. Now more mixes can be used, for better or worse. - Jay From jay.krell at cornell.edu Thu Jan 22 02:34:38 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 22 Jan 2009 01:34:38 +0000 Subject: [M3devel] chosing SIG_SUSPEND? In-Reply-To: <46D5FC1C-7F28-4C9B-83CD-8FE0E4290A56@cs.purdue.edu> References: <46D5FC1C-7F28-4C9B-83CD-8FE0E4290A56@cs.purdue.edu> Message-ID: The code is now: #define SIG_SUSPEND ThreadPThreadC_SIG_SUSPEND /* expected values for compat, if compat matters: Solaris: 17 (at least 32bit SPARC?) Cygwin: 19 -- er, but maybe that's wrong Linux: 64 FreeBSD: 31 OpenBSD: 31 HPUX: 44 Look at the history of Usignal and RTMachine to find more values. There was RTMachine.SIG_SUSPEND and SIG was aliased to it. Both SIG and SIG_SUSPEND were only defined for systems using pthreads. SIG was shorthand. */ #if defined(__APPLE__) const int SIG_SUSPEND = 0; #elif defined(__sun) || defined(__CYGWIN__) || defined(__FreeBSD__) const int SIG_SUSPEND = SIGUSR2; #elif defined(__linux) const int SIG_SUSPEND = NSIG - 1; #elif defined(SIGRTMAX) /* This might be a function call, in which case try _SIGRTMAX or initializing it somewhere. */ const int SIG_SUSPEND = SIGRTMAX; #elif defined(SIGUSR2) const int SIG_SUSPEND = SIGUSR2; #else #error Unable to determine SIG_SUSPEND. #endif Compatible but perhaps not ideal. It'll automatically port to "something" now, less per-machine work. The #ifdefs are overly broad, since __sun and __FreeBSD__ will cover more than just older platforms but also newer ones -- need to check processor. "SIG" is gone, it was private and I think merely "shorthand", not important. Uses say SIG_SUSPEND. SIG_SUSPEND gone from RTMachine.i3 and in ThreadPThreadC.{c,i3} - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Wed, 21 Jan 2009 09:42:38 -0500 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] chosing SIG_SUSPEND? > > Yes, we want a signal no-one else is using to stop the threads. > > On 21 Jan 2009, at 08:37, Jay wrote: > >> >> Solaris at least currently has SIGRTMAX. >> I want to switch RTSignalC.c to "something" here. >> I can preserve compat, like >> >> #ifdef __sun >> SIGUSR2 >> #else.. >> >> or..? >> >> I could do >> #ifdef SIGUSR2 >> #define SIG_SUSPEND SIGUSR2 >> #elif defined(SIGRTMAX) >> #define SIG_SUSPEND SIGRTMAX >> #else >> #error >> #endif >> >> I'll go with a compatible version for now and you can change it if >> you want. >> I'll test on Linux/x86, FreeBSD (AMD64, but hopefully there is gcc - >> m32), >> Linux/PPC, Solaris, Cygwin, Darwin/PPC (uh, actually, no, Darwin isn't >> really relevant, but I'll make sure the result does what is intended.) >> >> It looks like SIGRTMAX is a function call on Solaris. >> >> This stuff is like broken, right? >> I mean, there's a small number of signals and there's no arbitration. >> People just take them over and hope nobody else cares. >> >> >> There's no way to just queue a function call to a thread, in >> portable/general? >> Windows has QueueUserAPC or SuspendThread (SuspendThread is dangerous, >> thread could be doing anything), QueueUserAPC only interrupts at >> certain times. >> >> >> - Jay >> >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Wed, 21 Jan 2009 03:42:01 +1100 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] chosing SIG_SUSPEND? >>> >>> Choose SIGRTMAX first if defined, then SIGUSR2. I don't thing NSIG-1 >>> is reliable, but just works on some systems. >>> >>> On 21 Jan 2009, at 01:12, Jay wrote: >>> >>>> >>>> What is the algorithm for chosing SIG_SUSPEND? >>>> >>>> Something like: >>>> >>>> #include >>>> >>>> #ifdef __APPLE__ >>>> /* nothing -- SIG_SUSPEND not used */ >>>> #elif defined(NSIG) >>>> #define SIG_SUSPEND (NSIG - 1) >>>> #elif defined(_NSIG) >>>> #define SIG_SUSPEND (_NSIG - 1) >>>> #elif defined(SIGRTMAX) >>>> #define SIG_SUSPEND SIGRTMAX >>>> #else >>>> #define SIG_SUSPEND SIGUSR2 >>>> #endif >>>> >>>> ? >>>> >>>> Whatever it is, I think it should be in RTSignalC.c. >>>> >>>> - Jay >>> > 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: [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: [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 jay.krell at cornell.edu Fri Jan 23 08:09:40 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 23 Jan 2009 07:09:40 +0000 Subject: [M3devel] chosing SIG_SUSPEND? In-Reply-To: <46D5FC1C-7F28-4C9B-83CD-8FE0E4290A56@cs.purdue.edu> References: <46D5FC1C-7F28-4C9B-83CD-8FE0E4290A56@cs.purdue.edu> Message-ID: I noticed in some of the code..I think for SegV, Quit,etc., not for thread suspension, that if the signalis already set to other than SIG_DFL, Modula-3 refrainsfrom changing it. So, I was thinking, would it be reasonable to iterate through, saySIGUSR1, SIGUSR2, and SIGRTMIN through SIGRTMAX, anduse the "first" one that isn't set to SIG_DFL?By "first", I don't mean to imply what order to check in,probably my statement has the order backwards.The point is to check them and not just hijack them. OR, is there another way to do this? Doesn't or can't the Modula-3 code "check a flag""every so often" and then voluntarily yield?Of course, the allocator would check the flag. Perhaps I just really need to get "that paper" into my head?Understand the issue around "other threads running intight computation loops for a long time", and therefore not checkingon yielding? Is the signal mechanism actually preemptive anyway? - Jay> From: hosking at cs.purdue.edu> To: jay.krell at cornell.edu> Date: Wed, 21 Jan 2009 09:42:38 -0500> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] chosing SIG_SUSPEND?> > Yes, we want a signal no-one else is using to stop the threads.> > On 21 Jan 2009, at 08:37, Jay wrote:> > >> > Solaris at least currently has SIGRTMAX.> > I want to switch RTSignalC.c to "something" here.> > I can preserve compat, like> >> > #ifdef __sun> > SIGUSR2> > #else..> >> > or..?> >> > I could do> > #ifdef SIGUSR2> > #define SIG_SUSPEND SIGUSR2> > #elif defined(SIGRTMAX)> > #define SIG_SUSPEND SIGRTMAX> > #else> > #error> > #endif> >> > I'll go with a compatible version for now and you can change it if > > you want.> > I'll test on Linux/x86, FreeBSD (AMD64, but hopefully there is gcc - > > m32),> > Linux/PPC, Solaris, Cygwin, Darwin/PPC (uh, actually, no, Darwin isn't> > really relevant, but I'll make sure the result does what is intended.)> >> > It looks like SIGRTMAX is a function call on Solaris.> >> > This stuff is like broken, right?> > I mean, there's a small number of signals and there's no arbitration.> > People just take them over and hope nobody else cares.> >> >> > There's no way to just queue a function call to a thread, in > > portable/general?> > Windows has QueueUserAPC or SuspendThread (SuspendThread is dangerous,> > thread could be doing anything), QueueUserAPC only interrupts at > > certain times.> >> >> > - Jay> >> >> > ----------------------------------------> >> From: hosking at cs.purdue.edu> >> To: jay.krell at cornell.edu> >> Date: Wed, 21 Jan 2009 03:42:01 +1100> >> CC: m3devel at elegosoft.com> >> Subject: Re: [M3devel] chosing SIG_SUSPEND?> >>> >> Choose SIGRTMAX first if defined, then SIGUSR2. I don't thing NSIG-1> >> is reliable, but just works on some systems.> >>> >> On 21 Jan 2009, at 01:12, Jay wrote:> >>> >>>> >>> What is the algorithm for chosing SIG_SUSPEND?> >>>> >>> Something like:> >>>> >>> #include> >>>> >>> #ifdef __APPLE__> >>> /* nothing -- SIG_SUSPEND not used */> >>> #elif defined(NSIG)> >>> #define SIG_SUSPEND (NSIG - 1)> >>> #elif defined(_NSIG)> >>> #define SIG_SUSPEND (_NSIG - 1)> >>> #elif defined(SIGRTMAX)> >>> #define SIG_SUSPEND SIGRTMAX> >>> #else> >>> #define SIG_SUSPEND SIGUSR2> >>> #endif> >>>> >>> ?> >>>> >>> Whatever it is, I think it should be in RTSignalC.c.> >>>> >>> - Jay> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Jan 23 14:27:39 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 23 Jan 2009 08:27:39 -0500 Subject: [M3devel] chosing SIG_SUSPEND? In-Reply-To: References: <46D5FC1C-7F28-4C9B-83CD-8FE0E4290A56@cs.purdue.edu> Message-ID: On 23 Jan 2009, at 02:09, Jay wrote: > I noticed in some of the code..I think for SegV, Quit, > etc., not for thread suspension, that if the signal > is already set to other than SIG_DFL, Modula-3 refrains > from changing it. > > So, I was thinking, would it be reasonable to iterate through, say > SIGUSR1, SIGUSR2, and SIGRTMIN through SIGRTMAX, and > use the "first" one that isn't set to SIG_DFL? > By "first", I don't mean to imply what order to check in, > probably my statement has the order backwards. > The point is to check them and not just hijack them. Maybe. I would argue the opposite: that M3 apps that use signals should avoid using the one dedicated to thread suspension. > OR, is there another way to do this? > > Doesn't or can't the Modula-3 code "check a flag" > "every so often" and then voluntarily yield? > Of course, the allocator would check the flag. This is a reasonable approach for Modula-3-compiled code: the polling points are called GC-safe-points. You just need to insert poll-points on backward branches and calls. The real problem is stopping threads that are off in native code and system calls. We could wrap every native call with a code to save GC-relevant state before going native, and then check the flag on return from native in case a GC is in progress. Many Java implementations use that approach. > Perhaps I just really need to get "that paper" into my head? > Understand the issue around "other threads running in > tight computation loops for a long time", and therefore not checking > on yielding? > > Is the signal mechanism actually preemptive anyway? Preemptive in what sense? Depending on the OS, signals tend to get delivered at system calls or thread context-switches. > > > - Jay > > > > > > > > From: hosking at cs.purdue.edu > > To: jay.krell at cornell.edu > > Date: Wed, 21 Jan 2009 09:42:38 -0500 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] chosing SIG_SUSPEND? > > > > Yes, we want a signal no-one else is using to stop the threads. > > > > On 21 Jan 2009, at 08:37, Jay wrote: > > > > > > > > Solaris at least currently has SIGRTMAX. > > > I want to switch RTSignalC.c to "something" here. > > > I can preserve compat, like > > > > > > #ifdef __sun > > > SIGUSR2 > > > #else.. > > > > > > or..? > > > > > > I could do > > > #ifdef SIGUSR2 > > > #define SIG_SUSPEND SIGUSR2 > > > #elif defined(SIGRTMAX) > > > #define SIG_SUSPEND SIGRTMAX > > > #else > > > #error > > > #endif > > > > > > I'll go with a compatible version for now and you can change it if > > > you want. > > > I'll test on Linux/x86, FreeBSD (AMD64, but hopefully there is > gcc - > > > m32), > > > Linux/PPC, Solaris, Cygwin, Darwin/PPC (uh, actually, no, Darwin > isn't > > > really relevant, but I'll make sure the result does what is > intended.) > > > > > > It looks like SIGRTMAX is a function call on Solaris. > > > > > > This stuff is like broken, right? > > > I mean, there's a small number of signals and there's no > arbitration. > > > People just take them over and hope nobody else cares. > > > > > > > > > There's no way to just queue a function call to a thread, in > > > portable/general? > > > Windows has QueueUserAPC or SuspendThread (SuspendThread is > dangerous, > > > thread could be doing anything), QueueUserAPC only interrupts at > > > certain times. > > > > > > > > > - Jay > > > > > > > > > ---------------------------------------- > > >> From: hosking at cs.purdue.edu > > >> To: jay.krell at cornell.edu > > >> Date: Wed, 21 Jan 2009 03:42:01 +1100 > > >> CC: m3devel at elegosoft.com > > >> Subject: Re: [M3devel] chosing SIG_SUSPEND? > > >> > > >> Choose SIGRTMAX first if defined, then SIGUSR2. I don't thing > NSIG-1 > > >> is reliable, but just works on some systems. > > >> > > >> On 21 Jan 2009, at 01:12, Jay wrote: > > >> > > >>> > > >>> What is the algorithm for chosing SIG_SUSPEND? > > >>> > > >>> Something like: > > >>> > > >>> #include > > >>> > > >>> #ifdef __APPLE__ > > >>> /* nothing -- SIG_SUSPEND not used */ > > >>> #elif defined(NSIG) > > >>> #define SIG_SUSPEND (NSIG - 1) > > >>> #elif defined(_NSIG) > > >>> #define SIG_SUSPEND (_NSIG - 1) > > >>> #elif defined(SIGRTMAX) > > >>> #define SIG_SUSPEND SIGRTMAX > > >>> #else > > >>> #define SIG_SUSPEND SIGUSR2 > > >>> #endif > > >>> > > >>> ? > > >>> > > >>> Whatever it is, I think it should be in RTSignalC.c. > > >>> > > >>> - Jay > > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Fri Jan 23 15:01:49 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 23 Jan 2009 06:01:49 -0800 Subject: [M3devel] chosing SIG_SUSPEND? In-Reply-To: Your message of "Fri, 23 Jan 2009 08:27:39 EST." Message-ID: <200901231401.n0NE1ngq007378@camembert.async.caltech.edu> Tony Hosking writes: > ... >> probably my statement has the order backwards. >> The point is to check them and not just hijack them. > >Maybe. I would argue the opposite: that M3 apps that use signals >should avoid using the one dedicated to thread suspension. I agree! Signals are not the Modula-3 Way. Something you mess with only when you're trying to interface with C code that hasn't heard of "threads". Yuck. ... >> Is the signal mechanism actually preemptive anyway? > >Preemptive in what sense? Depending on the OS, signals tend to get >delivered at system calls or thread context-switches. Isn't the whole point of signals to interrupt a computation...? ctrl-C, ctrl-Z, ctrl-\, SIGALRM, etc.... Mika From rcoleburn at scires.com Mon Jan 26 01:43:27 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 25 Jan 2009 19:43:27 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20090125163615.DABA3904003@birch.elegosoft.com> References: <20090125163615.DABA3904003@birch.elegosoft.com> Message-ID: <497CC069.1E75.00D7.1@scires.com> Jay: Please explain what you are doing here. I don't want to break stuff just to make extremely old and no longer supported toolsets work. My recollection is that the cvtres program is used in getting icon resources et al added to the executable. I know that the CM3IDE package is dependent on the WindowsResources package as are a lot of my programs. If you make changes here, we need to make sure it doesn't break existing stuff. Also, if there is a better way to go about it, I don't mind learning, but we will need to deal with making everything that depends on windowsResources continue to work. Regards, Randy >>> Jay Krell 1/25/2009 5:36 PM >>> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 26 02:50:35 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 26 Jan 2009 01:50:35 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <497CC069.1E75.00D7.1@scires.com> References: <20090125163615.DABA3904003@birch.elegosoft.com> <497CC069.1E75.00D7.1@scires.com> Message-ID: There is never any need to run cvtres. I have never seen anyone do this. You just pass the .res file to the linker and it works. I would turn things around and ask why it was written this way in the first place, different than all other systems? I can imagine one very marginal very minor point. If the .res file is linked into multiple executables, there might be microscropic build perf win in running cvtres once. I would like further simplification here but I didn't do the research needed. In particular, I don't think clients should have to say if equal (TARGET, "WIN32"). The Quake code already does that, but you'd have to make sure the package is shipped for all platforms so they have the .tmpl file. - Jay _______________________________ > Date: Sun, 25 Jan 2009 19:43:27 -0500 > From: rcoleburn at scires.com > To: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Jay: > > > > Please explain what you are doing here. I don't want to break stuff just to make extremely old and no longer supported toolsets work. > > > > My recollection is that the cvtres program is used in getting icon resources et al added to the executable. I know that the CM3IDE package is dependent on the WindowsResources package as are a lot of my programs. If you make changes here, we need to make sure it doesn't break existing stuff. > > > > Also, if there is a better way to go about it, I don't mind learning, but we will need to deal with making everything that depends on windowsResources continue to work. > > > > Regards, > > Randy > >>>> Jay Krell 1/25/2009 5:36 PM>>> > 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 jay.krell at cornell.edu Wed Jan 28 15:37:20 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 28 Jan 2009 14:37:20 +0000 Subject: [M3devel] gratuitous platform differences? Message-ID: I'm looking to add user thread support to the stuff I'm working on. As part of this, I'm surveying various platform-specific code, to find the commonality. Some of this should be common Modula-3 code. Where there are dealings with struct sigaction or sigset_t, the code should be rewritten in C to avoid requiring other additional platform-dependent code. It seems to me that many of the differences are gratuitous. Here are two: - some platforms unmap, or at least take away write access, to the last page in the stack; and then remap it (or add back write access) before disposing Now, I'm not going to move all ports to "my rewritten headers", just ones that I can test and are "somewhat active". In this case, I think that leads to all platforms being the same. So the question of "why not always do this?" doesn't matter. - Regarding disallow_sigvtalrm, allow_sigvtalrm, some platforms initialize the mask in the module's initializer, some recreate it for every call. Is there a reason for this? Creating it once is faster. But does require the initializer run early enough. And one would hope that the cached struct isn't too huge and memory wasting. To be safe, I could just provide two versions here, one that makes the mask over and over, one that does not. - Jay From jay.krell at cornell.edu Wed Jan 28 15:57:17 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 28 Jan 2009 14:57:17 +0000 Subject: [M3devel] sigbus? Message-ID: Here is something very suspicious, that I find by comparing similar platform-specific code to other similar platforms, trying to find what needs to be forked or #ifdefed per-platfform and why: All the Darwin ports, and no other ports, have: C:\dev2\cm3.2\m3-libs\m3core\src\runtime\AMD64_DARWIN\RTSignal.m3(34): SetHandler (6, Usignal.SIGBUS, SegV); but none of them do anything with SIGBUS in RestoreHandlers. - It must be a mistake to not RestoreHandler, right? - Either all of the ports should handle SIGBUS, or none of them, right? At least if all the underlying platforms define it? Granted, no x86 or AMD64 platform is likely to ever issue it, but maybe for, like, using sse or cmpxchg 8b? - Jay From jay.krell at cornell.edu Wed Jan 28 16:56:42 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 28 Jan 2009 15:56:42 +0000 Subject: [M3devel] gratuitous platform differences? In-Reply-To: References: Message-ID: Another difference is that some platforms set the last page of the stack to be PROT_NONE, while others use PROT_READ, with a comment: (* The protection should be 0, but making the page read-only is good enough to prevent unchecked runtime errors *) except ALPHA_OSF says: (* The protection should be 0, but a bug in MIPS/Ultrix 4.2 (vmdup) causes kernel panics when it is. Making the page read-only is good enough to prevent unchecked runtime errors *) Also, whenever calling Usignal stuff, there are three styles i := Usignal.something() WITH i = Usignal.something() DO END; EVAL Usignal.something() It COULD be that the functions fail on some platforms and EVAL is used to ignore the result. I favor the first style -- I find that code should avoid indentation in general -- given a choice between an if/else and if/continue, I'll use if/continue, adding a local variable or using WITH, add a local variable. Etc. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Wed, 28 Jan 2009 14:37:20 +0000 > Subject: [M3devel] gratuitous platform differences? > > > I'm looking to add user thread support to the stuff I'm working on. > As part of this, I'm surveying various platform-specific code, > to find the commonality. > Some of this should be common Modula-3 code. > Where there are dealings with struct sigaction or sigset_t, the > code should be rewritten in C to avoid requiring other additional > platform-dependent code. > > > It seems to me that many of the differences are gratuitous. > > > Here are two: > > > - some platforms unmap, or at least take away write access, to the > last page in the stack; and then remap it (or add back write access) > before disposing > Now, I'm not going to move all ports to "my rewritten headers", > just ones that I can test and are "somewhat active". > In this case, I think that leads to all platforms being the same. > So the question of "why not always do this?" doesn't matter. > > > - Regarding disallow_sigvtalrm, allow_sigvtalrm, some platforms > initialize the mask in the module's initializer, some recreate it > for every call. > Is there a reason for this? > Creating it once is faster. > But does require the initializer run early enough. > And one would hope that the cached struct isn't too huge and memory wasting. > > > To be safe, I could just provide two versions here, one that makes the mask > over and over, one that does not. > > > - Jay From jay.krell at cornell.edu Wed Jan 28 17:04:34 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 28 Jan 2009 16:04:34 +0000 Subject: [M3devel] gratuitous platform differences? In-Reply-To: References: Message-ID: (There is an ASSERT in two of the styles, but it apparently got removed by some buggy mail software in the stack..) - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Wed, 28 Jan 2009 15:56:42 +0000 > Subject: Re: [M3devel] gratuitous platform differences? > > > Another difference is that some platforms set the last page of the stack to be PROT_NONE, while others use PROT_READ, with a comment: > > (* The protection should be 0, but making the page read-only > is good enough to prevent unchecked runtime errors *) > > except ALPHA_OSF says: > > (* The protection should be 0, but a bug in MIPS/Ultrix 4.2 (vmdup) > causes kernel panics when it is. Making the page read-only > is good enough to prevent unchecked runtime errors *) > > Also, whenever calling Usignal stuff, there are three styles > > i := Usignal.something() > > > > WITH i = Usignal.something() DO > > END; > > > EVAL Usignal.something() > > > > It COULD be that the functions fail on some platforms and EVAL is used to ignore the result. > I favor the first style -- I find that code should avoid indentation in general -- given a choice between an if/else and if/continue, I'll use if/continue, adding a local variable or using WITH, add a local variable. Etc. > > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Wed, 28 Jan 2009 14:37:20 +0000 >> Subject: [M3devel] gratuitous platform differences? >> >> >> I'm looking to add user thread support to the stuff I'm working on. >> As part of this, I'm surveying various platform-specific code, >> to find the commonality. >> Some of this should be common Modula-3 code. >> Where there are dealings with struct sigaction or sigset_t, the >> code should be rewritten in C to avoid requiring other additional >> platform-dependent code. >> >> >> It seems to me that many of the differences are gratuitous. >> >> >> Here are two: >> >> >> - some platforms unmap, or at least take away write access, to the >> last page in the stack; and then remap it (or add back write access) >> before disposing >> Now, I'm not going to move all ports to "my rewritten headers", >> just ones that I can test and are "somewhat active". >> In this case, I think that leads to all platforms being the same. >> So the question of "why not always do this?" doesn't matter. >> >> >> - Regarding disallow_sigvtalrm, allow_sigvtalrm, some platforms >> initialize the mask in the module's initializer, some recreate it >> for every call. >> Is there a reason for this? >> Creating it once is faster. >> But does require the initializer run early enough. >> And one would hope that the cached struct isn't too huge and memory wasting. >> >> >> To be safe, I could just provide two versions here, one that makes the mask >> over and over, one that does not. >> >> >> - Jay From jay.krell at cornell.edu Thu Jan 29 18:10:53 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 29 Jan 2009 17:10:53 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <495B901F.1E75.00D7.1@scires.com> References: <20081231105208.9CF4710D5DDE@birch.elegosoft.com> <495B4846.1E75.00D7.1@scires.com> <495B901F.1E75.00D7.1@scires.com> Message-ID: > In reading your post, you state that you deoptimized the native implementation > to make it match Cygwin. Now, I'm not sure how I was wrong on this point. Cygwin's setjmp.h incorrectly typedefs jmp_buf, indeed, to be much larger than "native", but the header is incorrect. Cygwin actually has a slightly smaller jmp_buf than native (13 ints vs. 16 ints), but we use the native size always, deoptimizing the Cygwin case. - Jay ________________________________ > Date: Wed, 31 Dec 2008 15:30:40 -0500 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > > > > > Jay: > > > > First, I do want to say thanks for all you are doing for the cause of Modula-3. I don't think we say thanks enough for what others do for us. THANK YOU! > > > > I don't want to be perceived as "complaining", rather I am trying to voice my opinion in the hopes of influencing future direction. Of course, since I'm not doing the work, I can only make suggestions. > > > > In reading your post, you state that you deoptimized the native implementation to make it match Cygwin. Now, I'm not sure how much effect this deoptimization has (maybe little), but it is clear that in this case your implementation choice has favored the non-native implementation over the native one. IMO, tradeoffs of this type are not good. If one is trying to convince someone to use Modula-3, why would you want to give them a "deoptimized" version just to make it easier to support a non-native environment---indeed, one that they may not even want/use? If we have to make a trade-off, I say favor the native implementation always over the non-native one. > > > > What I'm trying to say here is that my experience as a software, systems, and program engineer is that I've always been forced to justify the cost/benefit of development tools for any project. Many times I've had to go head to head with folks higher up in my own organization or in the customer's organization whose preconceived opinions were based on rumor and what they've heard rather than actual factual hands-on experience. I want to pick the best tool for the job instead of being forced to pick an inferior tool because someone higher in the food chain demanded it based on faulty preconceived opinion. I like Modula-3. I've found that I am more productive using it. But, if the compiler doesn't produce efficient code, I lose ground in arguing with the higher-ups. > > > > As for Python, I've never ventured to learn it, so for me, it is something of a mystery. But you miss the point. I'm not arguing the merits of Python, I'm just saying that anything Modula-3 requires on top of what is provided by the standard host platform represents a potential obstacle or barrier to ease of use/implementation. It also sends the message that somehow Modula-3 is not complete on its own, we have get Python just to install and oh yes we need a C compiler and a linker and a ...? IMO, ultimately we need a turn-key download and install routine for Modula-3 that just works, out-of-the-box. If you give me an EXE, a CMD, or a BAT, for the install, I can run it on Windows, but if you give me an install routine that requires I first install something else, e.g. Python, then that becomes a barrier to the folks who don't know Python or already have it installed. > > > > Am I alone in this line of thought? If so, I'll just be quiet. > > > > BTW, I can certainly help in maintaining the CMD/BAT install routines or in making a better CMINSTALL. My problem is that right now, it is hard to understand all the dependencies for proper building of cm3 from scratch. Indeed, I've contributed some CMD/BAT install stuff in the past, but it is now out of date. Perhaps if there is a way we could better document the proper build order and dependencies, it would be easier for folks in the community to help in this area. I certainly would volunteer to do the CMD files as long as I had enough information to do it right. At one point, I thought we had a file that showed the package build order and dependencies. Not sure if the format of this file is well-documented or if the file is kept up-to-date. > > > > Regards, > > Randy > > >>>> Jay 12/31/2008 1:34 PM>>> >> you've made the CYGWIN implementation "appear" >> be the same as the native Windows implementation. >> But they are not the same. > > > But they mostly are, from the front end's point of view. > They are both little endian, x86, use the same jump_buf size (I grew it to match Cygwin's, which is a deoptimization of stack use on native NT386), the same type sizes and alignments..er..not sure about LONGINT. > They might vary in newline and one uses the internal backend and one the external, however which backend they use is actually minor to the front end, though I think it affects if the front end "deals with" calling conventions, particularly left-to-right vs. right-to-left and struct returns. > Object code produced by one can generally be linked with object code produced by the other. > > > SOLgnu and SOLsun are a better example of this, though they do go ahead and duplicate tons of stuff that if I had implemented them, I would have avoided. > They are truly identical in every respect in the front end and back end. > They only vary in the config file. > This is wasteful, because, "by default", if I'm put together a comprehensive cross build system without being a little smarter, I end up building two identical m3cgs. My config files are willing to "probe across" SOLsun and SOLgnu though, so I need only one m3cg for the two of them. > > > Given that "NT386" can describe a combinatorial explosion of configurations, it makes some sense to keep it just one if possible. The compiler mostly doesn't care. > > > >> "- BUILD_DIR does not necessarily equal HOST or TARGET, >> because of how I structured I386_CYGWIN to be a "configuration" >> where TARGET is still NT386." > >> IMO, it would be wrong to change the meaning of things like "BUILD_DIR", "HOST", and "TARGET". > > BUILD_DIR also does not equal HOST or TARGET when doing profiled builds, which admittedly I never have. > Therefore, BUILD_DIR is arbitrary. > I might be confusing something here though -- since I have never built a profiled build, I also haven't shipped one. It could be that "shipped BUILD_DIR" does equal TARGET, for profiled builds, in which case I did set a precedent. But the "override" code isn't using shipped files, so.. > I have to check. > >> as long as it does not compromise the native Windows implementation > > Agreed and it basically doesn't. > Show me where it does. > The only thing I can think of is the jmpbuf size. > >> I don't want to have to install CYGWIN either in order to make >> the native implementation work on Windows. > > Please don't complain about stuff that isn't true or without being more specific. > I know of no dependency by the native implementation on Cygwin. > > In fact, installing Cygwin does tend to break the native implementation, depending on $PATH, because it has a link.exe that is a completely different program (ie: ln.exe). > I tried experimenting with using cl to drive link.exe but couldn't quite get it to work, for stupid reasons related to response files, which surely is fixable by extending response file support in cm3... > > As it is, I usually delete \cygwin\bin\link.exe, or remove cygwin from $PATH. > True, I don't ever uninstall Cygwin for testing, so the dependency could creep in by accident. > > >> I also still prefer the CMINSTALL, CMD, or BAT files >> for install as opposed to having to get Python or something else. Just my 2 cents. > > Once built and installed, there is no dependency on cmd, bat, cminstall, or python. > cminstall is pretty worthless imho, as long as you set PATH, INCLUDE, and LIB. > That is also a competing workaround for paths with spaces. > And allows moving around among different versions of Visual C++, which is good and bad. > Either you can have n installs of cm3, each configured tightly for one specific Visual C++, > or you can have 1 install of cm3, that is flexibly configured, that you "reconfigure" by altering the environment. I do the second. > > If you want to build the system, in a well automated way, with cmd and bat, you are welcome to write them. > Maybe the ones I left in the tree work, but i never use them any longer. > I use the Python all the time. > > Or you can manually cd around (as I suspect Tony does). > Personally I find cmd/bat among the worst programming languages ever and would rather not write it. > jscript via cscript.exe would be a good alternative, it is always there at least as of Windows 2000 or perhaps with IE installed on older versions, but then you have to duplicate work across Unix and Windows. > That is, for Windows-only no-cmd, no-install command line automation, JScript and VBScript are good choices, but Windows-only rules them out. The install is worth it. > Python is a very decent programming language that is very portable across "all" systems. > Perl would be the next best choice, though..I just don't like much. > sh/bash requires an install on Windows, so its built-inness on Posix I claim isn't a conclusive win. > I strongly encourage you to try out Python. > > Another avenue is to merge the sh/cmd/python into cm3 itself. > It shouldn't be all that hard. > > Modula-3 still needs a C linker. > And there is C code that I didn't put in -- hand.c and dtoa.c. > If someone writes a linker in Modula-3, or gets the .obj loader working, I'll be more open to eliminating C. > > But using C is much less error prone and much more portable, in some parts of the system. > > You may label C as "evil", but the other "evil" I am battling is tedious error prone "header cloning". > You pretty much must chose one. > The header cloning can be reduced, and its error proned-ness and difficulty various per system, depending on how gnarled up the headers are with ifdefs, compatibility hacks, processor-specificty, "cleansing" (where the installed headers are processor specific, deriving from #ifdef'ed or somesuch other files, but now I argue both sides, #ifdef is hard to read, but removing them removes information unless you track further back), etc. For example the OpenBSD headers are much more readable. I suspect NetBSD are too but haven't looked yet. The Linux headers contain a lot of #ifdef and they are also processor-specific I think -- you know, my /usr/include/errno.h on one system I think didn't show that x86 and SPARC use different values. > > > - Jay > > > > ________________________________ > > > Date: Wed, 31 Dec 2008 10:28:37 -0500 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay: > > > > Please explain what you mean by: > > > > "- BUILD_DIR does not necessarily equal HOST or TARGET, > because of how I structured I386_CYGWIN to be a "configuration" > where TARGET is still NT386." > > > > IMO, it would be wrong to change the meaning of things like "BUILD_DIR", "HOST", and "TARGET". Indeed, I have stuff that depends on the meaning of these things. Your statement seems to imply that "under the covers" you've made the CYGWIN implementation "appear" to be the same as the native Windows implementation. But they are not the same. > > > > On another note, All this CYGWIN stuff may be a nice way for die-hard Unix fans to run Modula-3 on Windows, and I have no objection to providing it, as long as it does not compromise the native Windows implementation. My main concern is the native implementation of Modula-3 on Windows. My preference would be to keep the NT386 implementation's dependencies on other stuff to a bare minimum, i.e., don't introduce anything that would require someone to have to acquire something besides what comes in the standard Windows OS in order to make Modula-3 run. As it is now, we already have to get a C compiler and linker. Fortunately, Microsoft has made the Visual Studio Express editions a free download, so this is not too bad. I don't want to have to install CYGWIN either in order to make the native implementation work on Windows. I also still prefer the CMINSTALL, CMD, or BAT files for install as opposed to having to get Python or something else. Just my 2 cents. > > > > Finally, I would go a step further and suggest that the Modula-3 implementation on every platform should strive to require minimal dependencies on anything not provided standard with that platform's operating system. > > > > Call me an idealist, but it just galls me that I have to have a C compiler/linker to build Modula-3. Modula-3 is a systems programming language. It should stand on its own. From a purely economical viewpoint, why should I have to buy something I don't want (C language development environment) in order to have the privilege of using what I do want (Modula-3 language development environment). > > > > Regards, > > Randy > >>>> Jay Krell 12/31/2008 11:52 AM>>> > CVSROOT:/usr/cvs > Changes by:jkrell at birch.08/12/31 11:52:08 > > Modified files: > cm3/m3-comm/netobj/src/: netobj-ov.tmpl > cm3/m3-comm/sharedobj/src/: sharedobj-ov.tmpl > cm3/m3-libs/libm3/src/bundleintf/: bundle-ov.tmpl > cm3/m3-ui/zeus/src/: m3zume-ov.tmpl > cm3/m3-ui/juno-2/juno-app/src/: m3makefile > > Log message: > Partly kinda sorta fix some cross build scenarios, without > affecting native builds. > > It's a larger more general problem though. > > - BUILD_DIR does not necessarily equal HOST or TARGET, > because of how I structured I386_CYGWIN to be a "configuration" > where TARGET is still NT386. > > - a cross build can run the shipped binary anyway, > and probably should (I didn't have the unshipped binaries around) > > - There should probably be automation to ensure all the tools are build. > ie: do-cm3-tools or do-cm3-crosstools. ie: build just the needed packages, > for the sniffed native platform. > > Cross builds have other problems. > > I keep hitting the following annoyances: > > ignoring foo/bar override when foo\bar already overridden > override paths should either be canonicalized to one slash type > or at least when there is a duplicate, canonicalize then and only > complain if canonicals vary > This is due to mixing I386_NT and I386_CYGWIN. > Similarly the problem demonstrated regarding m3unix.h in Uwaitpid.quake. > > Perhaps the change I made to allow forward slashes on Win32 was not good, esp. due to > its apparent inadequacy. > > The "lib" directory, specifically \cm3\lib\hand.obj is target..er, configuration dependent > the gcc hand.obj cannot be directly linked by Visual C++, for reasons to do with libgcc > > lib should probably have "target" or "build_dir" under it > > and/or hand.obj specifically should be merged into m3core.lib > > The mentor quake code generally fails in cross environments, probably due to slashes. > > host=NT386 (GNU?), target=LINUXLIBC6 m3zume is access violating > > I'm also highly suspicious of all this "override" stuff. > It clearly causes too much duplication and distribution of information. > I shouldn't have to know the directory structure of my dependencies, > and even if I do, I should be able to share that knowledge with their many > other dependents. The "scripts" directory also figures this sort of stuff out automatically.. > Being able to have multiple package stores is well and good. > I'm not sure they need to ever be used in an "unshipped" form, but instead just > use alternate roots and create new empty roots as needed. ? > > From rodney.bates at wichita.edu Thu Jan 29 22:43:37 2009 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 29 Jan 2009 15:43:37 -0600 Subject: [M3devel] Semantics of HasWideChars Message-ID: <49822309.7030407@wichita.edu> CM3's Text.HasWideChars, as implemented, has some strange behavior. From Text.i3: PROCEDURE HasWideChars (t: T): BOOLEAN; (* Returns "TRUE" if "t" contains any "WIDECHAR" characters. *) This reads to me like it refers to the actual characters comprising t, which also makes sense to a client of this interface. In fact, the implementation returns TRUE if the internal representation used is capable of representing any wide characters, even though they could all be narrow. Some examples: Text.HasWideChars(W"ABC") = TRUE Text.HasWideChars(W"ABC"&"def") = TRUE Text.HasWideChars(Text.Sub(W"ABC"&"def",3,3)) = FALSE Text.HasWideChars(Text.Sub(W"ABC"&"def",2,3)) = TRUE These results have nothing to do with the abstract view of TEXT as a string of characters. Moreover, a principal reason a client of Text would call HasWideChars would be to know whether it could subsequently call, e.g., Text.GetChar without having the value silently truncated to 8 bits. So I propose to fix HasWideChars. This will entail some performance penalties, as in many cases, it will have to go through the character values one at at time in a loop and range-check each one. The alternative would be to redefine HasWideChars as a one-sided approximation, (which is really is now) i.e., such that a result of FALSE means the string is guaranteed to contain no wide characters, but TRUE only means the real answer is unknown. Not very useful, and in that case, it really should be be renamed MightHaveWideChars. What do others think? Anybody using GetWideChars who would be affected? Rodney Bates From hosking at cs.purdue.edu Fri Jan 30 04:43:24 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 30 Jan 2009 14:43:24 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20090130032538.030B410D5DAA@birch.elegosoft.com> References: <20090130032538.030B410D5DAA@birch.elegosoft.com> Message-ID: Probably the wrong place for this. If it is x86-dependent it should go somewhere in the x86 hierarchy, not in a top-level directory like "context". On 30 Jan 2009, at 04:25, Jay Krell wrote: > 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 wagner at elegosoft.com Fri Jan 30 12:19:29 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 30 Jan 2009 12:19:29 +0100 Subject: [M3devel] Semantics of HasWideChars In-Reply-To: <49822309.7030407@wichita.edu> References: <49822309.7030407@wichita.edu> Message-ID: <20090130121929.vz7bla8tm8sc8ggk@mail.elegosoft.com> Quoting "Rodney M. Bates" : > CM3's Text.HasWideChars, as implemented, has some strange behavior. > From Text.i3: > > PROCEDURE HasWideChars (t: T): BOOLEAN; > (* Returns "TRUE" if "t" contains any "WIDECHAR" characters. *) > > This reads to me like it refers to the actual characters comprising t, > which also makes sense to a client of this interface. > > In fact, the implementation returns TRUE if the internal representation > used is capable of representing any wide characters, even though they > could all be narrow. > > Some examples: > > Text.HasWideChars(W"ABC") = TRUE > > Text.HasWideChars(W"ABC"&"def") = TRUE > > Text.HasWideChars(Text.Sub(W"ABC"&"def",3,3)) = FALSE > > Text.HasWideChars(Text.Sub(W"ABC"&"def",2,3)) = TRUE > > These results have nothing to do with the abstract view of TEXT as > a string of characters. Moreover, a principal reason a client of > Text would call HasWideChars would be to know whether it could > subsequently call, e.g., Text.GetChar without having the value > silently truncated to 8 bits. > > So I propose to fix HasWideChars. This will entail some performance > penalties, as in many cases, it will have to go through the character > values one at at time in a loop and range-check each one. > > The alternative would be to redefine HasWideChars as a one-sided > approximation, (which is really is now) i.e., such that a result > of FALSE means the string is guaranteed to contain no wide characters, > but TRUE only means the real answer is unknown. Not very useful, and in > that case, it really should be be renamed MightHaveWideChars. > > What do others think? Anybody using GetWideChars who would be > affected? I think it should be fixed. If anybody really needs the current semantics, we can add the `might have' predicate later, but I don't see that it is very useful ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Fri Jan 30 15:35:45 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 30 Jan 2009 15:35:45 +0100 Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various Message-ID: <1233326145.8086.12.camel@faramir.m3w.org> As I can see, structure and naming of cm3-min archive for AMD64_LINUX is not consistent with LINUXLIBC6 one... And there is no cminstall inside... What to do? What am I supposed to do with these two per configuration? m3core/src/unix% grep Uucon **/m3m* Common/m3makefile: Interface("Uucontext") darwin-amd64/m3makefile:Interface ("Uucontext") darwin-i386/m3makefile:Interface ("Uucontext") darwin-ppc/m3makefile:Interface ("Uucontext") freebsd-4/m3makefile:Interface ("Uucontext") linux-64/m3makefile:Interface ("Uucontext") linux-i386/m3makefile:Interface("Uucontext") solaris-2-x/m3makefile:Interface ("Uucontext") I've added my cm3.spec to archive and built binaries for LINUXLIBC6 without problem... Same day I tried AMD64_LINUX through analog process and - build fails. Anybody had success with AMD64_LINUX build in recent CVS heads? TIA, -- Dragi?a Duri? From jay.krell at cornell.edu Fri Jan 30 16:37:05 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 30 Jan 2009 15:37:05 +0000 Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various In-Reply-To: <1233326145.8086.12.camel@faramir.m3w.org> References: <1233326145.8086.12.camel@faramir.m3w.org> Message-ID: The alternate naming and lack of cminstall is mostly deliberate. The "posix" in "amd64 linux posix" is redundant. I just call it "amd64 linux". Deliberate. The lack of a timestamp is due to "not yet implemented". (Thus "mostly" deliberate.) cminstall isn't needed. Deliberate. You just extract the archive and set $PATH. The cm3.cfg file in the archive should just work. If it doesn't, please let me know. All the releases I make and upload are like this, including the LINUXLIBC6 ones. The Uucontext.i3 problem should be fixed now. - Jay ---------------------------------------- > From: dragisha at m3w.org > To: m3devel at elegosoft.com > Date: Fri, 30 Jan 2009 15:35:45 +0100 > Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various > > As I can see, structure and naming of cm3-min archive for AMD64_LINUX is > not consistent with LINUXLIBC6 one... And there is no cminstall > inside... What to do? > > What am I supposed to do with these two per configuration? > > m3core/src/unix% grep Uucon **/m3m* > Common/m3makefile: Interface("Uucontext") > darwin-amd64/m3makefile:Interface ("Uucontext") > darwin-i386/m3makefile:Interface ("Uucontext") > darwin-ppc/m3makefile:Interface ("Uucontext") > freebsd-4/m3makefile:Interface ("Uucontext") > linux-64/m3makefile:Interface ("Uucontext") > linux-i386/m3makefile:Interface("Uucontext") > solaris-2-x/m3makefile:Interface ("Uucontext") > > I've added my cm3.spec to archive and built binaries for LINUXLIBC6 > without problem... Same day I tried AMD64_LINUX through analog process > and - build fails. Anybody had success with AMD64_LINUX build in recent > CVS heads? > > TIA, > > -- > Dragi?a Duri? > From dragisha at m3w.org Fri Jan 30 22:33:16 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 30 Jan 2009 22:33:16 +0100 Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various In-Reply-To: References: <1233326145.8086.12.camel@faramir.m3w.org> Message-ID: <1233351197.8086.268.camel@faramir.m3w.org> What remains as a problem is /lib vs. /lib64 thing. I've done this by applying this: @@ -37,9 +37,13 @@ %------------------------------------------------------------------------------ readonly BIN_INSTALL = INSTALL_ROOT & SL & "bin" % executables -readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & PROFILING_P % libraries +if equal(TARGET, "AMD64_LINUX") + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib64" & PROFILING_P % libraries +else + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & PROFILING_P % libraries +end readonly PKG_INSTALL = INSTALL_ROOT & SL & "pkg" % packages readonly DOC_INSTALL = INSTALL_ROOT & SL & "doc" % documents This way I can choose which development to use, while maintaining both runtimes on-system. LINUXLIBC6 and AMD64_LINUX separation will work for pkg, but folder containing links - $INSTALLROOT + SL + "lib" on AMD64_LINUX must use lib64. On Fri, 2009-01-30 at 15:37 +0000, Jay wrote: > The alternate naming and lack of cminstall is mostly deliberate. > > The "posix" in "amd64 linux posix" is redundant. I just call it "amd64 linux". Deliberate. > > The lack of a timestamp is due to "not yet implemented". (Thus "mostly" deliberate.) > > cminstall isn't needed. Deliberate. > > You just extract the archive and set $PATH. > The cm3.cfg file in the archive should just work. > If it doesn't, please let me know. > > > All the releases I make and upload are like this, including the LINUXLIBC6 ones. > > > The Uucontext.i3 problem should be fixed now. > > - Jay > > ---------------------------------------- > > From: dragisha at m3w.org > > To: m3devel at elegosoft.com > > Date: Fri, 30 Jan 2009 15:35:45 +0100 > > Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various > > > > As I can see, structure and naming of cm3-min archive for AMD64_LINUX is > > not consistent with LINUXLIBC6 one... And there is no cminstall > > inside... What to do? > > > > What am I supposed to do with these two per configuration? > > > > m3core/src/unix% grep Uucon **/m3m* > > Common/m3makefile: Interface("Uucontext") > > darwin-amd64/m3makefile:Interface ("Uucontext") > > darwin-i386/m3makefile:Interface ("Uucontext") > > darwin-ppc/m3makefile:Interface ("Uucontext") > > freebsd-4/m3makefile:Interface ("Uucontext") > > linux-64/m3makefile:Interface ("Uucontext") > > linux-i386/m3makefile:Interface("Uucontext") > > solaris-2-x/m3makefile:Interface ("Uucontext") > > > > I've added my cm3.spec to archive and built binaries for LINUXLIBC6 > > without problem... Same day I tried AMD64_LINUX through analog process > > and - build fails. Anybody had success with AMD64_LINUX build in recent > > CVS heads? > > > > TIA, > > > > -- > > Dragi?a Duri? > > -- Dragi?a Duri? From jay.krell at cornell.edu Fri Jan 30 22:53:17 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 30 Jan 2009 21:53:17 +0000 Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various In-Reply-To: <1233351197.8086.268.camel@faramir.m3w.org> References: <1233326145.8086.12.camel@faramir.m3w.org> <1233351197.8086.268.camel@faramir.m3w.org> Message-ID: That's very reasonable. You could just commit that imho. More general and reasonable would be: > + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & WORD_SIZE & PROFILING_P % libraries or even > + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib/" & TARGET & PROFILING_P % libraries though granted, most systems aren't biarch/multiarch, so what you have is maybe best, possibly manually adding in biarch/multiarch systems as they are discovered -- e.g. most but not all x86 systems. (This area is actually "surprisingly large" Irix has two 32bit ABIs, there are 32bit ABIs for IA64, I think like on HP-UX). The full lib/TARGET helps for NT386 vs. NT386GNU. - Jay ---------------------------------------- > Subject: RE: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various > From: dragisha at m3w.org > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Date: Fri, 30 Jan 2009 22:33:16 +0100 > > What remains as a problem is /lib vs. /lib64 thing. > > I've done this by applying this: > > @@ -37,9 +37,13 @@ > > %------------------------------------------------------------------------------ > > readonly BIN_INSTALL = INSTALL_ROOT & SL & "bin" % executables > -readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & PROFILING_P % libraries > +if equal(TARGET, "AMD64_LINUX") > + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib64" & PROFILING_P % libraries > +else > + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & PROFILING_P % libraries > +end > readonly PKG_INSTALL = INSTALL_ROOT & SL & "pkg" % packages > readonly DOC_INSTALL = INSTALL_ROOT & SL & "doc" % documents > > > This way I can choose which development to use, while maintaining both > runtimes on-system. LINUXLIBC6 and AMD64_LINUX separation will work for > pkg, but folder containing links - $INSTALLROOT + SL + "lib" on > AMD64_LINUX must use lib64. > > On Fri, 2009-01-30 at 15:37 +0000, Jay wrote: >> The alternate naming and lack of cminstall is mostly deliberate. >> >> The "posix" in "amd64 linux posix" is redundant. I just call it "amd64 linux". Deliberate. >> >> The lack of a timestamp is due to "not yet implemented". (Thus "mostly" deliberate.) >> >> cminstall isn't needed. Deliberate. >> >> You just extract the archive and set $PATH. >> The cm3.cfg file in the archive should just work. >> If it doesn't, please let me know. >> >> >> All the releases I make and upload are like this, including the LINUXLIBC6 ones. >> >> >> The Uucontext.i3 problem should be fixed now. >> >> - Jay >> >> ---------------------------------------- >>> From: dragisha at m3w.org >>> To: m3devel at elegosoft.com >>> Date: Fri, 30 Jan 2009 15:35:45 +0100 >>> Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various >>> >>> As I can see, structure and naming of cm3-min archive for AMD64_LINUX is >>> not consistent with LINUXLIBC6 one... And there is no cminstall >>> inside... What to do? >>> >>> What am I supposed to do with these two per configuration? >>> >>> m3core/src/unix% grep Uucon **/m3m* >>> Common/m3makefile: Interface("Uucontext") >>> darwin-amd64/m3makefile:Interface ("Uucontext") >>> darwin-i386/m3makefile:Interface ("Uucontext") >>> darwin-ppc/m3makefile:Interface ("Uucontext") >>> freebsd-4/m3makefile:Interface ("Uucontext") >>> linux-64/m3makefile:Interface ("Uucontext") >>> linux-i386/m3makefile:Interface("Uucontext") >>> solaris-2-x/m3makefile:Interface ("Uucontext") >>> >>> I've added my cm3.spec to archive and built binaries for LINUXLIBC6 >>> without problem... Same day I tried AMD64_LINUX through analog process >>> and - build fails. Anybody had success with AMD64_LINUX build in recent >>> CVS heads? >>> >>> TIA, >>> >>> -- >>> Dragi?a Duri? >>> > -- > Dragi?a Duri? > From dragisha at m3w.org Fri Jan 30 23:02:35 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 30 Jan 2009 23:02:35 +0100 Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various In-Reply-To: References: <1233326145.8086.12.camel@faramir.m3w.org> <1233351197.8086.268.camel@faramir.m3w.org> Message-ID: <1233352955.8086.270.camel@faramir.m3w.org> "lib" & WORD_SIZE is not usual, IMO, because lib64 is addition, and lib was always there. Also - best approach would be to scratch itch by itch. Trying too generally can make mess in advance. What script do you use to make yours cm3-min? dd On Fri, 2009-01-30 at 21:53 +0000, Jay wrote: > That's very reasonable. You could just commit that imho. > > > More general and reasonable would be: > > > > + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & WORD_SIZE & PROFILING_P % libraries > > or even > > > + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib/" & TARGET & PROFILING_P % libraries > > > though granted, most systems aren't biarch/multiarch, so what you have is maybe best, possibly manually adding in biarch/multiarch systems as they are discovered -- e.g. most but not all x86 systems. (This area is actually "surprisingly large" Irix has two 32bit ABIs, there are 32bit ABIs for IA64, I think like on HP-UX). > > > The full lib/TARGET helps for NT386 vs. NT386GNU. > > - Jay > > > ---------------------------------------- > > Subject: RE: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various > > From: dragisha at m3w.org > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Date: Fri, 30 Jan 2009 22:33:16 +0100 > > > > What remains as a problem is /lib vs. /lib64 thing. > > > > I've done this by applying this: > > > > @@ -37,9 +37,13 @@ > > > > %------------------------------------------------------------------------------ > > > > readonly BIN_INSTALL = INSTALL_ROOT & SL & "bin" % executables > > -readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & PROFILING_P % libraries > > +if equal(TARGET, "AMD64_LINUX") > > + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib64" & PROFILING_P % libraries > > +else > > + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & PROFILING_P % libraries > > +end > > readonly PKG_INSTALL = INSTALL_ROOT & SL & "pkg" % packages > > readonly DOC_INSTALL = INSTALL_ROOT & SL & "doc" % documents > > > > > > This way I can choose which development to use, while maintaining both > > runtimes on-system. LINUXLIBC6 and AMD64_LINUX separation will work for > > pkg, but folder containing links - $INSTALLROOT + SL + "lib" on > > AMD64_LINUX must use lib64. > > > > On Fri, 2009-01-30 at 15:37 +0000, Jay wrote: > >> The alternate naming and lack of cminstall is mostly deliberate. > >> > >> The "posix" in "amd64 linux posix" is redundant. I just call it "amd64 linux". Deliberate. > >> > >> The lack of a timestamp is due to "not yet implemented". (Thus "mostly" deliberate.) > >> > >> cminstall isn't needed. Deliberate. > >> > >> You just extract the archive and set $PATH. > >> The cm3.cfg file in the archive should just work. > >> If it doesn't, please let me know. > >> > >> > >> All the releases I make and upload are like this, including the LINUXLIBC6 ones. > >> > >> > >> The Uucontext.i3 problem should be fixed now. > >> > >> - Jay > >> > >> ---------------------------------------- > >>> From: dragisha at m3w.org > >>> To: m3devel at elegosoft.com > >>> Date: Fri, 30 Jan 2009 15:35:45 +0100 > >>> Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various > >>> > >>> As I can see, structure and naming of cm3-min archive for AMD64_LINUX is > >>> not consistent with LINUXLIBC6 one... And there is no cminstall > >>> inside... What to do? > >>> > >>> What am I supposed to do with these two per configuration? > >>> > >>> m3core/src/unix% grep Uucon **/m3m* > >>> Common/m3makefile: Interface("Uucontext") > >>> darwin-amd64/m3makefile:Interface ("Uucontext") > >>> darwin-i386/m3makefile:Interface ("Uucontext") > >>> darwin-ppc/m3makefile:Interface ("Uucontext") > >>> freebsd-4/m3makefile:Interface ("Uucontext") > >>> linux-64/m3makefile:Interface ("Uucontext") > >>> linux-i386/m3makefile:Interface("Uucontext") > >>> solaris-2-x/m3makefile:Interface ("Uucontext") > >>> > >>> I've added my cm3.spec to archive and built binaries for LINUXLIBC6 > >>> without problem... Same day I tried AMD64_LINUX through analog process > >>> and - build fails. Anybody had success with AMD64_LINUX build in recent > >>> CVS heads? > >>> > >>> TIA, > >>> > >>> -- > >>> Dragi?a Duri? > >>> > > -- > > Dragi?a Duri? > > -- Dragi?a Duri? From jay.krell at cornell.edu Fri Jan 30 23:33:56 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 30 Jan 2009 22:33:56 +0000 Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various In-Reply-To: <1233352955.8086.270.camel@faramir.m3w.org> References: <1233326145.8086.12.camel@faramir.m3w.org> <1233351197.8086.268.camel@faramir.m3w.org> <1233352955.8086.270.camel@faramir.m3w.org> Message-ID: > What script do you use to make yours cm3-min? scripts/python/make-dist.py - Jay ---------------------------------------- > From: dragisha at m3w.org > To: jay.krell at cornell.edu > Date: Fri, 30 Jan 2009 23:02:35 +0100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various > > "lib" & WORD_SIZE is not usual, IMO, because lib64 is addition, and lib > was always there. > > Also - best approach would be to scratch itch by itch. Trying too > generally can make mess in advance. > > What script do you use to make yours cm3-min? > > dd > > On Fri, 2009-01-30 at 21:53 +0000, Jay wrote: >> That's very reasonable. You could just commit that imho. >> >> >> More general and reasonable would be: >> >> >>> + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & WORD_SIZE & PROFILING_P % libraries >> >> or even >> >>> + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib/" & TARGET & PROFILING_P % libraries >> >> >> though granted, most systems aren't biarch/multiarch, so what you have is maybe best, possibly manually adding in biarch/multiarch systems as they are discovered -- e.g. most but not all x86 systems. (This area is actually "surprisingly large" Irix has two 32bit ABIs, there are 32bit ABIs for IA64, I think like on HP-UX). >> >> >> The full lib/TARGET helps for NT386 vs. NT386GNU. >> >> - Jay >> >> >> ---------------------------------------- >>> Subject: RE: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various >>> From: dragisha at m3w.org >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Date: Fri, 30 Jan 2009 22:33:16 +0100 >>> >>> What remains as a problem is /lib vs. /lib64 thing. >>> >>> I've done this by applying this: >>> >>> @@ -37,9 +37,13 @@ >>> >>> %------------------------------------------------------------------------------ >>> >>> readonly BIN_INSTALL = INSTALL_ROOT & SL & "bin" % executables >>> -readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & PROFILING_P % libraries >>> +if equal(TARGET, "AMD64_LINUX") >>> + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib64" & PROFILING_P % libraries >>> +else >>> + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & PROFILING_P % libraries >>> +end >>> readonly PKG_INSTALL = INSTALL_ROOT & SL & "pkg" % packages >>> readonly DOC_INSTALL = INSTALL_ROOT & SL & "doc" % documents >>> >>> >>> This way I can choose which development to use, while maintaining both >>> runtimes on-system. LINUXLIBC6 and AMD64_LINUX separation will work for >>> pkg, but folder containing links - $INSTALLROOT + SL + "lib" on >>> AMD64_LINUX must use lib64. >>> >>> On Fri, 2009-01-30 at 15:37 +0000, Jay wrote: >>>> The alternate naming and lack of cminstall is mostly deliberate. >>>> >>>> The "posix" in "amd64 linux posix" is redundant. I just call it "amd64 linux". Deliberate. >>>> >>>> The lack of a timestamp is due to "not yet implemented". (Thus "mostly" deliberate.) >>>> >>>> cminstall isn't needed. Deliberate. >>>> >>>> You just extract the archive and set $PATH. >>>> The cm3.cfg file in the archive should just work. >>>> If it doesn't, please let me know. >>>> >>>> >>>> All the releases I make and upload are like this, including the LINUXLIBC6 ones. >>>> >>>> >>>> The Uucontext.i3 problem should be fixed now. >>>> >>>> - Jay >>>> >>>> ---------------------------------------- >>>>> From: dragisha at m3w.org >>>>> To: m3devel at elegosoft.com >>>>> Date: Fri, 30 Jan 2009 15:35:45 +0100 >>>>> Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various >>>>> >>>>> As I can see, structure and naming of cm3-min archive for AMD64_LINUX is >>>>> not consistent with LINUXLIBC6 one... And there is no cminstall >>>>> inside... What to do? >>>>> >>>>> What am I supposed to do with these two per configuration? >>>>> >>>>> m3core/src/unix% grep Uucon **/m3m* >>>>> Common/m3makefile: Interface("Uucontext") >>>>> darwin-amd64/m3makefile:Interface ("Uucontext") >>>>> darwin-i386/m3makefile:Interface ("Uucontext") >>>>> darwin-ppc/m3makefile:Interface ("Uucontext") >>>>> freebsd-4/m3makefile:Interface ("Uucontext") >>>>> linux-64/m3makefile:Interface ("Uucontext") >>>>> linux-i386/m3makefile:Interface("Uucontext") >>>>> solaris-2-x/m3makefile:Interface ("Uucontext") >>>>> >>>>> I've added my cm3.spec to archive and built binaries for LINUXLIBC6 >>>>> without problem... Same day I tried AMD64_LINUX through analog process >>>>> and - build fails. Anybody had success with AMD64_LINUX build in recent >>>>> CVS heads? >>>>> >>>>> TIA, >>>>> >>>>> -- >>>>> Dragi?a Duri? >>>>> >>> -- >>> Dragi?a Duri? >>> > -- > Dragi?a Duri? > From jay.krell at cornell.edu Fri Jan 30 23:49:25 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 30 Jan 2009 22:49:25 +0000 Subject: [M3devel] using *context functions for user threading? Message-ID: Tony, can you tell me more of what you have in mind here? In particular...I /think/ it goes like: use getcontext + makecontext to "create a thread" use simple struct copying/memcpy of the third parameter to the signal handler for context switching in particular -- setcontext/makecontext never used -- except to start a thread, but not to switch to/from already started threads. ? Implication here is that even on systems without context APIs, our ucontext_t needs to match what the signal handler gets. That isn't the case for what I just got "working" (prototype, proof of concept, whatever) on OpenBSD, but easy enough. An alternative is to call setcontext in the signal handler, but that makes me nervous. It seems best to exit "cleanly" out of a signal handler? And then I get to seeing very murky things, like, can a system call be interrupted by an alarm signal? If so, switching threads then...what would that do? Seems bad. So then I guess I see the origin of all the original system call wrappers -- to turn of thread switching during system calls. ? The current code does appear to longjmp out of a system call -- or rather, to longjmp from one alarm signal to another. Again this seems confusing if alarm signals can interrupt system calls. Some abstraction that encompasses Win32 fibers might be nice, though there would remain the question of how to preempt. - Jay From hosking at cs.purdue.edu Sat Jan 31 04:09:23 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 31 Jan 2009 14:09:23 +1100 Subject: [M3devel] using *context functions for user threading? In-Reply-To: References: Message-ID: On 31 Jan 2009, at 09:49, Jay wrote: > Tony, can you tell me more of what you have in mind here? I didn't plan anything other than using swapcontext instead of longjmp in switch_thread, and using makecontext instead of InitContext to get a forked thread's context. > In particular...I /think/ it goes like: > > > use getcontext + makecontext to "create a thread" > use simple struct copying/memcpy of the third parameter to the > signal handler for context switching No, swapcontext. > in particular -- setcontext/makecontext never used -- except to > start a thread, but not to switch to/from already started threads. Right. > ? > > > Implication here is that even on systems without context APIs, our > ucontext_t needs to match what the signal handler gets. That isn't > the case for what I just got "working" (prototype, proof of concept, > whatever) on OpenBSD, but easy enough. I don't know what you are saying here. swapcontext should be enough. > An alternative is to call setcontext in the signal handler, but that > makes me nervous. > It seems best to exit "cleanly" out of a signal handler? You're right, but this is probably broken for the current longjmp- based implementation too. > And then I get to seeing very murky things, like, can a system call > be interrupted by an alarm signal? If so, switching threads > then...what would that do? Seems bad. Yes, I was never convinced that the longjmp-based implementation was safe either. I figured that it probably worked only because it was a single-threaded process, but I don't know if that really prevents a timer signal arriving inside the signal handler, and what impact that might have. > So then I guess I see the origin of all the original system call > wrappers -- to turn of thread switching during system calls. No, those were only for GC. > ? > > The current code does appear to longjmp out of a system call -- or > rather, to longjmp from one alarm signal to another. Again this > seems confusing if alarm signals can interrupt system calls. Right... > Some abstraction that encompasses Win32 fibers might be nice, though > there would remain the question of how to preempt. The safest solution for all of this is to have the timer signal handler set a flag and for the M3 compiler to inject a test of the flag at calls/backward branches, and explicitly yield if the flag is set. > > > - Jay From jay.krell at cornell.edu Sat Jan 31 04:46:53 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 31 Jan 2009 03:46:53 +0000 Subject: [M3devel] using *context functions for user threading? In-Reply-To: References: Message-ID: I think setjmp/longjmp would continue to be ok. It has very little machine dependency, and I /guess/ works and is portable. I guess. We are both leary, but it's been there a while. It is InitContext imho that could be "better" -- more portable, remove all the mucking around with frames and stack pointers. I was late to see this because it is in the machine-independent chunk of code. What does swapcontext buy over setjmp/longjmp, once a thread is "already started"? I can see there is a "unifying" reason. If makecontext is used to InitContext, then swapcontext is needed to "start" a thread. setjmp/longjmp could be used to suspend/resume, but if you phrase "start" and "resume" as the same thing, then "stuck" with swapcontext. For some time I was under the impression that Modula-3 repeatedly longjmped to a buffer that only had setjmp called once, or where the function that setjmp was called from had returned, but I'm not sure of that now. It seems viable to "follow the rules" wrt setjmp/longjmp, other than the "escaping from a signal handler" aspect. > The safest solution for all of this is to have the timer signal > handler set a flag and for the M3 compiler to inject a test of the > flag at calls/backward branches, and explicitly yield if the flag is > set. Yes that makes me much more comfortable as well. Is it cut & dry agreed to and such? Someone should just do it? Or there are concerns that: - it might not be often enough? There are no "forward" or "backward" branches at the Modula-3 level, are there? It is at the whim of the backend, right? I guess you might be able to conceptually label branches as forward or backward, even if the backend "rotates" things or adds more branches (you know, like loops often starting with a forward branch). - it might be too often? - it might be too code bloating? Or too slow when "checks" greatly outweight actual switches? - a call out to a function or a check of a variable? - only do it if a compiler command line switch is given? Or for platforms known to support user threads? (given the design though..it could be every platform) Though I raise the issues, it still seems the right thing, vs. longjmping out of a signal handler. The OpenBSD sigaction manpage does seem to have in mind an ability to "switch threads" in a signal handler: "When a caught signal is delivered, the current state of the process is saved, a new signal mask is calculated (as described below), and the signal handler is invoked. The call to the handler is arranged so that if the signal han- dling routine returns normally the process will resume execution in the context from before the signal's delivery. If the process wishes to re- sume in a different context, then it must arrange to restore the previous context itself. " but the idea here is not longjmp or I think exactly swapcontext, but manually swapping a context with the third parameter to the signal handler. > single-threaded process, but I don't know if that really prevents a > timer signal arriving inside the signal handler, and what impact that > might have. Right. I don't see that control-c can't come in at about the same time as timer. Though I think sigaction allows for fixing this -- block all signals during the signal handler. I'll reread some manpages. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Sat, 31 Jan 2009 14:09:23 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] using *context functions for user threading? > > On 31 Jan 2009, at 09:49, Jay wrote: > >> Tony, can you tell me more of what you have in mind here? > > I didn't plan anything other than using swapcontext instead of longjmp > in switch_thread, and using makecontext instead of InitContext to get > a forked thread's context. > >> In particular...I /think/ it goes like: >> >> >> use getcontext + makecontext to "create a thread" >> use simple struct copying/memcpy of the third parameter to the >> signal handler for context switching > > No, swapcontext. > >> in particular -- setcontext/makecontext never used -- except to >> start a thread, but not to switch to/from already started threads. > > Right. > >> ? >> >> >> Implication here is that even on systems without context APIs, our >> ucontext_t needs to match what the signal handler gets. That isn't >> the case for what I just got "working" (prototype, proof of concept, >> whatever) on OpenBSD, but easy enough. > > I don't know what you are saying here. swapcontext should be enough. > >> An alternative is to call setcontext in the signal handler, but that >> makes me nervous. >> It seems best to exit "cleanly" out of a signal handler? > > You're right, but this is probably broken for the current longjmp- > based implementation too. > >> And then I get to seeing very murky things, like, can a system call >> be interrupted by an alarm signal? If so, switching threads >> then...what would that do? Seems bad. > > Yes, I was never convinced that the longjmp-based implementation was > safe either. I figured that it probably worked only because it was a > single-threaded process, but I don't know if that really prevents a > timer signal arriving inside the signal handler, and what impact that > might have. > >> So then I guess I see the origin of all the original system call >> wrappers -- to turn of thread switching during system calls. > > No, those were only for GC. > >> ? >> >> The current code does appear to longjmp out of a system call -- or >> rather, to longjmp from one alarm signal to another. Again this >> seems confusing if alarm signals can interrupt system calls. > > Right... > >> Some abstraction that encompasses Win32 fibers might be nice, though >> there would remain the question of how to preempt. > > The safest solution for all of this is to have the timer signal > handler set a flag and for the M3 compiler to inject a test of the > flag at calls/backward branches, and explicitly yield if the flag is > set. > >> >> >> - Jay > From hosking at cs.purdue.edu Sat Jan 31 05:08:49 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 31 Jan 2009 15:08:49 +1100 Subject: [M3devel] using *context functions for user threading? In-Reply-To: References: Message-ID: <4D53B3C7-7089-4372-AD7C-3B879D43D2C8@cs.purdue.edu> It doesn't work because of security enhancements that prevent forgery of a context as the current system does. swapcontext *is* used on Solaris (as currently implemented) but the InitContext code needs replacing with makecontext. longjmp is not async-signal-safe, and so just as bad as swapcontext when called from a signal handler. Indeed, BSD seems to imply swapcontext can be used in a signal handler. I don't want to leap into explicit polling of a yield flag without further thought. Better to get 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 31 Jan 2009, at 14:46, Jay wrote: > > I think setjmp/longjmp would continue to be ok. > It has very little machine dependency, and I /guess/ works and is > portable. > I guess. We are both leary, but it's been there a while. > It is InitContext imho that could be "better" -- more portable, > remove all the > mucking around with frames and stack pointers. > I was late to see this because it is in the machine-independent > chunk of code. > > > What does swapcontext buy over setjmp/longjmp, once a thread is > "already started"? > I can see there is a "unifying" reason. > If makecontext is used to InitContext, then swapcontext is needed to > "start" a thread. > setjmp/longjmp could be used to suspend/resume, but if you phrase > "start" and "resume" as the same thing, then "stuck" with swapcontext. > > > For some time I was under the impression that Modula-3 repeatedly > longjmped to a buffer that only had setjmp called once, or where the > function that setjmp was called from had returned, but I'm not sure > of that now. It seems viable to "follow the rules" wrt setjmp/ > longjmp, other than the "escaping from a signal handler" aspect. > > >> The safest solution for all of this is to have the timer signal >> handler set a flag and for the M3 compiler to inject a test of the >> flag at calls/backward branches, and explicitly yield if the flag is >> set. > > > Yes that makes me much more comfortable as well. > > > Is it cut & dry agreed to and such? > > > Someone should just do it? > > > Or there are concerns that: > - it might not be often enough? > There are no "forward" or "backward" branches at the Modula-3 > level, are there? > It is at the whim of the backend, right? I guess you might be > able to > conceptually label branches as forward or backward, even if the > backend "rotates" things or > adds more branches (you know, like loops often starting with a > forward branch). > - it might be too often? > - it might be too code bloating? Or too slow when "checks" greatly > outweight actual switches? > - a call out to a function or a check of a variable? > - only do it if a compiler command line switch is given? Or for > platforms known to support user threads? (given the design > though..it could be every platform) > > > Though I raise the issues, it still seems the right thing, vs. > longjmping out of a signal handler. > > > The OpenBSD sigaction manpage does seem to have in mind an ability > to "switch threads" in a signal handler: > > > "When a caught > signal is delivered, the current state of the process is saved, > a new > signal mask is calculated (as described below), and the signal > handler is > invoked. The call to the handler is arranged so that if the > signal han- > dling routine returns normally the process will resume execution > in the > context from before the signal's delivery. If the process > wishes to re- > sume in a different context, then it must arrange to restore the > previous > context itself. > " > > but the idea here is not longjmp or I think exactly swapcontext, but > manually swapping a context with the third parameter to the signal > handler. > > >> single-threaded process, but I don't know if that really prevents a >> timer signal arriving inside the signal handler, and what impact that >> might have. > > > Right. I don't see that control-c can't come in at about the same > time as timer. > Though I think sigaction allows for fixing this -- block all signals > during the signal handler. > I'll reread some manpages. > > > - Jay > > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Sat, 31 Jan 2009 14:09:23 +1100 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] using *context functions for user threading? >> >> On 31 Jan 2009, at 09:49, Jay wrote: >> >>> Tony, can you tell me more of what you have in mind here? >> >> I didn't plan anything other than using swapcontext instead of >> longjmp >> in switch_thread, and using makecontext instead of InitContext to get >> a forked thread's context. >> >>> In particular...I /think/ it goes like: >>> >>> >>> use getcontext + makecontext to "create a thread" >>> use simple struct copying/memcpy of the third parameter to the >>> signal handler for context switching >> >> No, swapcontext. >> >>> in particular -- setcontext/makecontext never used -- except to >>> start a thread, but not to switch to/from already started threads. >> >> Right. >> >>> ? >>> >>> >>> Implication here is that even on systems without context APIs, our >>> ucontext_t needs to match what the signal handler gets. That isn't >>> the case for what I just got "working" (prototype, proof of concept, >>> whatever) on OpenBSD, but easy enough. >> >> I don't know what you are saying here. swapcontext should be enough. >> >>> An alternative is to call setcontext in the signal handler, but that >>> makes me nervous. >>> It seems best to exit "cleanly" out of a signal handler? >> >> You're right, but this is probably broken for the current longjmp- >> based implementation too. >> >>> And then I get to seeing very murky things, like, can a system call >>> be interrupted by an alarm signal? If so, switching threads >>> then...what would that do? Seems bad. >> >> Yes, I was never convinced that the longjmp-based implementation was >> safe either. I figured that it probably worked only because it was a >> single-threaded process, but I don't know if that really prevents a >> timer signal arriving inside the signal handler, and what impact that >> might have. >> >>> So then I guess I see the origin of all the original system call >>> wrappers -- to turn of thread switching during system calls. >> >> No, those were only for GC. >> >>> ? >>> >>> The current code does appear to longjmp out of a system call -- or >>> rather, to longjmp from one alarm signal to another. Again this >>> seems confusing if alarm signals can interrupt system calls. >> >> Right... >> >>> Some abstraction that encompasses Win32 fibers might be nice, though >>> there would remain the question of how to preempt. >> >> The safest solution for all of this is to have the timer signal >> handler set a flag and for the M3 compiler to inject a test of the >> flag at calls/backward branches, and explicitly yield if the flag is >> set. >> >>> >>> >>> - Jay >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Jan 31 18:31:39 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 31 Jan 2009 18:31:39 +0100 Subject: [M3devel] make_dir failure Message-ID: <1233423099.16504.4.camel@faramir.m3w.org> I am trying to build rpm for AMD64_LINUX... I have this situation (strace output fragment) 25802 utimes("/tmp/cm3/usr/local/cm3/pkg/m3core/AMD64_LINUX/libm3core.so", {{1233421816, 0}, {1233421693, 0}}) = 0 25802 stat("/tmp/cm3/usr/local/cm3/bin/../lib64", 0x7fff53109270) = -1 ENOENT (No such file or directory) 25802 stat("/tmp/cm3/usr/local/cm3/bin/..", 0x7fff531090d0) = -1 ENOENT (No such file or directory) 25802 stat("/tmp/cm3/usr/local/cm3/bin", 0x7fff53108f30) = -1 ENOENT (No such file or directory) 25802 stat("/tmp/cm3/usr/local/cm3", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 25802 mkdir("/tmp/cm3/usr/local/cm3/bin", 0777) = 0 25802 mkdir("/tmp/cm3/usr/local/cm3/bin/..", 0777) = -1 EEXIST (File exists) 25802 fcntl(2, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) 25802 fcntl(2, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0 25802 write(2, "\"/usr/src/redhat/BUILD/cm3/m3-li"..., 312) = 312 25802 fcntl(2, F_SETFL, O_RDWR|O_LARGEFILE) = 0 25802 fcntl(2, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) 25802 fcntl(2, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0 25802 write(2, "\n", 1) = 1 25802 fcntl(2, F_SETFL, O_RDWR|O_LARGEFILE) = 0 25802 fcntl(1, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) 25802 fcntl(1, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0 25802 write(1, "Fatal Error: package build faile"..., 34) = 34 25802 fcntl(1, F_SETFL, O_RDWR|O_LARGEFILE) = 0 25802 unlink("m3make.args") = 0 .M3SHIP command in question is: make_dir("/usr/local/cm3/bin/../lib64") Looks like path normalization function are a bit... confused? -- Dragi?a Duri? From jay.krell at cornell.edu Sat Jan 31 20:05:36 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 31 Jan 2009 19:05:36 +0000 Subject: [M3devel] make_dir failure In-Reply-To: <1233423099.16504.4.camel@faramir.m3w.org> References: <1233423099.16504.4.camel@faramir.m3w.org> Message-ID: It looks ok to me. What happens if you create /usr/local/cm3/bin and /tmp/cm3/usr/local/cm3/bin? Unix is imho bogusly finicky and doesn't like foo/../bar unless foo exists. Windows parses out the .. without checking if foo exists, leaving this sort of construct more useful. The Modula-3/Quake code I think never smushes out the ".." here, but making it do so is very reasonable. This is part of how I avoid cminstall and just having one cm3.cfg -- all the paths are computed from the path of cm3/cm3.cfg. Probably defaulting them in the Modula-3 code instead of requiring them be set by Quake would be good, as part of a larger goal of more Modula-3 and less Quake. Quake coudl still override them if necessary. - Jay ---------------------------------------- > From: dragisha at m3w.org > To: m3devel at elegosoft.com > Date: Sat, 31 Jan 2009 18:31:39 +0100 > Subject: [M3devel] make_dir failure > > I am trying to build rpm for AMD64_LINUX... I have this situation > (strace output fragment) > > 25802 utimes("/tmp/cm3/usr/local/cm3/pkg/m3core/AMD64_LINUX/libm3core.so", {{1233421816, 0}, {1233421693, 0}}) = 0 > 25802 stat("/tmp/cm3/usr/local/cm3/bin/../lib64", 0x7fff53109270) = -1 ENOENT (No such file or directory) > 25802 stat("/tmp/cm3/usr/local/cm3/bin/..", 0x7fff531090d0) = -1 ENOENT (No such file or directory) > 25802 stat("/tmp/cm3/usr/local/cm3/bin", 0x7fff53108f30) = -1 ENOENT (No such file or directory) > 25802 stat("/tmp/cm3/usr/local/cm3", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 > 25802 mkdir("/tmp/cm3/usr/local/cm3/bin", 0777) = 0 > 25802 mkdir("/tmp/cm3/usr/local/cm3/bin/..", 0777) = -1 EEXIST (File exists) > 25802 fcntl(2, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) > 25802 fcntl(2, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0 > 25802 write(2, "\"/usr/src/redhat/BUILD/cm3/m3-li"..., 312) = 312 > 25802 fcntl(2, F_SETFL, O_RDWR|O_LARGEFILE) = 0 > 25802 fcntl(2, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) > 25802 fcntl(2, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0 > 25802 write(2, "\n", 1) = 1 > 25802 fcntl(2, F_SETFL, O_RDWR|O_LARGEFILE) = 0 > 25802 fcntl(1, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) > 25802 fcntl(1, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0 > 25802 write(1, "Fatal Error: package build faile"..., 34) = 34 > 25802 fcntl(1, F_SETFL, O_RDWR|O_LARGEFILE) = 0 > 25802 unlink("m3make.args") = 0 > > .M3SHIP command in question is: > > make_dir("/usr/local/cm3/bin/../lib64") > > Looks like path normalization function are a bit... confused? > -- > Dragi?a Duri? > > From dragisha at m3w.org Sat Jan 31 21:26:19 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 31 Jan 2009 21:26:19 +0100 Subject: [M3devel] make_dir failure In-Reply-To: References: <1233423099.16504.4.camel@faramir.m3w.org> Message-ID: <1233433579.16504.7.camel@faramir.m3w.org> This can look good to you, but this breaks with errno 17 - file exists. Look at 7th row of strace. On Sat, 2009-01-31 at 19:05 +0000, Jay wrote: > It looks ok to me. > What happens if you create /usr/local/cm3/bin and /tmp/cm3/usr/local/cm3/bin? > Unix is imho bogusly finicky and doesn't like foo/../bar unless foo exists. > Windows parses out the .. without checking if foo exists, leaving this sort of construct more useful. > The Modula-3/Quake code I think never smushes out the ".." here, but making it do so is very reasonable. > > > This is part of how I avoid cminstall and just having one cm3.cfg -- all the paths are computed from the path of cm3/cm3.cfg. Probably defaulting them in the Modula-3 code instead of requiring them be set by Quake would be good, as part of a larger goal of more Modula-3 and less Quake. Quake coudl still override them if necessary. > > > - Jay > > ---------------------------------------- > > From: dragisha at m3w.org > > To: m3devel at elegosoft.com > > Date: Sat, 31 Jan 2009 18:31:39 +0100 > > Subject: [M3devel] make_dir failure > > > > I am trying to build rpm for AMD64_LINUX... I have this situation > > (strace output fragment) > > > > 25802 utimes("/tmp/cm3/usr/local/cm3/pkg/m3core/AMD64_LINUX/libm3core.so", {{1233421816, 0}, {1233421693, 0}}) = 0 > > 25802 stat("/tmp/cm3/usr/local/cm3/bin/../lib64", 0x7fff53109270) = -1 ENOENT (No such file or directory) > > 25802 stat("/tmp/cm3/usr/local/cm3/bin/..", 0x7fff531090d0) = -1 ENOENT (No such file or directory) > > 25802 stat("/tmp/cm3/usr/local/cm3/bin", 0x7fff53108f30) = -1 ENOENT (No such file or directory) > > 25802 stat("/tmp/cm3/usr/local/cm3", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 > > 25802 mkdir("/tmp/cm3/usr/local/cm3/bin", 0777) = 0 > > 25802 mkdir("/tmp/cm3/usr/local/cm3/bin/..", 0777) = -1 EEXIST (File exists) > > 25802 fcntl(2, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) > > 25802 fcntl(2, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0 > > 25802 write(2, "\"/usr/src/redhat/BUILD/cm3/m3-li"..., 312) = 312 > > 25802 fcntl(2, F_SETFL, O_RDWR|O_LARGEFILE) = 0 > > 25802 fcntl(2, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) > > 25802 fcntl(2, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0 > > 25802 write(2, "\n", 1) = 1 > > 25802 fcntl(2, F_SETFL, O_RDWR|O_LARGEFILE) = 0 > > 25802 fcntl(1, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) > > 25802 fcntl(1, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0 > > 25802 write(1, "Fatal Error: package build faile"..., 34) = 34 > > 25802 fcntl(1, F_SETFL, O_RDWR|O_LARGEFILE) = 0 > > 25802 unlink("m3make.args") = 0 > > > > .M3SHIP command in question is: > > > > make_dir("/usr/local/cm3/bin/../lib64") > > > > Looks like path normalization function are a bit... confused? > > -- > > Dragi?a Duri? > > > > -- Dragi?a Duri? From hendrik at topoi.pooq.com Thu Jan 1 11:25:35 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 1 Jan 2009 05:25:35 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <495B4846.1E75.00D7.1@scires.com> References: <20081231105208.9CF4710D5DDE@birch.elegosoft.com> <495B4846.1E75.00D7.1@scires.com> Message-ID: <20090101102535.GB20605@topoi.pooq.com> On Wed, Dec 31, 2008 at 10:28:37AM -0500, Randy Coleburn wrote: > > On another note, All this CYGWIN stuff may be a nice way for die-hard > Unix fans to run Modula-3 on Windows, and I have no objection to > providing it, as long as it does not compromise the native Windows > implementation. It is useful to have a way to take Modula 3 programs from Unix to Windows with minimal change. That said, Modula-3 is a system programming language, and it should be possible to program in a system-dependent way. Do we need two Windows platforms, one native and one to run on a Unix-compatibility layer? And while we're at it, do we need two Unix platforms, one native and one that runs via Wine? > My main concern is the native implementation of > Modula-3 on Windows. My preference would be to keep the NT386 > implementation's dependencies on other stuff to a bare minimum, i.e., > don't introduce anything that would require someone to have to acquire > something besides what comes in the standard Windows OS in order to > make Modula-3 run. As it is now, we already have to get a C compiler > and linker. Fortunately, Microsoft has made the Visual Studio Express > editions a free download, so this is not too bad. Except that the free download won't work on old versions of Windows. This is the main reason why I have been unable in the past to use Modula 3 on Windows. At the moment, though, an overriding reason is that I have no Windows machines available. > I don't want to have to install CYGWIN either in order to make the > native implementation work on Windows. I also still prefer the > CMINSTALL, CMD, or BAT files for install as opposed to having to get > Python or something else. Just my 2 cents. > > Finally, I would go a step further and suggest that the Modula-3 > implementation on every platform should strive to require minimal > dependencies on anything not provided standard with that platform's > operating system. > > Call me an idealist, but it just galls me that I have to have a C > compiler/linker to build Modula-3. Modula-3 is a systems programming > language. It should stand on its own. It is not hard to write a linker in Modula-3. > From a purely economical > viewpoint, why should I have to buy something I don't want (C language > development environment) in order to have the privilege of using what > I do want (Modula-3 language development environment). What's hard is making it compatible with existing proprietary linkers and loaders that are poorly documented and subject to change without notice. > > Regards, > Randy -- hendrik From hendrik at topoi.pooq.com Thu Jan 1 15:20:48 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 1 Jan 2009 09:20:48 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <495B6B87.1E75.00D7.1@scires.com> References: <20081231105208.9CF4710D5DDE@birch.elegosoft.com> <495B4846.1E75.00D7.1@scires.com> <20090101102535.GB20605@topoi.pooq.com> <495B6B87.1E75.00D7.1@scires.com> Message-ID: <20090101142047.GA21146@topoi.pooq.com> On Wed, Dec 31, 2008 at 12:59:03PM -0500, Randy Coleburn wrote: > Hendrik: > > I agree it is useful for those accustomed to Unix to be able to work > in the Cygwin environment on Windows. I have no issue with supporting > this. Yes. But it's not what's really needed for most users of Windows machines. I was using another Unix on Windows system, M-SYS. There's a conceptual gap between M-SYS and Windows (that's the whole point, isn't it?) that brings on headaches. Windows programming should be done in Windows. > I assert that it is also very useful for non-Unix, Windows folks to be > able to work with Modula-3 in Windows without needing to know anything > about Unix, or using any Unix tools to make Modula-3 work. (BTW, I > work in both the Unix and Windows worlds, but primarily in the Windows > world lately.) Yes. Exactly. > > So yes, I suppose we do need both the native Windows and > Unix-compatibility implementations for Modula-3 on Windows. However, > I think it important to support Modula-3 natively on all platforms > rather than *requiring* a compatibility-implementation. Yes. > Thus, I would > always vote for having a native implementation first, then add a > compatibility one later, if desired. So, from my vantage point (and > others may disagree), the native Windows implementation of Modula-3 is > the number one priority on the Windows platform. Cygwin is a > "nice-to-have" for the Unix crowd, but not essential. I was trying to use Modula-3 on Windows in the days that it required a nongratis Microsoft linker, and some nongratis Microsoft linkers were reported not to be compatible. No one could guarantee that any currently available commercial linker was compatible with Modula-3. I wasn't prepared to pay for a system that had significant risk of being useless. > I don't know much about Wine, so won't comment on it. It's the Windows API implemented according to spec. And hacked up so that it is actually somewhat compatible with Windows. It could be useful to test any Windows versions of Modula-3 to see if they run under Wine. In the past quite a few programmers have discovered it's easier to debug Windows programs under Wine than under Windows, because the underlying OS doesn't crash. I don't know whether this is still the case. > > As for taking your Modula-3 programs that run on one platform, and > building and running them on other platforms, I think this is one of > the best features of Modula-3. And this is what I really wanted. > I routinely do this. Indeed, I've > tried very hard to make it possible for all my programs to be both > buildable and runable on both Unix and Windows platforms without the > need for source code modification. I've also tried to make them > interoperable across platforms, e.g. clients on one platform type, > servers on another, etc. Network Objects and Pickles have been my > friends here. > > As for the free Visual Studio stuff not working on old versions of > Windows, well yes that is a problem for those old platforms, but then, > they are old and Microsoft has dropped support for them long ago and > continuing to support them both from a hardware and software > standpoint is going to get more problematic as time goes on. It's > like my 13-year old car--the last time I had it repaired the shop had > to put out a nationwide search for the parts. I too have a 13-year-old car. The dealer used to maintain it. I switched to my local general mechanic when the dealer could no longer find replacement parts. For some reason the local mechanic has no such problem. > At some point, I'll > have to give it up. Me, too. I've been wondering whether the effort of digging it out of the snow every week or so is worth it during the winter. > > I believe you can use some old versions of Microsoft Visual C (e.g., > v6) for these old platforms, but those were not free. I recall having > to buy Microsoft C v6 when I bought CMass Reactor v4.1 many years ago. > The v6 C was pretty common, so you can probably find it around > somewhere today on the used market. Indeed, I still have my v6 C > disks. > > If you or someone else wants to build a linker for Modula-3 on > Windows, that's fine with me. Until then, we are stuck with what we > have--a free download of Visual Studio. > > As for going forward, I believe we should strive to support current > and future platforms more than working to add support for old ones. > Of course, as we move forward, it would be nice to try to maintain > support for platforms as they age, but not at the expense of > supporting newer stuff. I agree, especially since we are talking now about providing a level of support for the old system that was never available in those old days. Anyone with a Windows 95 machine that ran Modula-3 can presumably still use the system he had back then, using the linker he had back then. > This reasoning is based on trying to keep the > language alive, useful, and attractive to new programmers. If we live > in the past, Modula-3 will wither away as the current crop of > enthusiasts age and pass on. I agree. I remember a long time ago tinkering with an OS/2 port of Modula 3. I had the source for the DOS version to start with. I didn't have the time or resources to do anything serious on it though, and someone else did. I wonder what we used for a linker back in those days? > All that said, let me ask this question: Would it be useful to anyone > if I tried to put together a binary distribution of Modula-3 for the > WindowsNT 4.0 (circa 1996) platform? Not for me. Not now. I no longer use Windows. The one machine I have that used to run Windows no longer runs Windows in anything but maintenance mode (though it runs Linux with no trouble at all). What might be useful to me is an ability to cross-compile a Windows executable from a Linux machine, so I could ship the result to a non-programmer Windows user. That would probably require a lot of infrastructure work, and may not be worth it. It may be easier to buy a new Windows machine if I need that. And download the free linker, which I hope still runs on XP as well as Vista. > > I still have one of those old beasts and it does still work. I think I have one in the basement, too. I got it at a garage sale, and have never had occasion to use it. It boots, but I have user or admin password for it it. I am aware of techniques to crack the password, but the machine is probably too slow to be of much use now. -- hendrik From hosking at cs.purdue.edu Thu Jan 1 02:34:09 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 1 Jan 2009 12:34:09 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20081231105208.9CF4710D5DDE@birch.elegosoft.com> <495B4846.1E75.00D7.1@scires.com> <495B901F.1E75.00D7.1@scires.com> Message-ID: <1A450527-2CB6-41CF-982F-DA49C20EA686@cs.purdue.edu> My bandwidth is limited right now so I am unable to follow the discussion closely. But, I am uneasy with some of what I am hearing and would like to have someone provide a succinct summary of the debates. I hope that Randy, Jay, and Mika can perhaps do this. From hosking at cs.purdue.edu Thu Jan 1 02:29:24 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 1 Jan 2009 12:29:24 +1100 Subject: [M3devel] variations of waitpid..? In-Reply-To: References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> Message-ID: If someone uses waitpid they get what they paid for. On 1 Jan 2009, at 06:24, Jay wrote: > > You mean, this function is easy to misuse? >> People who declare their own <*EXTERNAL*> > Like waitpid exposed from m3core? > > waitpid is already easy to misuse, on a userthread system, leading > to possible (though I think rare) deadlock. > It is easy to misuse on pthreads, lead "just" to bad performance, > and in fact I believe cm3 is doing this, via sysutils. > This at least guides you between two patterns of use, and fix the > perf of cm3/sysutils. > > On a userthread system, waitpid(pid, flags = 0) waits for the child > process, with all parent threads suspended. > Generally I doubt the child depends on parent threads progressing, > but, yeah, that could deadlock, like if a parent thread is waiting > to a file or stdin of the child, or reading a child's stdout. > > The various uses do waitpid(pid, flags = nohang) and then sleep and > try again. > > pthreads just uses waitpid(pid, flags = 0) and all threads keep > running From jay.krell at cornell.edu Thu Jan 1 02:49:28 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 1 Jan 2009 01:49:28 +0000 Subject: [M3devel] variations of waitpid..? In-Reply-To: References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> Message-ID: > If someone uses waitpid they get what they paid for. But someone is us -- m3core/libm3 (I think just m3core), sysutils, and then cm3 uses them. I guess there is a point that this "grand new interface" SchedulerPosix.DoesWaitPidYield has precious few users. (It isn't grand. It takes no parameters and just returns a boolean, hardcoded, depending on thread library.) m3core now (today) uses it internally -- no need for a public interface. Sysutils can't use it until the baseline m3core is newer, so arguably, not a user. Instead (today) sysutils uses m3core's m3makefiles to decide the value. Heck, waitpid is therefore only used internally by m3core, and sysutils. If sysutils could be (partly) merged into m3core, then m3core's waitpid need not be public. - Jay> CC: mika> From: hosking> To: jay> Subject: Re: [M3devel] variations of waitpid..?> Date: Thu, 1 Jan 2009 12:29:24 +1100> > If someone uses waitpid they get what they paid for. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 1 02:59:50 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 1 Jan 2009 01:59:50 +0000 Subject: [M3devel] FW: variations of waitpid..? In-Reply-To: References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> Message-ID: [truncated just slightly..and probably will be again given more rambling..] ps: the internal use in m3core could be easily removed, just by compiling one branch of the if or the other. I just wanted them in the same file to keep similar code closer together. So it comes down that m3core does expose Uwaitpid.waitpid and Uexec.waitpid, and as long as they are...or as long as user threads exist..imho there is some obligation of m3core to expose perhaps surprising characteristics of its thread library. You might say the entire interface is already and has always been fully exposed in Thread.i3, but I don't believe it. User threads and kernel threads have too divergent too visible artifacts, that I don't think are previously exposed in the public interface. I claim it is somewhat "surprising", or at least important to know the detail of, whether or not waitpid yields to other threads. You know, I mean..let's say I am some really clever waitpid user and I really must use it. And I am using Modula-3 threads. And my child process is reading the output of Modula-3 threads. Aren't I kind of stuck? Isn't there /some/ obligation of m3core to help just a teeny tiny bit? Or, would you argue, I am obligated, if I am using Modula-3, to use the higher level interfaces, that already know about this? Well, ok, m3core did already know about, I fixed it only a few months ago, but then even the likes of sysutils is stuck? Another example, that may or may not be well exposed, is willingness/ability to set thread stack size. Mika mentions creation thousands of threads. 32bit kernel threads are going to be more limited here. Whereas 32bit user threads might be willing to create much smaller stacks, and 64 bit anything has essentially infinite address space for infinite stacks (but still beware working set, physical memory is not infinite). (Personally I have seen precious little code that cares about stack size, just seems to somehow get along, combined with the fact that the current Modula-3 pthread code very likely leaks on some platforms attempting to deal with stack size, makes me inclined to just rip out the code..but yeah..just fix the leak...) - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: mika at async.caltech.edu; m3devel at elegosoft.comSubject: RE: [M3devel] variations of waitpid..?Date: Thu, 1 Jan 2009 01:49:28 +0000 > If someone uses waitpid they get what they paid for. But someone is us -- m3core/libm3 (I think just m3core), sysutils, and then cm3 uses them. I guess there is a point that this "grand new interface" SchedulerPosix.DoesWaitPidYield has precious few users. (It isn't grand. It takes no parameters and just returns a boolean, hardcoded, depending on thread library.) m3core now (today) uses it internally -- no need for a public interface.Sysutils can't use it until the baseline m3core is newer, so arguably, not a user. Instead (today) sysutils uses m3core's m3makefiles to decide the value. Heck, waitpid is therefore only used internally by m3core, and sysutils.If sysutils could be (partly) merged into m3core, then m3core's waitpid need not be public. - Jay> CC: mika> From: hosking> To: jay> Subject: Re: [M3devel] variations of waitpid..?> Date: Thu, 1 Jan 2009 12:29:24 +1100> > If someone uses waitpid they get what they paid for. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.illig at gmx.de Thu Jan 1 05:18:47 2009 From: roland.illig at gmx.de (Roland Illig) Date: Thu, 01 Jan 2009 05:18:47 +0100 Subject: [M3devel] Is Modula-3 available on x86_64-unknown-linux-gnu? In-Reply-To: References: <495B4A7B.6010505@gmx.de> Message-ID: <495C4427.4090106@gmx.de> Jay schrieb: > In your config file, make sure to put -m32 on the cm3cg invocation, and > perhaps -32 or --32 on the as/gas invocation. They may or may not help. Thanks for the suggestion. I tried it (SYSTEM_CC="gcc -m32", SYSTEM_ASM="as --32"), and the program builds fine now. When running it, I get the following: Program received signal SIGSEGV, Segmentation fault. 0xdc1ca000 in ?? () (gdb) where #0 0xdc1ca000 in ?? () #1 0xf75dee30 in RTThread__FlushStackCache () at RTThread.m3:65 #2 0xf75e49ce in ThreadPosix__DetermineContext (M3_AJWxb1_oldSP=0xffb59250) at ThreadPosix.m3:1101 #3 0xf75e4932 in ThreadPosix__InitTopContext (M3_A8sSUp_c=0xf73b203c, M3_AJWxb1_stackbase=0xffb5935c) at ThreadPosix.m3:1076 #4 0xf75e5fe5 in ThreadF__Init () at ThreadPosix.m3:1498 #5 0xf75cdfcd in RTLinker__InitRuntime (M3_AcxOUs_p_argc=1, M3_AJWxb1_p_argv=0xffb59424, M3_AJWxb1_p_envp=0xffb5942c, M3_AJWxb1_p_instance=0x0) at RTLinker.m3:59 #6 0x08048901 in main (argc=1, argv=0xffb59424, envp=0xffb5942c) at _m3main.mc:3 The address 0xdc1ca000 does not appear in /proc/self/maps, so I don't know where to look further. Roland From jay.krell at cornell.edu Thu Jan 1 09:51:00 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 1 Jan 2009 08:51:00 +0000 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: <20081230021646.GA8558@jack.stsp.name> References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> Message-ID: Stefan, Please try http://modula3.elegosoft.com/cm3/uploaded-archives/. There are std and min archives there now. I haven't yet run X or tests, but the system is self hosting -- it builds itself. Let us know how it goes. Thanks, - Jay > Date: Tue, 30 Dec 2008 03:16:46 +0100> From: stefan> To: jay> CC: m3devel> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > On Mon, Dec 29, 2008 at 09:33:44PM +0000, Jay Krell wrote:> > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 08/12/29 21:33:44> > Hey Jay,> > > Log message:> > enough I386_OPENBSD support to build a bootstrap package,> > that builds on the target, and results in a cm3 that> > runs and correct errors out for lack of cm3.cfg,> > Cool, I'd like to play with this, once you have a bootstrap binary.> > Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 1 09:57:45 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 1 Jan 2009 08:57:45 +0000 Subject: [M3devel] Is Modula-3 available on x86_64-unknown-linux-gnu? In-Reply-To: <495C4427.4090106@gmx.de> References: <495B4A7B.6010505@gmx.de> <495C4427.4090106@gmx.de> Message-ID: Roland, You are using user threads. I can tell from the functions on the stack. >From what I read on this list, I gather user threads are broken on Linux due to "jumpbuf scrambling". (besides the problem I reported, which isn't in very old builds) Can you please try a newer build? ie: one that uses pthreads? > SYSTEM_CC="gcc -m32", I forgot to mention that one but yeah. :) You are using a very old build, right? - Jay> Date: Thu, 1 Jan 2009 05:18:47 +0100> From: roland> To: m3devel> Subject: Re: [M3devel] Is Modula-3 available on x86_64-unknown-linux-gnu?> > Jay schrieb:> > In your config file, make sure to put -m32 on the cm3cg invocation, and> > perhaps -32 or --32 on the as/gas invocation. They may or may not help.> > Thanks for the suggestion. I tried it (SYSTEM_CC="gcc -m32",> SYSTEM_ASM="as --32"), and the program builds fine now. When running it,> I get the following:> > Program received signal SIGSEGV, Segmentation fault.> 0xdc1ca000 in ?? ()> (gdb) where> #0 0xdc1ca000 in ?? ()> #1 0xf75dee30 in RTThread__FlushStackCache () at RTThread.m3:65> #2 0xf75e49ce in ThreadPosix__DetermineContext> (M3_AJWxb1_oldSP=0xffb59250) at ThreadPosix.m3:1101> #3 0xf75e4932 in ThreadPosix__InitTopContext (M3_A8sSUp_c=0xf73b203c,> M3_AJWxb1_stackbase=0xffb5935c) at ThreadPosix.m3:1076> #4 0xf75e5fe5 in ThreadF__Init () at ThreadPosix.m3:1498> #5 0xf75cdfcd in RTLinker__InitRuntime (M3_AcxOUs_p_argc=1,> M3_AJWxb1_p_argv=0xffb59424, M3_AJWxb1_p_envp=0xffb5942c,> M3_AJWxb1_p_instance=0x0) at RTLinker.m3:59> #6 0x08048901 in main (argc=1, argv=0xffb59424, envp=0xffb5942c)> at _m3main.mc:3> > The address 0xdc1ca000 does not appear in /proc/self/maps, so I don't> know where to look further.> > Roland -------------- next part -------------- An HTML attachment was scrubbed... URL: From stsp at elego.de Thu Jan 1 12:41:39 2009 From: stsp at elego.de (Stefan Sperling) Date: Thu, 1 Jan 2009 12:41:39 +0100 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> Message-ID: <20090101114139.GC10003@jack.stsp.name> On Thu, Jan 01, 2009 at 08:51:00AM +0000, Jay wrote: > > Stefan, Please try > [1]http://modula3.elegosoft.com/cm3/uploaded-archives/. > There are std and min archives there now. > I haven't yet run X or tests, but the system is self hosting -- it > builds itself. > Let us know how it goes. Where are the bootstrap binaries? Stefan From roland.illig at gmx.de Thu Jan 1 13:19:36 2009 From: roland.illig at gmx.de (Roland Illig) Date: Thu, 01 Jan 2009 13:19:36 +0100 Subject: [M3devel] Is Modula-3 available on x86_64-unknown-linux-gnu? In-Reply-To: References: <495B4A7B.6010505@gmx.de> <495C4427.4090106@gmx.de> Message-ID: <495CB4D8.5050400@gmx.de> Jay schrieb: > Can you please try a newer build? > ie: one that uses pthreads? I first used cm3-5.4.0, which had the problems you mentioned with the user threads. Then I tried cm3-5.5.0, which always produces an internal compiler error (Segmentation Fault) in cm3cg, which unfortunately has all debugging symbols stripped: $ /home/roland/usr.local/packages/cm3-5.5.0/bin/cm3 --- building in LINUXLIBC6 --- new source -> compiling Hello.m3 Hello.m3: In function 'Hello_M3': Hello.m3:25: internal compiler error: Segmentation fault At last I tried today's daily snapshot (5.7.0-2009-01-01-03). I was confused about the installer, which isn't interactive anymore. And if I run "./cminstall --help" or "./cminstall -?", like probably every Unix user would do, I don't even get a useful error message. Most programs print a single line that looks like: usage: ./cminstall [-verbose] [-interactive] directory That message would have been very helpful. Finally I got around this usability issue, and managed to install it. Since the installation was completely non-interactive, I edited the cm3.cfg file manually. I set SYSTEM_CC="/usr/bin/gcc -m32" and SYSTEM_AS="/usr/bin/as --32", and changed all "-L/usr/lib" into "-L/usr/lib32". Then I tried to build the hello world program, and this is what I got: $ /home/roland/usr.local/packages/cm3-5.7.0.2009.01.01/bin/cm3 --- building in LINUXLIBC6 --- new source -> compiling Hello.m3 -> linking hello $ ./LINUXLIBC6/hello Hello World! Yippieeeeh. Roland From jay.krell at cornell.edu Thu Jan 1 20:45:44 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 1 Jan 2009 19:45:44 +0000 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: <20090101114139.GC10003@jack.stsp.name> References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> <20090101114139.GC10003@jack.stsp.name> Message-ID: What do you mean by "bootstrap binaries"? There are a variety of ways to get a usable system. There is http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-I386_OPENBSD-1.tar.gz extract it (tar zxf ...) cd into it (cd ...) add -lm and -lpthread to the link line make mkdir -p /usr/local/cm3/bin mv cm3 /usr/local/cm3/bin export PATH=$PATH:/usr/local/cm3/bin export CM3_ROOT=/usr/src/cm3 or whatever export CVSROOT=:ext:stefan at m3.elegosoft.com:/usr/cvs cvs -z3 checkout cm3 cd /usr/src/scripts/python ./do-cm3-front.py buildship OR get http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-I386_OPENBSD-d5.7.0.tar.lzma cd /usr/local rm -rf cm3 lzcat cm3-min-I386_OPENBSD-d5.7.0.tar.lzma | tar xf - mv cm3-min-I386_OPENBSD-d5.7.0 cm3 or get the much larger .tar.gz file and usr zcat instead of lzcat get the source cd /usr/src/scripts/python ./do-cm3-all.py realclean && ./upgrade.py && ./do-cm3-std.py buildshipd OR get http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-I386_OPENBSD-d5.7.0.tar.lzma and not much need to build anything, but a good test to see if it is working, can follow the same instructions as for "min", it will rebuild stuff you already have. OR go to some other system, and cd $CVSROOT/m3-sys/m3cc cm3 -DM3CC_TARGET=I386_OPENBSD cd $CVSROOT/scripts/python NOTE you'll either have loosen file system privileges or /slightly/ change the code. For easy of finding it, I put the output at the root of my drive/volume/namespace. I should probably change that to be in /tmp. ./boot1.py I386_OPENBSD This gives you /cm3-boot-I386_OPENBSD-1.tar.gz (and /cm3-boot-I386_OPENBSD-1, but again, I should move these to "temp"), which you ftp or rcp or scp or whatever to the I386_OPENBSD machine and pick up at the first set of steps -- that's how I get new platforms working, though sometimes you can cheat on "biarch" systems, e.g. you can bring up AMD64_LINUX via LINUXLIBC6, just on one machine, no need to copy across machines and can skip the "boot" process and build more in one step, AMD64_FREEBSD via FreeBSD4, etc..)) - Jay> Date: Thu, 1 Jan 2009 12:41:39 +0100> From: stsp at elego.de> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: I386_OPENBSD uploaded-archives> > On Thu, Jan 01, 2009 at 08:51:00AM +0000, Jay wrote:> > > > Stefan, Please try> > [1]http://modula3.elegosoft.com/cm3/uploaded-archives/.> > There are std and min archives there now.> > I haven't yet run X or tests, but the system is self hosting -- it> > builds itself.> > Let us know how it goes.> > Where are the bootstrap binaries?> > Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 1 21:04:36 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 1 Jan 2009 20:04:36 +0000 Subject: [M3devel] Is Modula-3 available on x86_64-unknown-linux-gnu? In-Reply-To: <495CB4D8.5050400@gmx.de> References: <495B4A7B.6010505@gmx.de> <495C4427.4090106@gmx.de> <495CB4D8.5050400@gmx.de> Message-ID: /usr/lib32, good point, we can/should handle that automatically. If word size 32bits and /usr/lib32 exists, use it instead of /usr/lib. Similarly for /usr/lib64. etc. When I get back I'll fiddle with m3-sys/cminstall/src/config-no-install. I never use cminstall. I suggest http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-LINUXLIBC6-d5.7.0.tar.bz2 or http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-LINUXLIBC6-d5.7.0.tar.bz2 though I guess they need a readme. They would admittedly probably have the same problem but I can fix that easily. (-m32/--32 maybe not, but /usr/lib vs. /usr/lib32 probably.) You might also try the native: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-AMD64_LINUX-d5.7.0.tar.gz or http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-AMD64_LINUX-d5.7.0.tar.gz "min" contains only the compiler and m3core and libm3. "std" contains "everything" -- everything that currently builds successfully. - Jay> Date: Thu, 1 Jan 2009 13:19:36 +0100> From: roland.illig at gmx.de> To: m3devel at elegosoft.com> Subject: Re: [M3devel] Is Modula-3 available on x86_64-unknown-linux-gnu?> > Jay schrieb:> > Can you please try a newer build?> > ie: one that uses pthreads?> > I first used cm3-5.4.0, which had the problems you mentioned with the> user threads.> > Then I tried cm3-5.5.0, which always produces an internal compiler error> (Segmentation Fault) in cm3cg, which unfortunately has all debugging> symbols stripped:> > $ /home/roland/usr.local/packages/cm3-5.5.0/bin/cm3> --- building in LINUXLIBC6 ---> > new source -> compiling Hello.m3> Hello.m3: In function 'Hello_M3':> Hello.m3:25: internal compiler error: Segmentation fault> > At last I tried today's daily snapshot (5.7.0-2009-01-01-03). I was> confused about the installer, which isn't interactive anymore. And if I> run "./cminstall --help" or "./cminstall -?", like probably every Unix> user would do, I don't even get a useful error message. Most programs> print a single line that looks like:> > usage: ./cminstall [-verbose] [-interactive] directory> > That message would have been very helpful. Finally I got around this> usability issue, and managed to install it. Since the installation was> completely non-interactive, I edited the cm3.cfg file manually. I set> SYSTEM_CC="/usr/bin/gcc -m32" and SYSTEM_AS="/usr/bin/as --32", and> changed all "-L/usr/lib" into "-L/usr/lib32". Then I tried to build the> hello world program, and this is what I got:> > $ /home/roland/usr.local/packages/cm3-5.7.0.2009.01.01/bin/cm3> --- building in LINUXLIBC6 ---> > new source -> compiling Hello.m3> -> linking hello> $ ./LINUXLIBC6/hello> Hello World!> > Yippieeeeh.> > Roland -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.illig at gmx.de Thu Jan 1 21:10:09 2009 From: roland.illig at gmx.de (Roland Illig) Date: Thu, 01 Jan 2009 21:10:09 +0100 Subject: [M3devel] Is Modula-3 available on x86_64-unknown-linux-gnu? In-Reply-To: References: <495B4A7B.6010505@gmx.de> <495C4427.4090106@gmx.de> <495CB4D8.5050400@gmx.de> Message-ID: <495D2321.1040205@gmx.de> Jay schrieb: > http://modula3.elegosoft.com/cm3/uploaded-archives/ That's nice. I didn't know about this directory before. Roland From rodney.bates at wichita.edu Thu Jan 1 20:02:17 2009 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 01 Jan 2009 13:02:17 -0600 Subject: [M3devel] TEXT & etc. In-Reply-To: <200812310822.mBV8Mf2j027994@camembert.async.caltech.edu> References: <200812310822.mBV8Mf2j027994@camembert.async.caltech.edu> Message-ID: <495D1339.2070703@wichita.edu> I started working on a more elaborate package of performance improvements to TEXT operations. They are algorithm-only (no changes to declarations or invariants of data structure), thus no effect on pickles, stubs, etc., as is your change. I am flattening concatenations only when the result has finite bounded length, keeping Text.Cat O(1), although with considerably larger constant factor. I am also doing two-level rebalancing of trees, also O(1). Without knowing depths (which would require either an O(log N) algorithm to compute then or caching them, requiring data structure changes), I am using lengths as a crude estimate of depth. Meanwhile I am recoding get_chars/get_wide_chars to recurse on only the shorter side and iterate on the other. This, in combination with better balance, should cut down greatly on stack depth and execution time. I am also avoiding cases where a number of other operations in the current implementation unnecessarily convert concatenations containing only 8-bit representations to 16, which requires a character-by-character loop to expand them. I also have found a couple of bugs. Hopefully, these will help. Mika Nystrom wrote: > Hello everyone, > > I mentioned a week or two ago that I had run into horrific performance > issues with CM3's TEXTs. It wasn't my intention to start a debate > about Unicode and Mahjong characters, just to point out that there's > a serious performance problem with CM3 in this area. I run into > performance problems with CM3 from time to time because I am trying > to maintain a fairly large amount of software written in Modula-3 > and it appears to me that the SRC/PM3 compilers often pay better > attention to performance issues than the newer CM3 compiler. > Generally speaking I think Modula-3 needs to avoid getting into the > Java situation: Java is squeezed between "fast enough" Python and > "much more efficient" C++... Modula-3 I see as the only hope for > getting the performance of C++ with the safety of Java. The problems > I have seen with CM3 are in the following areas: > > 1. Thread mutex acquisition involving kernel calls (pthreads > implementation) > > 2. ISTYPE and TYPECASE (appear much faster on PM3, don't know why, > could just be a profiling issue). In any case TYPECASE is very slow > because of having to search the type tree. This could be improved > but I can't work on it because I always run into some kind of fatal > problem trying to bootstrap the compiler. > > 3. The TEXT issue. I mentioned performance problems before. It turns > out that it was showing up in another area. I upgraded my PowerBook > a while back (to OS X 10.4) and of course everything stopped working, > including at least half my Modula-3 programs. I thought it was a > versioning problem with C libraries I was importing, but it turned out > that in at least one case I was running out of stack space because of > the calls to get_char on concatenated TEXTs. (Not very long ones, > at that.) > > To get to the point. What follows is my new version of TextCat.m3, > which I believe works, but I can't really say because I'm perennially > incapable of bootstrapping CM3. The basic idea is that you can > have *one* TextCat.T, at the "root" of your TEXT. It will flatten > anything else. > > I don't see a simple way of modifying the CM3 TEXT implementation to > do much better than this. Of course throwing out TextCat.T completely > is an option. > > An advantage of what I've done is that I haven't changed any interfaces > at all. So I don't get problems with version stamps, etc. > > Mika > > From martinbishop at bellsouth.net Fri Jan 2 04:53:29 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Thu, 01 Jan 2009 21:53:29 -0600 Subject: [M3devel] Modula-3 auto keyword upcase Message-ID: <495D8FB9.6030800@bellsouth.net> I use the Modula-3 elisp code for Emacs to edit Modula-3 source, but it's somewhat annoying having to hit TAB to complete keywords (otherwise I have to hold shift to type them out). I have used an Oberon mode for Emacs before, that would auto upcase the keywords. If you typed 'module' and then pressed space, it would become 'MODULE', etc. I tried to modify the code from the Oberon mode and add it to the Modula-3 mode, but I had no luck. Does anyone know of any Modula-3 elisp code that does this? Or is there another editor that is capable of this? I have NEdit and jEdit, both have Modula-3 highlighting support, but neither help in actually editing Modula-3 code. From jay.krell at cornell.edu Fri Jan 2 08:02:34 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 2 Jan 2009 07:02:34 +0000 Subject: [M3devel] meaning of unsafe? Message-ID: Recent quote, that I haven't further investigated, made me realize some of my ignorance. I know that "unsafe" includes: taking address of local explicit free dealing with any untraced ref? Not sure. Questions are: is unsafe well statically enforced? and/or is safe well statically enforced? That is, should I remove unsafe "everywhere", as long as it compiles ok, it must be safe, and better, so leave it that way? And if it fails, put it back? Or do I need to think about it myself? I think for modules it might be brainless as stated -- put it in only where the compiler makes, and nowhere extra, since extra is a loss not a bonus. But for interfaces.. I think, again, ideal to remove it where you can, but that the compiler can't enforce it? At least where there is "external"? Maybe I should just reread that quote, and thing about it. Safe can code call unsafe code, but should not be able to do so with parameters that, indirectly, make the safe code unsafe. For example, I cannot safe call "free" in unsafe code on behalf of safe code, unless I am darn sure the data isn't referenced -- unless I am the garbage collector. Any pointer give to unsafe code by safe code must not be stored "long term" -- ie: in the heap or globals, because it could be a stack pointer. Unless, well, duh..ok, any VAR parameter or UNTRACED REF passed to unsafe code, what I just said, but traced refs can be held onto -- they are by definition not stack pointers. I guess, you know..programming C code that interacts with Modula-3 code..you realize the incompleteness of the C type system. Modula-3 has, let's say, var, traced ref, and untraced ref. C just has pointers. The compiler doesn't know any better, the programmer has to. If you imagine a Modula-3 to C header compiler..which I would like..you know, it outputs C headers that map FROM Modula-3 interfaces (instead of the usual hand translations in either direction), it would likely lose a lot of information and only be for special purpose use, unless, unlikely, not likely valuable, this problem was solved. Which..oh, this is interesting..I can see, to solve this, you'd need an "API" for storing pointers perhaps. Something perhaps to make sure the pointer is allowed to be stored like such. Not sure. But I suspect this "API" is related to the "checks" that the Modula-3 compiler generates...I really need to understand those... Generally this is easy, because generally things are "synchronous" -- generally the C code doesn't hold on to its parameters beyond the lifetime of itself -- doesn't store it in the heap or globally for other threads to use, and generally the Modula-3 code isn't busy freeing the parameters on another thread, in fact VAR parameters cannot be freed, they are on the stack, and traced refs can only be freed..if the garbage collector can't find any references to them..and then untraced refs require "discipline" both in the Modula-3 code and the C code, but again generally, saved by "synchronicity" -- C code doesn't hold on to them, Modula-3 code doesn't free them on another thread. Those scenarios are certainly possible, just not all that common, and as soon as you "escape" to safe Modula-3 code, not a possibility..no untraced refs.. About right? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Fri Jan 2 08:27:24 2009 From: darko at darko.org (Darko) Date: Fri, 2 Jan 2009 16:27:24 +0900 Subject: [M3devel] meaning of unsafe? In-Reply-To: References: Message-ID: <12ACA122-57EC-4AA1-A250-9E22B71AC2DD@darko.org> Safety is a property of the language, not the procedures. A safe module is one that doesn't use unsafe features and means the language will guarantee that you will get no unchecked errors when you run the code. And that guarantee is dependent on the compiler and language definition being bug free. Outside that of that it is like asking if rocks feel guilty. External modules are not written in M3 so they have no possibility of safety in the M3 sense, unless they were written in a language with an equivalent definition to M3. They might be reliable or bug free, but that's not the same thing. On 02/01/2009, at 4:02 PM, Jay wrote: > Recent quote, that I haven't further investigated, made me realize > some of my ignorance. > > I know that "unsafe" includes: > taking address of local > explicit free > dealing with any untraced ref? Not sure. > > Questions are: > is unsafe well statically enforced? > and/or is safe well statically enforced? > > That is, should I remove unsafe "everywhere", as long as it compiles > ok, it must be safe, and better, so leave it that way? And if it > fails, put it back? > > Or do I need to think about it myself? > > I think for modules it might be brainless as stated -- put it in > only where the compiler makes, and nowhere extra, since extra is a > loss not a bonus. > > But for interfaces.. I think, again, ideal to remove it where you > can, but that the compiler can't enforce it? At least where there is > "external"? > Maybe I should just reread that quote, and thing about it. > > Safe can code call unsafe code, but should not be able to do so with > parameters that, indirectly, make the safe code unsafe. For example, > I cannot safe call "free" in unsafe code on behalf of safe code, > unless I am darn sure the data isn't referenced -- unless I am the > garbage collector. Any pointer give to unsafe code by safe code must > not be stored "long term" -- ie: in the heap or globals, because it > could be a stack pointer. Unless, well, duh..ok, any VAR parameter > or UNTRACED REF passed to unsafe code, what I just said, but traced > refs can be held onto -- they are by definition not stack pointers. > > I guess, you know..programming C code that interacts with Modula-3 > code..you realize the incompleteness of the C type system. Modula-3 > has, let's say, var, traced ref, and untraced ref. C just has > pointers. The compiler doesn't know any better, the programmer has to. > > If you imagine a Modula-3 to C header compiler..which I would > like..you know, it outputs C headers that map FROM Modula-3 > interfaces (instead of the usual hand translations in either > direction), it would likely lose a lot of information and only be > for special purpose use, unless, unlikely, not likely valuable, this > problem was solved. > Which..oh, this is interesting..I can see, to solve this, you'd need > an "API" for storing pointers perhaps. Something perhaps to make > sure the pointer is allowed to be stored like such. Not sure. But I > suspect this "API" is related to the "checks" that the Modula-3 > compiler generates...I really need to understand those... > > > Generally this is easy, because generally things are "synchronous" > -- generally the C code doesn't hold on to its parameters beyond the > lifetime of itself -- doesn't store it in the heap or globally for > other threads to use, and generally the Modula-3 code isn't busy > freeing the parameters on another thread, in fact VAR parameters > cannot be freed, they are on the stack, and traced refs can only be > freed..if the garbage collector can't find any references to > them..and then untraced refs require "discipline" both in the > Modula-3 code and the C code, but again generally, saved by > "synchronicity" -- C code doesn't hold on to them, Modula-3 code > doesn't free them on another thread. Those scenarios are certainly > possible, just not all that common, and as soon as you "escape" to > safe Modula-3 code, not a possibility..no untraced refs.. > > > About right? > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jan 2 09:16:18 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 2 Jan 2009 08:16:18 +0000 Subject: [M3devel] meaning of unsafe? In-Reply-To: <12ACA122-57EC-4AA1-A250-9E22B71AC2DD@darko.org> References: <12ACA122-57EC-4AA1-A250-9E22B71AC2DD@darko.org> Message-ID: The language offers optional safety, therefore safety has a meaning "among" modules and interfaces. (heck, it might be interesting to have safe/unsafe functions, or even blocks of code -- C# has safe/unsafe blocks of code, like unsafe { do stuff }) What is the meaning of an unsafe interface vs. a safe interface? I see one thing -- an unsafe module cannot import from a safe interface. I tried that. I think you or Mika summed it up -- safe code can call into unsafe code, but doing so must not violate "the usual safety" constraints". Therefore, unsafe code must be "careful", i.e. bug-free (well, not logically bug-free, but type-system bug-free -- no use of freed pointers (nor dangling stack pointers, nor invalid addresses in general), no double frees, no buffer overflows (or underflows), no integer overflows, etc., and don't call into any such code either). - Jay From: darko at darko.orgTo: jay.krell at cornell.eduDate: Fri, 2 Jan 2009 16:27:24 +0900CC: m3devel at elegosoft.comSubject: Re: [M3devel] meaning of unsafe? Safety is a property of the language, not the procedures. A safe module is one that doesn't use unsafe features and means the language will guarantee that you will get no unchecked errors when you run the code. And that guarantee is dependent on the compiler and language definition being bug free. Outside that of that it is like asking if rocks feel guilty. External modules are not written in M3 so they have no possibility of safety in the M3 sense, unless they were written in a language with an equivalent definition to M3. They might be reliable or bug free, but that's not the same thing. On 02/01/2009, at 4:02 PM, Jay wrote: Recent quote, that I haven't further investigated, made me realize some of my ignorance. I know that "unsafe" includes: taking address of local explicit free dealing with any untraced ref? Not sure. Questions are: is unsafe well statically enforced? and/or is safe well statically enforced? That is, should I remove unsafe "everywhere", as long as it compiles ok, it must be safe, and better, so leave it that way? And if it fails, put it back? Or do I need to think about it myself? I think for modules it might be brainless as stated -- put it in only where the compiler makes, and nowhere extra, since extra is a loss not a bonus. But for interfaces.. I think, again, ideal to remove it where you can, but that the compiler can't enforce it? At least where there is "external"?Maybe I should just reread that quote, and thing about it. Safe can code call unsafe code, but should not be able to do so with parameters that, indirectly, make the safe code unsafe. For example, I cannot safe call "free" in unsafe code on behalf of safe code, unless I am darn sure the data isn't referenced -- unless I am the garbage collector. Any pointer give to unsafe code by safe code must not be stored "long term" -- ie: in the heap or globals, because it could be a stack pointer. Unless, well, duh..ok, any VAR parameter or UNTRACED REF passed to unsafe code, what I just said, but traced refs can be held onto -- they are by definition not stack pointers. I guess, you know..programming C code that interacts with Modula-3 code..you realize the incompleteness of the C type system. Modula-3 has, let's say, var, traced ref, and untraced ref. C just has pointers. The compiler doesn't know any better, the programmer has to. If you imagine a Modula-3 to C header compiler..which I would like..you know, it outputs C headers that map FROM Modula-3 interfaces (instead of the usual hand translations in either direction), it would likely lose a lot of information and only be for special purpose use, unless, unlikely, not likely valuable, this problem was solved. Which..oh, this is interesting..I can see, to solve this, you'd need an "API" for storing pointers perhaps. Something perhaps to make sure the pointer is allowed to be stored like such. Not sure. But I suspect this "API" is related to the "checks" that the Modula-3 compiler generates...I really need to understand those... Generally this is easy, because generally things are "synchronous" -- generally the C code doesn't hold on to its parameters beyond the lifetime of itself -- doesn't store it in the heap or globally for other threads to use, and generally the Modula-3 code isn't busy freeing the parameters on another thread, in fact VAR parameters cannot be freed, they are on the stack, and traced refs can only be freed..if the garbage collector can't find any references to them..and then untraced refs require "discipline" both in the Modula-3 code and the C code, but again generally, saved by "synchronicity" -- C code doesn't hold on to them, Modula-3 code doesn't free them on another thread. Those scenarios are certainly possible, just not all that common, and as soon as you "escape" to safe Modula-3 code, not a possibility..no untraced refs.. About right? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Fri Jan 2 09:24:28 2009 From: darko at darko.org (Darko) Date: Fri, 2 Jan 2009 17:24:28 +0900 Subject: [M3devel] meaning of unsafe? In-Reply-To: References: <12ACA122-57EC-4AA1-A250-9E22B71AC2DD@darko.org> Message-ID: <408EB16D-82D8-47DF-A036-10AA25CC5C69@darko.org> The language def says: In unsafe interfaces and modules the definition of "assignable" for types is extended: two reference types T and U are assignable if T <: U or U <: T. The only effect of this change is to allow a value of type ADDRESS to be assigned to a variable of type UNTRACED REF T. It is an unchecked runtime error if the value does not address a variable of type T. In unsafe interfaces and modules the type constructor UNTRACED REF T is allowed for traced as well as untraced T, and the fields of untraced objects can be traced. If u is an untraced reference to a traced variable t, then the validity of the traced references in t is implementation-dependent, since the garbage collector probably will not trace them through u. On 02/01/2009, at 5:16 PM, Jay wrote: > The language offers optional safety, therefore safety has a meaning > "among" modules and interfaces. > (heck, it might be interesting to have safe/unsafe functions, or > even blocks of code -- C# has safe/unsafe blocks of code, like > unsafe { do stuff }) > > What is the meaning of an unsafe interface vs. a safe interface? > > I see one thing -- an unsafe module cannot import from a safe > interface. > I tried that. > > I think you or Mika summed it up -- safe code can call into unsafe > code, but doing so must not violate "the usual safety" constraints". > Therefore, unsafe code must be "careful", i.e. bug-free (well, not > logically bug-free, but type-system bug-free -- no use of freed > pointers (nor dangling stack pointers, nor invalid addresses in > general), no double frees, no buffer overflows (or underflows), no > integer overflows, etc., and don't call into any such code either). > > - Jay > > > > From: darko at darko.org > To: jay.krell at cornell.edu > Date: Fri, 2 Jan 2009 16:27:24 +0900 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] meaning of unsafe? > > > Safety is a property of the language, not the procedures. A safe > module is one that doesn't use unsafe features and means the > language will guarantee that you will get no unchecked errors when > you run the code. And that guarantee is dependent on the compiler > and language definition being bug free. > > Outside that of that it is like asking if rocks feel guilty. > External modules are not written in M3 so they have no possibility > of safety in the M3 sense, unless they were written in a language > with an equivalent definition to M3. They might be reliable or bug > free, but that's not the same thing. > > > On 02/01/2009, at 4:02 PM, Jay wrote: > > Recent quote, that I haven't further investigated, made me realize > some of my ignorance. > > I know that "unsafe" includes: > taking address of local > explicit free > dealing with any untraced ref? Not sure. > > Questions are: > is unsafe well statically enforced? > and/or is safe well statically enforced? > > That is, should I remove unsafe "everywhere", as long as it compiles > ok, it must be safe, and better, so leave it that way? And if it > fails, put it back? > > Or do I need to think about it myself? > > I think for modules it might be brainless as stated -- put it in > only where the compiler makes, and nowhere extra, since extra is a > loss not a bonus. > > But for interfaces.. I think, again, ideal to remove it where you > can, but that the compiler can't enforce it? At least where there is > "external"? > Maybe I should just reread that quote, and thing about it. > > Safe can code call unsafe code, but should not be able to do so with > parameters that, indirectly, make the safe code unsafe. For example, > I cannot safe call "free" in unsafe code on behalf of safe code, > unless I am darn sure the data isn't referenced -- unless I am the > garbage collector. Any pointer give to unsafe code by safe code must > not be stored "long term" -- ie: in the heap or globals, because it > could be a stack pointer. Unless, well, duh..ok, any VAR parameter > or UNTRACED REF passed to unsafe code, what I just said, but traced > refs can be held onto -- they are by definition not stack pointers. > > I guess, you know..programming C code that interacts with Modula-3 > code..you realize the incompleteness of the C type system. Modula-3 > has, let's say, var, traced ref, and untraced ref. C just has > pointers. The compiler doesn't know any better, the programmer has to. > > If you imagine a Modula-3 to C header compiler..which I would > like..you know, it outputs C headers that map FROM Modula-3 > interfaces (instead of the usual hand translations in either > direction), it would likely lose a lot of information and only be > for special purpose use, unless, unlikely, not likely valuable, this > problem was solved. > Which..oh, this is interesting..I can see, to solve this, you'd need > an "API" for storing pointers perhaps. Something perhaps to make > sure the pointer is allowed to be stored like such. Not sure. But I > suspect this "API" is related to the "checks" that the Modula-3 > compiler generates...I really need to understand those... > > > Generally this is easy, because generally things are "synchronous" > -- generally the C code doesn't hold on to its parameters beyond the > lifetime of itself -- doesn't store it in the heap or globally for > other threads to use, and generally the Modula-3 code isn't busy > freeing the parameters on another thread, in fact VAR parameters > cannot be freed, they are on the stack, and traced refs can only be > freed..if the garbage collector can't find any references to > them..and then untraced refs require "discipline" both in the > Modula-3 code and the C code, but again generally, saved by > "synchronicity" -- C code doesn't hold on to them, Modula-3 code > doesn't free them on another thread. Those scenarios are certainly > possible, just not all that common, and as soon as you "escape" to > safe Modula-3 code, not a possibility..no untraced refs.. > > > About right? > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Jan 2 11:15:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 02 Jan 2009 11:15:25 +0100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <495B901F.1E75.00D7.1@scires.com> References: <20081231105208.9CF4710D5DDE@birch.elegosoft.com> <495B4846.1E75.00D7.1@scires.com> <495B901F.1E75.00D7.1@scires.com> Message-ID: <20090102111525.16anbdkwg8ocg44k@mail.elegosoft.com> See below (still trying to catch up on M3 mails ;-) Quoting Randy Coleburn : > Jay: > > First, I do want to say thanks for all you are doing for the cause > of Modula-3. I don't think we say thanks enough for what others do > for us. THANK YOU! > > I don't want to be perceived as "complaining", rather I am trying to > voice my opinion in the hopes of influencing future direction. Of > course, since I'm not doing the work, I can only make suggestions. > > In reading your post, you state that you deoptimized the native > implementation to make it match Cygwin. Now, I'm not sure how much > effect this deoptimization has (maybe little), but it is clear that > in this case your implementation choice has favored the non-native > implementation over the native one. IMO, tradeoffs of this type are > not good. If one is trying to convince someone to use Modula-3, > why would you want to give them a "deoptimized" version just to > make it easier to support a non-native environment---indeed, one > that they may not even want/use? If we have to make a trade-off, I > say favor the native implementation always over the non-native one. > > What I'm trying to say here is that my experience as a software, > systems, and program engineer is that I've always been forced to > justify the cost/benefit of development tools for any project. Many > times I've had to go head to head with folks higher up in my own > organization or in the customer's organization whose preconceived > opinions were based on rumor and what they've heard rather than > actual factual hands-on experience. I want to pick the best tool > for the job instead of being forced to pick an inferior tool because > someone higher in the food chain demanded it based on faulty > preconceived opinion. I like Modula-3. I've found that I am more > productive using it. But, if the compiler doesn't produce efficient > code, I lose ground in arguing with the higher-ups. > > As for Python, I've never ventured to learn it, so for me, it is > something of a mystery. But you miss the point. I'm not arguing > the merits of Python, I'm just saying that anything Modula-3 > requires on top of what is provided by the standard host platform > represents a potential obstacle or barrier to ease of > use/implementation. It also sends the message that somehow Modula-3 > is not complete on its own, we have get Python just to install and > oh yes we need a C compiler and a linker and a ...? IMO, > ultimately we need a turn-key download and install routine for > Modula-3 that just works, out-of-the-box. If you give me an EXE, a > CMD, or a BAT, for the install, I can run it on Windows, but if you > give me an install routine that requires I first install something > else, e.g. Python, then that becomes a barrier to the folks who > don't know Python or already have it installed. > > Am I alone in this line of thought? If so, I'll just be quiet. No, you're not alone here. Ultimately, I think we should have something that installs very easily without any preconditions, too. But it is difficult to achieve and maintain this quality in an open source project with so few volunteers. So I am afraid that there will have to be some tradeoffs, but we should try to keep them reasonably small. Thus said, I think it is great that you are speaking up here, as great as it is that Jay is doing this great amount of work for M3. It is important that changes are reviewed and reasons are questioned for the overall quality of the project. And as long as we are polite and argue reasonably and not personally, this is only good for the project, too. Thanks to all who are contributing to the M3 delevopment, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Jan 2 11:27:24 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 02 Jan 2009 11:27:24 +0100 Subject: [M3devel] variations of waitpid..? In-Reply-To: References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> Message-ID: <20090102112724.5sr7fnp000cokcco@mail.elegosoft.com> Quoting Tony Hosking : > If someone uses waitpid they get what they paid for. It is so long ago that we wrote those sysutils routines... They have only ever be used in simple command line utilities (like cm3) without much concurrency, I think. If there is potential for deadlocks and bad performance, we should at least document that in the interfaces. I am not up-to-date wrt. the M3 system interfaces and threads implementation: is there a way for a thread to wait for the exit code of another process without blocking other threads? If so, I'll adapt the sysutils code... If not, can we introduce such an interface in m3core/libm3? Olaf > On 1 Jan 2009, at 06:24, Jay wrote: > >> >> You mean, this function is easy to misuse? >>> People who declare their own <*EXTERNAL*> >> Like waitpid exposed from m3core? >> >> waitpid is already easy to misuse, on a userthread system, leading >> to possible (though I think rare) deadlock. >> It is easy to misuse on pthreads, lead "just" to bad performance, >> and in fact I believe cm3 is doing this, via sysutils. >> This at least guides you between two patterns of use, and fix the >> perf of cm3/sysutils. >> >> On a userthread system, waitpid(pid, flags = 0) waits for the child >> process, with all parent threads suspended. >> Generally I doubt the child depends on parent threads progressing, >> but, yeah, that could deadlock, like if a parent thread is waiting >> to a file or stdin of the child, or reading a child's stdout. >> >> The various uses do waitpid(pid, flags = nohang) and then sleep and >> try again. >> >> pthreads just uses waitpid(pid, flags = 0) and all threads keep running -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Jan 2 11:32:57 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 02 Jan 2009 11:32:57 +0100 Subject: [M3devel] FW: variations of waitpid..? In-Reply-To: References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> Message-ID: <20090102113257.me6vseyaskggssoc@mail.elegosoft.com> Quoting Jay : > (Personally I have seen precious little code that cares about stack > size, just seems to somehow get along, combined with the fact that > the current Modula-3 pthread code very likely leaks on some > platforms attempting to deal with stack size, makes me inclined to > just rip out the code..but yeah..just fix the leak...) Please don't do that (remove the ability to set stack sizes). I know that for most of the programs I wrote years ago we had to adapt stack sizes for threads carefully. That was with user threads though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Jan 2 11:42:48 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 02 Jan 2009 11:42:48 +0100 Subject: [M3devel] TEXT & etc. In-Reply-To: <495D1339.2070703@wichita.edu> References: <200812310822.mBV8Mf2j027994@camembert.async.caltech.edu> <495D1339.2070703@wichita.edu> Message-ID: <20090102114248.lcnartw3eowcs4gg@mail.elegosoft.com> Quoting "Rodney M. Bates" : > I started working on a more elaborate package of performance improvements > to TEXT operations. They are algorithm-only (no changes to declarations or > invariants of data structure), thus no effect on pickles, stubs, etc., as > is your change. > > I am flattening concatenations only when the result has finite bounded > length, keeping Text.Cat O(1), although with considerably larger constant > factor. I am also doing two-level rebalancing of trees, also O(1). > Without knowing depths (which would require either an O(log N) algorithm > to compute then or caching them, requiring data structure changes), I am > using lengths as a crude estimate of depth. > > Meanwhile I am recoding get_chars/get_wide_chars to recurse on only > the shorter side and iterate on the other. This, in combination with > better balance, should cut down greatly on stack depth and execution > time. > > I am also avoiding cases where a number of other operations in the current > implementation unnecessarily convert concatenations containing only 8-bit > representations to 16, which requires a character-by-character loop > to expand them. > > I also have found a couple of bugs. All this sounds good. Have you already committed some of your work? (I'm not following m3commit closely these days.) Have you also some test cases that will validate the TEXT behaviour for concatenations etc.? Olaf > Hopefully, these will help. > > Mika Nystrom wrote: >> Hello everyone, >> >> I mentioned a week or two ago that I had run into horrific performance >> issues with CM3's TEXTs. It wasn't my intention to start a debate >> about Unicode and Mahjong characters, just to point out that there's >> a serious performance problem with CM3 in this area. I run into >> performance problems with CM3 from time to time because I am trying >> to maintain a fairly large amount of software written in Modula-3 >> and it appears to me that the SRC/PM3 compilers often pay better >> attention to performance issues than the newer CM3 compiler. >> Generally speaking I think Modula-3 needs to avoid getting into the >> Java situation: Java is squeezed between "fast enough" Python and >> "much more efficient" C++... Modula-3 I see as the only hope for >> getting the performance of C++ with the safety of Java. The problems >> I have seen with CM3 are in the following areas: >> >> 1. Thread mutex acquisition involving kernel calls (pthreads >> implementation) >> >> 2. ISTYPE and TYPECASE (appear much faster on PM3, don't know why, >> could just be a profiling issue). In any case TYPECASE is very slow >> because of having to search the type tree. This could be improved >> but I can't work on it because I always run into some kind of fatal >> problem trying to bootstrap the compiler. >> >> 3. The TEXT issue. I mentioned performance problems before. It >> turns out that it was showing up in another area. I upgraded my >> PowerBook >> a while back (to OS X 10.4) and of course everything stopped working, >> including at least half my Modula-3 programs. I thought it was a >> versioning problem with C libraries I was importing, but it >> turned out >> that in at least one case I was running out of stack space because of >> the calls to get_char on concatenated TEXTs. (Not very long ones, >> at that.) >> >> To get to the point. What follows is my new version of TextCat.m3, >> which I believe works, but I can't really say because I'm perennially >> incapable of bootstrapping CM3. The basic idea is that you can >> have *one* TextCat.T, at the "root" of your TEXT. It will flatten >> anything else. I don't see a simple way of modifying the CM3 TEXT >> implementation to do much better than this. Of course throwing out >> TextCat.T completely >> is an option. >> >> An advantage of what I've done is that I haven't changed any interfaces >> at all. So I don't get problems with version stamps, etc. >> >> Mika >> >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.bates at wichita.edu Fri Jan 2 18:29:26 2009 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 02 Jan 2009 11:29:26 -0600 Subject: [M3devel] TEXT & etc. In-Reply-To: <20090102114248.lcnartw3eowcs4gg@mail.elegosoft.com> References: <200812310822.mBV8Mf2j027994@camembert.async.caltech.edu> <495D1339.2070703@wichita.edu> <20090102114248.lcnartw3eowcs4gg@mail.elegosoft.com> Message-ID: <495E4EF6.6030406@wichita.edu> No, I have not committed anything yet. I have it temporarily coded so the the operations can be switched between the old and new versions by setting a (gasp!) global variable. I plan to write a test program that generates many (10s of thousands) of random operations on texts, does them using old and new algorithms, and compares results. I have used this testing approach on several projects in the past, with very good success. My preferred development style is to get a group of related changes complete and tested before committing anything. For one thing, that saves me from having to retest after every little change. Just since my previous post, I have already had to do some rethinking about how much and what kind of rebalancing to do. Olaf Wagner wrote: > Quoting "Rodney M. Bates" : > >> I started working on a more elaborate package of performance improvements >> to TEXT operations. They are algorithm-only (no changes to >> declarations or >> invariants of data structure), thus no effect on pickles, stubs, etc., as >> is your change. >> >> I am flattening concatenations only when the result has finite bounded >> length, keeping Text.Cat O(1), although with considerably larger constant >> factor. I am also doing two-level rebalancing of trees, also O(1). >> Without knowing depths (which would require either an O(log N) algorithm >> to compute then or caching them, requiring data structure changes), I am >> using lengths as a crude estimate of depth. >> >> Meanwhile I am recoding get_chars/get_wide_chars to recurse on only >> the shorter side and iterate on the other. This, in combination with >> better balance, should cut down greatly on stack depth and execution >> time. >> >> I am also avoiding cases where a number of other operations in the >> current >> implementation unnecessarily convert concatenations containing only 8-bit >> representations to 16, which requires a character-by-character loop >> to expand them. >> >> I also have found a couple of bugs. > > All this sounds good. Have you already committed some of your work? > (I'm not following m3commit closely these days.) > Have you also some test cases that will validate the TEXT behaviour > for concatenations etc.? > > Olaf > > From jay.krell at cornell.edu Fri Jan 2 19:18:20 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 2 Jan 2009 18:18:20 +0000 Subject: [M3devel] variations of waitpid..? In-Reply-To: <20090102112724.5sr7fnp000cokcco@mail.elegosoft.com> References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> <20090102112724.5sr7fnp000cokcco@mail.elegosoft.com> Message-ID: > is there a way for a thread to wait for the exit code> of another process without blocking other threads? If so, I'll adapt Yes, by using kernel threads (which is all that work currently, but I'll probably fix that..) If you know you are using kernel threads, you can optimize accordingly. I measured the difference when I fixed m3core/libm3 and it was significant, though I forgot the details (they should be in the m3commit or m3devel history). I didn't measure for sysutils. It seems to me that sysutils provides /roughly/ but not exactly identical abstractions as m3core/libm3. This is not "bad", it just means m3core/libm3 aren't necessarily providing the best, sufficiently general abstractions. That happens. (It is also common for folks to reimplement stuff due to not understanding what is available, or there being a real or perceived inability to change what is available.) For this reason, that I fixed m3core/libm3 months ago, does not help sysutils. That is, sysutils uses waitpid, and the waitpid uses in m3core/libm3 are "buried" in higher abstractions. m3core/waitpid itself, I think, is not where this fix belongs. But maybe. I think that would change its semantics too much, even if its semantics are problematic. Maybe. I hadn't considered this. At least the change would only be in the user threads implementation. Everyone could perhaps just pass 0, and a wrapper would change to nohang and poll/sleep loop. pthreads would not -- it'd just pass on directly through. A lower level interface is needed for sysutils, and I added one. I added SchedulerPosix.DoesWaitPidYield. It just returns true for pthreads and false for userthreads. However, I believe sysutils cannot take on new m3core/libm3 dependencies, unless the minimum version for bootstrapping is raised, to a version that includes those changes. Therefore I don't use the very abstraction provided to solve the problem, but something similar. The code is now prepared to trivially switch to it, when the time comes that the minimum m3core/libm3 is raised. Similar story as the portable waitpid C wrapper, which I think fixes errors on I386_DARWIN and AMD64_DARWIN, though that I think only matters if a process returns non-zero, was ok for returning 0. There the code is well shared, but via automated copy and rename. For waitpid, I changed the "copied abstraction" to just be an interace containing a constant, instead of a function call. Perhaps a constant in m3core would be appropriate too. However..I wonder if the user/kernel threads option should be chosable at runtime or the command line or the default changable when building executables, all using the same runtime that could support either, therefore a function call. I know, it isn't chosable as such currently, it is a feature of the m3core as-built, but maybe a nice idea. - Jay> Date: Fri, 2 Jan 2009 11:27:24 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] variations of waitpid..?> > Quoting Tony Hosking :> > > If someone uses waitpid they get what they paid for.> It is so long ago that we wrote those sysutils routines...> They have only ever be used in simple command line utilities (like cm3)> without much concurrency, I think. If there is potential for deadlocks> and bad performance, we should at least document that in the interfaces.> > I am not up-to-date wrt. the M3 system interfaces and threads> implementation: is there a way for a thread to wait for the exit code> of another process without blocking other threads? If so, I'll adapt> the sysutils code... If not, can we introduce such an interface in> m3core/libm3?> > Olaf> > > On 1 Jan 2009, at 06:24, Jay wrote:> >> >>> >> You mean, this function is easy to misuse?> >>> People who declare their own <*EXTERNAL*>> >> Like waitpid exposed from m3core?> >>> >> waitpid is already easy to misuse, on a userthread system, leading > >> to possible (though I think rare) deadlock.> >> It is easy to misuse on pthreads, lead "just" to bad performance, > >> and in fact I believe cm3 is doing this, via sysutils.> >> This at least guides you between two patterns of use, and fix the > >> perf of cm3/sysutils.> >>> >> On a userthread system, waitpid(pid, flags = 0) waits for the child > >> process, with all parent threads suspended.> >> Generally I doubt the child depends on parent threads progressing, > >> but, yeah, that could deadlock, like if a parent thread is waiting > >> to a file or stdin of the child, or reading a child's stdout.> >>> >> The various uses do waitpid(pid, flags = nohang) and then sleep and > >> try again.> >>> >> pthreads just uses waitpid(pid, flags = 0) and all threads keep running> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jan 2 19:36:33 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 2 Jan 2009 18:36:33 +0000 Subject: [M3devel] FW: variations of waitpid..? In-Reply-To: <20090102113257.me6vseyaskggssoc@mail.elegosoft.com> References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> <20090102113257.me6vseyaskggssoc@mail.elegosoft.com> Message-ID: The pthreads code appears to leak for every thread created, as a result of trying to set stack size.I'll just fix it, once confirmed. Setting stack size is basically impossible all around.Both by the user and by "the OS". By the user: If the user calls into any dynamically linked code he didn't write, he doesn'tknow what is needed, without a lot of testing, and it can change in time. If the user so much as compiles with different flags or a different compileror targeting a different platform, stack use will change. By the OS: Same thing -- the OS doesn't know how much stack any user will need. Personally I generally practise and recommend minimizing stack usageand using heap instead. However there are large tradeoffs inperf and medium tradeoffs in debuggability (debuggers do a betterjob of immediately showing the contents of character arrays, insteadof pointers, which they don't follow automatically, at least cdb/ntsd/windbg,not sure about the various gdb/dbx/visualstudio). A terrible pattern imho, is stuff like char FilePath[some large maximum like 200 or 1000]; They use up the stack fast, are usually wasteful over-allocations, and sometimes arbitrary capacity-limiting under-allocations. For paths in particular, Win32 advertises two maximums, one of which is wrong, the other of which is suspicous -- 260 and 32K. 32K isn't clearly correct due to the availability of relative opens. Even if 32K is considered correct, it is way too much to allocate "just in case". Better to determine the actual needed size and allocate that. (I think current Cygwin code does just this though -- blow up a bunch of buffers to 32K.) Imho. Oh, and the common Unix advertisement of 1024 is also perhaps wrong.You know, what happens if I am using SMB to NT, or to another system with a different max?Do paths beyond 1024 get truncated, or unavailable, or overflow buffers?They can certainly exist.I'll have to try it out sometime. In general on disk structures are all "relative" and have no limits for full paths,only usually for individual path elements. The stack is generally of relatively small capacity, and when it is exhausted,that is more difficult to detect and recover from, than heap or addressspaceexhaustion. True, even heap and addresspace can run out, by either being "only" 32bits, orvia fragmentation, and are difficult to recover from.I personally don't defend against fragmentation, and it worries me some.It's maybe not a concern in Modula-3 due to compaction, however compactionseems also bad in that it requires larger contiguous memory.Fragmentation is good. Fragmentation is bad.. - Jay> Date: Fri, 2 Jan 2009 11:32:57 +0100> From: wagner@> To: m3devel@> Subject: Re: [M3devel] FW: variations of waitpid..?> > Quoting Jay:> > > (Personally I have seen precious little code that cares about stack > > size, just seems to somehow get along, combined with the fact that > > the current Modula-3 pthread code very likely leaks on some > > platforms attempting to deal with stack size, makes me inclined to > > just rip out the code..but yeah..just fix the leak...)> > Please don't do that (remove the ability to set stack sizes). I know> that for most of the programs I wrote years ago we had to adapt stack> sizes for threads carefully. That was with user threads though.> > Olaf -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jan 2 19:44:48 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 2 Jan 2009 18:44:48 +0000 Subject: [M3devel] dynamic chose between user/kernel threads? Message-ID: Should the user/kernel thread chose be available: On the command line to a Modula-3 executable (or even an executable where main is in another language, but which static or dynamic Modula-3 libs are used)? Via a quake directive when building programs? You know, imagine you have a bunch of Modula-3 programs and some but not all use a very large number of threads and benefit from userthreads. Currently the chose is locked into m3core when it is built. I understand (and anyone who likes the idea should understand) this is not easy to achieve. Well, at the very least, it is a tedious transform of the code, not anything hard to understand, just not a small physical change. The choice also has to be communicated very early in "startup/initialization", since e.g. the garbage collector creates a thread for itself during "startup/initialization" -- letting Main's body call Scheduler.SetThreadImplementation(enum [UserThreads, KernelThreads]) would not likely work, and not be provided. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jan 2 20:15:48 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 2 Jan 2009 19:15:48 +0000 Subject: [M3devel] variations of waitpid..? In-Reply-To: <20090102112724.5sr7fnp000cokcco@mail.elegosoft.com> References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> <20090102112724.5sr7fnp000cokcco@mail.elegosoft.com> Message-ID: I didn't read that well -- the deadlock risk in sysutils is not there. The bad perf is probably. To be clear (esp. for folks that might not already know about this, I didn't know about until fairly recently), there are two options: waitpid(pid, flags = 0) move along or while (waitpid(pid, flags = nohang) != 0) sleep(some value) The second is what sysutils was doing, and works, doesn't deadlock, is deoptimized. m3core/libm3 did this for a long time as well. When I complained about perf, it was pointed out to me. The first has deadlock potential with userthreads, but is ok and faster with kernel threads. waitpid(flags = nohang = don't actually wait, just get the exit code, if there is one) is a way to quickly poll if a process has ended, and if so, get its exit code. In Win32 there are two seperate functions GetExitCodeProcess and WaitForSingleObject or WaitForMultipleObjects ("waiting" is generalized across files, processes, sockets, files, threads, semaphores, mutexes, events and more..but not critical sections..only kernel objects). These have a bug too. One particular exit code is reserved to mean "the process is still running", but that is easily avoided by using Wait first. I have seen code get confused by this though. Wait also accepts a timeout, 32bit unsigned milliseconds, including 0 and infinity, so also can be used to poll. Win32 also defines the exit code to be 32bits, whereas Posix only allows for 8 bits which can be an interop problem. Perl on Win32 truncates exit codes to 8 bits, very bad. Unhandled exceptions end up as "large" exit codes. Anyway... The problem with the polling approach, at least part of the problem, is that if the child process isn't done when waitpid is first called, but finishes before sleep(whatever value) ends, we will still sleep for the full "whatever value". You only really want to sleep until the child process is done, and no longer. Making just the first sleep shorter might be a good idea. You know, to handle processes that are short-lived, but not "zero" lived. ("zero" being the amount of time it takes for the code to proceed from fork/exec to waitpid, surely much smaller than a small sleep() but longer than no sleep). Calling just waitpid(flags = 0) could deadlock if, for example, a parent thread is writing to a child's stdin, and the child won't finish until the parent has written all that it needs to. The parent and child process, er, other threads in the parent process, need to be allowed to run concurrently, for the sake of at least some reasonable scenarios. With kernelthreads, the implementation of waitpid knows about threads and will itself, in a sense, do the poll/sleep, but not exactly that -- it won't sleep beyond the child process finishing. Hopefully this makes sense and lets more folks understand the problem. What you can do, of course, is like: if kernelthreads waitpid(flags = 0) else while (waitpid(flags = nohang) != 0) sleep and that is basically what the code looks like now. The part "if kernelthreads" I propose be "if SchedulerPosix.DoesWaitPidYield()" though a really direct "if Thread or Scheduler.KernelThreads" might be reasonable. Up to folks then to decide what that implies.. - Jay> Date: Fri, 2 Jan 2009 11:27:24 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] variations of waitpid..?> > Quoting Tony Hosking :> > > If someone uses waitpid they get what they paid for.> It is so long ago that we wrote those sysutils routines...> They have only ever be used in simple command line utilities (like cm3)> without much concurrency, I think. If there is potential for deadlocks> and bad performance, we should at least document that in the interfaces.> > I am not up-to-date wrt. the M3 system interfaces and threads> implementation: is there a way for a thread to wait for the exit code> of another process without blocking other threads? If so, I'll adapt> the sysutils code... If not, can we introduce such an interface in> m3core/libm3?> > Olaf> > > On 1 Jan 2009, at 06:24, Jay wrote:> >> >>> >> You mean, this function is easy to misuse?> >>> People who declare their own <*EXTERNAL*>> >> Like waitpid exposed from m3core?> >>> >> waitpid is already easy to misuse, on a userthread system, leading > >> to possible (though I think rare) deadlock.> >> It is easy to misuse on pthreads, lead "just" to bad performance, > >> and in fact I believe cm3 is doing this, via sysutils.> >> This at least guides you between two patterns of use, and fix the > >> perf of cm3/sysutils.> >>> >> On a userthread system, waitpid(pid, flags = 0) waits for the child > >> process, with all parent threads suspended.> >> Generally I doubt the child depends on parent threads progressing, > >> but, yeah, that could deadlock, like if a parent thread is waiting > >> to a file or stdin of the child, or reading a child's stdout.> >>> >> The various uses do waitpid(pid, flags = nohang) and then sleep and > >> try again.> >>> >> pthreads just uses waitpid(pid, flags = 0) and all threads keep running> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Fri Jan 2 21:22:45 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 2 Jan 2009 20:22:45 +0000 (GMT) Subject: [M3devel] Modula-3 auto keyword upcase In-Reply-To: <495D8FB9.6030800@bellsouth.net> Message-ID: <562083.11611.qm@web28610.mail.ukl.yahoo.com> Hi, I know there are two good options, but yo may want to try first and see what adjust better for your purposes: The m3clipse projects which currently has developed a parser that builds the AST tree and gives you highlighting capabilities of Eclipse Editors (also auto completes) You may want to try download the source and build as a Java Plugin Project, http://sourceforge.net/cvs/?group_id=183896 if doesn't work or have doubts on how to do it just write the m3clipse project list or me. The author told me that: "The simplest way is to start Eclipse (3.3), choose File->import and load the workset file" that is m3clipse.psf file The other possibility but is still more in development is the Cooledit Text Editor Modula-3 syntax work made by Pino Zollo (he agrees to put the files on elego cvs tree ): http://freshmeat.net/projects/cooledit/ You can put the two files which are attached (Syntax and modula3.syntax)? and you will get some completion features (I couldn't see if that works still as the author told me it does, but highlighting works),? and offers easy macro construction on the Editor and easy interaction with python scripts. I managed to compile the cooledit itself and then put the 2 files on the path ~/.cedit/? (or in the Unix installation path /usr/local/share/cooledit/syntax ) but I needed to add the following two lines in the Syntax file (no modula3.syntax) : file ..\*\\.(m3|i3|ig|mg)$ Modula3\sProgram include modula3.syntax Cooledit? should work in Win32 platforms as well. Also he commented me the mc program could use this two files as well. Hope this helps --- El jue, 1/1/09, Martin Bishop wrote: De: Martin Bishop Asunto: [M3devel] Modula-3 auto keyword upcase Para: m3devel at elegosoft.com Fecha: jueves, 1 enero, 2009 10:53 I use the Modula-3 elisp code for Emacs to edit Modula-3 source, but it's somewhat annoying having to hit TAB to complete keywords (otherwise I have to hold shift to type them out). I have used an Oberon mode for Emacs before, that would auto upcase the keywords. If you typed 'module' and then pressed space, it would become 'MODULE', etc. I tried to modify the code from the Oberon mode and add it to the Modula-3 mode, but I had no luck. Does anyone know of any Modula-3 elisp code that does this? Or is there another editor that is capable of this? I have NEdit and jEdit, both have Modula-3 highlighting support, but neither help in actually editing Modula-3 code. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Syntax Type: application/octet-stream Size: 4510 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: modula3.syntax Type: application/octet-stream Size: 5846 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: m3clipse.psf Type: application/octet-stream Size: 329 bytes Desc: not available URL: From rcoleburn at scires.com Fri Jan 2 22:18:40 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 02 Jan 2009 16:18:40 -0500 Subject: [M3devel] FW: variations of waitpid..? In-Reply-To: References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> Message-ID: <495E3E42.1E75.00D7.1@scires.com> Jay: Your comment about stack size rang a bell with me. I have had trouble in the past running out of stack space, most notably on HP-UX. Same program built on Windows usually did not suffer the same fate. I seem to recall the most stack space trouble was when a thread did anything with Trestle/FormsVBT etc. So, I added a command line switch to my program that let's you specify a multiplier for the stack size. During initialization, my programs read the command line switches and take appropriate action to increase the thread stack sizes before any threads are created. If you don't specify a stack size multiplier on the command line, I think I wound up using seven (7) as the default. Here is a code excerpt: IF stackMult > 1 THEN WITH default = Thread.GetDefaultStackSize(), desired = default * stackMult, increase = desired - default DO PutText("Increasing default stack size by a factor of " & Fmt.Int(stackMult) & " (" & Fmt.Int(default) & " >>> " & Fmt.Int(desired) & ").\n"); Thread.IncDefaultStackSize(increase); END; (* with *) WITH default = Thread.GetDefaultStackSize() DO PutText("Thread stacks are now " & Fmt.Int(default) & " bytes.\n"); END; (* with *) END; (* if *) Regards, Randy >>> Jay 12/31/2008 8:59 PM >>> [truncated just slightly..and probably will be again given more rambling..] ps: the internal use in m3core could be easily removed, just by compiling one branch of the if or the other. I just wanted them in the same file to keep similar code closer together. So it comes down that m3core does expose Uwaitpid.waitpid and Uexec.waitpid, and as long as they are...or as long as user threads exist..imho there is some obligation of m3core to expose perhaps surprising characteristics of its thread library. You might say the entire interface is already and has always been fully exposed in Thread.i3, but I don't believe it. User threads and kernel threads have too divergent too visible artifacts, that I don't think are previously exposed in the public interface. I claim it is somewhat "surprising", or at least important to know the detail of, whether or not waitpid yields to other threads. You know, I mean..let's say I am some really clever waitpid user and I really must use it. And I am using Modula-3 threads. And my child process is reading the output of Modula-3 threads. Aren't I kind of stuck? Isn't there /some/ obligation of m3core to help just a teeny tiny bit? Or, would you argue, I am obligated, if I am using Modula-3, to use the higher level interfaces, that already know about this? Well, ok, m3core did already know about, I fixed it only a few months ago, but then even the likes of sysutils is stuck? Another example, that may or may not be well exposed, is willingness/ability to set thread stack size. Mika mentions creation thousands of threads. 32bit kernel threads are going to be more limited here. Whereas 32bit user threads might be willing to create much smaller stacks, and 64 bit anything has essentially infinite address space for infinite stacks (but still beware working set, physical memory is not infinite). (Personally I have seen precious little code that cares about stack size, just seems to somehow get along, combined with the fact that the current Modula-3 pthread code very likely leaks on some platforms attempting to deal with stack size, makes me inclined to just rip out the code..but yeah..just fix the leak...) - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: mika at async.caltech.edu; m3devel at elegosoft.com Subject: RE: [M3devel] variations of waitpid..? Date: Thu, 1 Jan 2009 01:49:28 +0000 > If someone uses waitpid they get what they paid for. But someone is us -- m3core/libm3 (I think just m3core), sysutils, and then cm3 uses them. I guess there is a point that this "grand new interface" SchedulerPosix.DoesWaitPidYield has precious few users. (It isn't grand. It takes no parameters and just returns a boolean, hardcoded, depending on thread library.) m3core now (today) uses it internally -- no need for a public interface. Sysutils can't use it until the baseline m3core is newer, so arguably, not a user. Instead (today) sysutils uses m3core's m3makefiles to decide the value. Heck, waitpid is therefore only used internally by m3core, and sysutils. If sysutils could be (partly) merged into m3core, then m3core's waitpid need not be public. - Jay > CC: mika > From: hosking > To: jay > Subject: Re: [M3devel] variations of waitpid..? > Date: Thu, 1 Jan 2009 12:29:24 +1100 > > If someone uses waitpid they get what they paid for. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Jan 2 22:28:04 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 02 Jan 2009 16:28:04 -0500 Subject: [M3devel] Modula-3 auto keyword upcase In-Reply-To: <495D8FB9.6030800@bellsouth.net> References: <495D8FB9.6030800@bellsouth.net> Message-ID: <495E4076.1E75.00D7.1@scires.com> Martin: I use CRiSP. http://www.crisp.com/ If you want to try it, I can provide you with my Modula-3 keyword and template files. Regards, Randy >>> Martin Bishop 1/1/2009 10:53 PM >>> I use the Modula-3 elisp code for Emacs to edit Modula-3 source, but it's somewhat annoying having to hit TAB to complete keywords (otherwise I have to hold shift to type them out). I have used an Oberon mode for Emacs before, that would auto upcase the keywords. If you typed 'module' and then pressed space, it would become 'MODULE', etc. I tried to modify the code from the Oberon mode and add it to the Modula-3 mode, but I had no luck. Does anyone know of any Modula-3 elisp code that does this? Or is there another editor that is capable of this? I have NEdit and jEdit, both have Modula-3 highlighting support, but neither help in actually editing Modula-3 code. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Jan 2 22:41:37 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 02 Jan 2009 16:41:37 -0500 Subject: [M3devel] meaning of unsafe? In-Reply-To: References: Message-ID: <495E43A3.1E75.00D7.1@scires.com> Jay: Modula-3 has a very precise definition of what it means to have a safe or an UNSAFE module. See pages 59-61 (section 2.7 Unsafe Operations) of the "Green Book" (Systems Programming with Modula-3 edited by Greg Nelson). Bottom line is that if you don't use any features of the language that are deemed UNSAFE, your program can't cause unchecked runtime errors. Regards, Randy >>> Jay 1/2/2009 2:02 AM >>> Recent quote, that I haven't further investigated, made me realize some of my ignorance. I know that "unsafe" includes: taking address of local explicit free dealing with any untraced ref? Not sure. Questions are: is unsafe well statically enforced? and/or is safe well statically enforced? That is, should I remove unsafe "everywhere", as long as it compiles ok, it must be safe, and better, so leave it that way? And if it fails, put it back? Or do I need to think about it myself? I think for modules it might be brainless as stated -- put it in only where the compiler makes, and nowhere extra, since extra is a loss not a bonus. But for interfaces.. I think, again, ideal to remove it where you can, but that the compiler can't enforce it? At least where there is "external"? Maybe I should just reread that quote, and thing about it. Safe can code call unsafe code, but should not be able to do so with parameters that, indirectly, make the safe code unsafe. For example, I cannot safe call "free" in unsafe code on behalf of safe code, unless I am darn sure the data isn't referenced -- unless I am the garbage collector. Any pointer give to unsafe code by safe code must not be stored "long term" -- ie: in the heap or globals, because it could be a stack pointer. Unless, well, duh..ok, any VAR parameter or UNTRACED REF passed to unsafe code, what I just said, but traced refs can be held onto -- they are by definition not stack pointers. I guess, you know..programming C code that interacts with Modula-3 code..you realize the incompleteness of the C type system. Modula-3 has, let's say, var, traced ref, and untraced ref. C just has pointers. The compiler doesn't know any better, the programmer has to. If you imagine a Modula-3 to C header compiler..which I would like..you know, it outputs C headers that map FROM Modula-3 interfaces (instead of the usual hand translations in either direction), it would likely lose a lot of information and only be for special purpose use, unless, unlikely, not likely valuable, this problem was solved. Which..oh, this is interesting..I can see, to solve this, you'd need an "API" for storing pointers perhaps. Something perhaps to make sure the pointer is allowed to be stored like such. Not sure. But I suspect this "API" is related to the "checks" that the Modula-3 compiler generates...I really need to understand those... Generally this is easy, because generally things are "synchronous" -- generally the C code doesn't hold on to its parameters beyond the lifetime of itself -- doesn't store it in the heap or globally for other threads to use, and generally the Modula-3 code isn't busy freeing the parameters on another thread, in fact VAR parameters cannot be freed, they are on the stack, and traced refs can only be freed..if the garbage collector can't find any references to them..and then untraced refs require "discipline" both in the Modula-3 code and the C code, but again generally, saved by "synchronicity" -- C code doesn't hold on to them, Modula-3 code doesn't free them on another thread. Those scenarios are certainly possible, just not all that common, and as soon as you "escape" to safe Modula-3 code, not a possibility..no untraced refs.. About right? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jan 3 00:05:24 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 2 Jan 2009 23:05:24 +0000 Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer? Message-ID: I'd like to avoid using "long" and "ulong" anywhere. On Unix, they are always pointer sized. On Windows, they are always 32 bits. This divergence of meaning I think it renders it useless. I believe for pointer-sized integers, the right types are any of: unsigned: size_t, Word.T signed: INTEGER, ssize_t, ptrdiff_t For 32bit integers: int32_t and uint32_t, perhaps int. There is arguably some ambiguity if you consider 16bit platforms. Now, I noticed we have: INTERFACE Cstddef; size_t = Ctypes.unsigned_long; ssize_t = Ctypes.long; ptrdiff_t = Ctypes.long; I would like to change this, either to: 32bits: size_t = Ctypes.unsigned_int; ssize_t = Ctypes.int; ptrdiff_t = Ctypes.int; 64bits: size_t = Ctypes.unsigned_long_long; ssize_t = Ctypes.long_long; ptrdiff_t = Ctypes.long_long; or portable: size_t = Word.T; ssize_t = INTEGER; ptrdiff_t = INTEGER; but, my question then is, why isn't the portable version already in use? Especially for the signed types. I mean, you know, we have: 32bits/BasicCtypes: INTERFACE BasicCtypes; IMPORT Word, Long; TYPE (* the four signed integer types *) signed_char = [-16_7f-1 .. 16_7f]; short_int = [-16_7fff-1 .. 16_7fff]; int = [-16_7fffffff-1 .. 16_7fffffff]; long_int = [-16_7fffffff-1 .. 16_7fffffff]; question is, why aren't int and long_int INTEGER? 64bits/BasicCtypes: long_int = [-16_7fffffffffffffff -1 .. 16_7fffffffffffffff ]; long_long = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL]; why not INTEGER? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Jan 3 01:12:27 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 03 Jan 2009 01:12:27 +0100 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: References: Message-ID: <20090103011227.vgpfs347400088sg@mail.elegosoft.com> An option to cm3 or a quake directive to use in the m3makefiles would suffice in my opinion (and be a great improvement). Olaf Quoting Jay : > > Should the user/kernel thread chose be available: > > > On the command line to a Modula-3 executable (or even an executable > where main is in another language, but which static or dynamic > Modula-3 libs are used)? > > > Via a quake directive when building programs? > > > You know, imagine you have a bunch of Modula-3 programs and some but > not all use a very large number of threads and benefit from > userthreads. > > > Currently the chose is locked into m3core when it is built. > > > I understand (and anyone who likes the idea should understand) this > is not easy to achieve. > Well, at the very least, it is a tedious transform of the code, not > anything hard to understand, just not a small physical change. The > choice also has to be communicated very early in > "startup/initialization", since e.g. the garbage collector creates a > thread for itself during "startup/initialization" -- letting Main's > body call Scheduler.SetThreadImplementation(enum [UserThreads, > KernelThreads]) would not likely work, and not be provided. > > > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sat Jan 3 01:24:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 3 Jan 2009 11:24:34 +1100 Subject: [M3devel] FW: variations of waitpid..? In-Reply-To: References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> <20090102113257.me6vseyaskggssoc@mail.elegosoft.com> Message-ID: What OS is this leak on? I don't think it is anything in the Modula-3 wrappers to pthreads, but please confirm. On 3 Jan 2009, at 05:36, Jay wrote: > The pthreads code appears to leak for every thread created, as a > result of trying to set stack size. > I'll just fix it, once confirmed. > > Setting stack size is basically impossible all around. > Both by the user and by "the OS". > > By the user: > > If the user calls into any dynamically linked code he didn't write, > he doesn't > know what is needed, without a lot of testing, and it can change in > time. > > If the user so much as compiles with different flags or a different > compiler > or targeting a different platform, stack use will change. > > By the OS: > > Same thing -- the OS doesn't know how much stack any user will need. > > > Personally I generally practise and recommend minimizing stack usage > and using heap instead. However there are large tradeoffs in > perf and medium tradeoffs in debuggability (debuggers do a better > job of immediately showing the contents of character arrays, instead > of pointers, which they don't follow automatically, at least cdb/ > ntsd/windbg, > not sure about the various gdb/dbx/visualstudio). > > > A terrible pattern imho, is stuff like > char FilePath[some large maximum like 200 or 1000]; > > They use up the stack fast, are usually wasteful over-allocations, > and sometimes > arbitrary capacity-limiting under-allocations. For paths in > particular, > Win32 advertises two maximums, one of which is wrong, the other of > which is > suspicous -- 260 and 32K. 32K isn't clearly correct due to the > availability of > relative opens. > Even if 32K is considered correct, it is way too much to allocate > "just in case". > Better to determine the actual needed size and allocate that. > (I think current Cygwin code does just this though -- blow up a > bunch of buffers to 32K.) > Imho. > > Oh, and the common Unix advertisement of 1024 is also perhaps wrong. > You know, what happens if I am using SMB to NT, or to another system > with a different max? > Do paths beyond 1024 get truncated, or unavailable, or overflow > buffers? > They can certainly exist. > I'll have to try it out sometime. > > In general on disk structures are all "relative" and have no limits > for full paths, > only usually for individual path elements. > > The stack is generally of relatively small capacity, and when it is > exhausted, > that is more difficult to detect and recover from, than heap or > addressspace > exhaustion. > > True, even heap and addresspace can run out, by either being "only" > 32bits, or > via fragmentation, and are difficult to recover from. > I personally don't defend against fragmentation, and it worries me > some. > It's maybe not a concern in Modula-3 due to compaction, however > compaction > seems also bad in that it requires larger contiguous memory. > Fragmentation is good. Fragmentation is bad.. > > - Jay > > > > > > Date: Fri, 2 Jan 2009 11:32:57 +0100 > > From: wagner@ > > To: m3devel@ > > Subject: Re: [M3devel] FW: variations of waitpid..? > > > > Quoting Jay: > > > > > (Personally I have seen precious little code that cares about > stack > > > size, just seems to somehow get along, combined with the fact that > > > the current Modula-3 pthread code very likely leaks on some > > > platforms attempting to deal with stack size, makes me inclined to > > > just rip out the code..but yeah..just fix the leak...) > > > > Please don't do that (remove the ability to set stack sizes). I know > > that for most of the programs I wrote years ago we had to adapt > stack > > sizes for threads carefully. That was with user threads though. > > > > Olaf > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jan 3 05:44:01 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 3 Jan 2009 04:44:01 +0000 Subject: [M3devel] FW: variations of waitpid..? In-Reply-To: <495E3E42.1E75.00D7.1@scires.com> References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> <495E3E42.1E75.00D7.1@scires.com> Message-ID: Perhaps, tangentially, we should strive to reduce stack usage in Trestle? Not as an alternative, granted. - Jay Date: Fri, 2 Jan 2009 16:18:40 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] FW: variations of waitpid..? Jay: Your comment about stack size rang a bell with me. I have had trouble in the past running out of stack space, most notably on HP-UX. Same program built on Windows usually did not suffer the same fate. I seem to recall the most stack space trouble was when a thread did anything with Trestle/FormsVBT etc. So, I added a command line switch to my program that let's you specify a multiplier for the stack size. During initialization, my programs read the command line switches and take appropriate action to increase the thread stack sizes before any threads are created. If you don't specify a stack size multiplier on the command line, I think I wound up using seven (7) as the default. Here is a code excerpt: IF stackMult > 1 THEN WITH default = Thread.GetDefaultStackSize(), desired = default * stackMult, increase = desired - default DO PutText("Increasing default stack size by a factor of " & Fmt.Int(stackMult) & " (" & Fmt.Int(default) & " >>> " & Fmt.Int(desired) & ").\n"); Thread.IncDefaultStackSize(increase); END; (* with *) WITH default = Thread.GetDefaultStackSize() DO PutText("Thread stacks are now " & Fmt.Int(default) & " bytes.\n"); END; (* with *) END; (* if *) Regards, Randy >>> Jay 12/31/2008 8:59 PM >>>[truncated just slightly..and probably will be again given more rambling..] ps: the internal use in m3core could be easily removed, just by compiling one branch of the if or the other.I just wanted them in the same file to keep similar code closer together. So it comes down that m3core does expose Uwaitpid.waitpid and Uexec.waitpid, and as long as they are...or as long as user threads exist..imho there is some obligation of m3core to expose perhaps surprising characteristics of its thread library. You might say the entire interface is already and has always been fully exposed in Thread.i3, but I don't believe it. User threads and kernel threads have too divergent too visible artifacts, that I don't think are previously exposed in the public interface. I claim it is somewhat "surprising", or at least important to know the detail of, whether or not waitpid yields to other threads. You know, I mean..let's say I am some really clever waitpid user and I really must use it. And I am using Modula-3 threads. And my child process is reading the output of Modula-3 threads. Aren't I kind of stuck? Isn't there /some/ obligation of m3core to help just a teeny tiny bit? Or, would you argue, I am obligated, if I am using Modula-3, to use the higher level interfaces, that already know about this? Well, ok, m3core did already know about, I fixed it only a few months ago, but then even the likes of sysutils is stuck? Another example, that may or may not be well exposed, is willingness/ability to set thread stack size. Mika mentions creation thousands of threads. 32bit kernel threads are going to be more limited here. Whereas 32bit user threads might be willing to create much smaller stacks, and 64 bit anything has essentially infinite address space for infinite stacks (but still beware working set, physical memory is not infinite). (Personally I have seen precious little code that cares about stack size, just seems to somehow get along, combined with the fact that the current Modula-3 pthread code very likely leaks on some platforms attempting to deal with stack size, makes me inclined to just rip out the code..but yeah..just fix the leak...) - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: mika at async.caltech.edu; m3devel at elegosoft.comSubject: RE: [M3devel] variations of waitpid..?Date: Thu, 1 Jan 2009 01:49:28 +0000 > If someone uses waitpid they get what they paid for. But someone is us -- m3core/libm3 (I think just m3core), sysutils, and then cm3 uses them. I guess there is a point that this "grand new interface" SchedulerPosix.DoesWaitPidYield has precious few users. (It isn't grand. It takes no parameters and just returns a boolean, hardcoded, depending on thread library.) m3core now (today) uses it internally -- no need for a public interface.Sysutils can't use it until the baseline m3core is newer, so arguably, not a user. Instead (today) sysutils uses m3core's m3makefiles to decide the value. Heck, waitpid is therefore only used internally by m3core, and sysutils.If sysutils could be (partly) merged into m3core, then m3core's waitpid need not be public. - Jay> CC: mika> From: hosking> To: jay> Subject: Re: [M3devel] variations of waitpid..?> Date: Thu, 1 Jan 2009 12:29:24 +1100> > If someone uses waitpid they get what they paid for. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eiserlohpp at yahoo.com Sat Jan 3 07:52:26 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Fri, 2 Jan 2009 22:52:26 -0800 (PST) Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer? Message-ID: <443283.92057.qm@web56804.mail.re3.yahoo.com> Jay, Please don't make size_t 128 bits in size. In "C" a long is specified by the language spec to be an integral type big enough to hold a pointer. Longs in "C" may be bigger than a pointer, but they must be at least that size. NOTE: an int (integer) does not have that guarantee. In fact, I once programed on a platform (Amiga) that had two different compilers one used 16-bits and other 32 for their integers. You can imagine the difficulties. Windows machines, as you have been using, give an address space of 32 bits to user space. This is regardless of how much RAM it may actually have. I would expect that on a Win64 platform, pointers are 64 bits, and "long" is also 64 bits. On my AMD64_LINUX box, pointers are 64 bits, and therefore a long is 64, and a long long is 128. The system type size_t is 64 bits. If you attempt to map Cstddef.size_t to 128 bits it will not only break the syscall interfaces to the kernel, but also be a waste of space. >From that standpoint the type definitions size_t = Ctypes.unsigned_long; ..., etc. are correct. Please don't define size_t = Ctypes.unsigned_long_long; The "C" include files /usr/includes/bits/types.h /usr/includes/bits/typesizes.h play preprocessor games to ensure that the ssize_t are defined to use the "natural" word size. Other types get defined to fixed sizes (ie, _int32 must always be 32 bits) otherwise external interfaces (file formats, inodes, ..., etc) would be corrupted. For that reason explicitly sized types need to be defined. Actually, GNU/Modula-2 recently defined explictly sized types. Peter Eiserloh. Date: Fri, 2 Jan 2009 23:05:24 +0000 From: Jay Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer? To: m3devel , Tony Message-ID: Content-Type: text/plain; charset="iso-8859-1" I'd like to avoid using "long" and "ulong" anywhere. On Unix, they are always pointer sized. On Windows, they are always 32 bits. This divergence of meaning I think it renders it useless. I believe for pointer-sized integers, the right types are any of: unsigned: size_t, Word.T signed: INTEGER, ssize_t, ptrdiff_t For 32bit integers: int32_t and uint32_t, perhaps int. There is arguably some ambiguity if you consider 16bit platforms. Now, I noticed we have: INTERFACE Cstddef; size_t = Ctypes.unsigned_long; ssize_t = Ctypes.long; ptrdiff_t = Ctypes.long; I would like to change this, either to: 32bits: size_t = Ctypes.unsigned_int; ssize_t = Ctypes.int; ptrdiff_t = Ctypes.int; 64bits: size_t = Ctypes.unsigned_long_long; ssize_t = Ctypes.long_long; ptrdiff_t = Ctypes.long_long; or portable: size_t = Word.T; ssize_t = INTEGER; ptrdiff_t = INTEGER; but, my question then is, why isn't the portable version already in use? Especially for the signed types. I mean, you know, we have: 32bits/BasicCtypes: INTERFACE BasicCtypes; IMPORT Word, Long; TYPE (* the four signed integer types *) signed_char = [-16_7f-1 .. 16_7f]; short_int = [-16_7fff-1 .. 16_7fff]; int = [-16_7fffffff-1 .. 16_7fffffff]; long_int = [-16_7fffffff-1 .. 16_7fffffff]; question is, why aren't int and long_int INTEGER? 64bits/BasicCtypes: long_int = [-16_7fffffffffffffff -1 .. 16_7fffffffffffffff ]; long_long = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL]; why not INTEGER? +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Sat Jan 3 08:45:26 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 3 Jan 2009 07:45:26 +0000 Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer? In-Reply-To: <443283.92057.qm@web56804.mail.re3.yahoo.com> References: <443283.92057.qm@web56804.mail.re3.yahoo.com> Message-ID: Peter, Huh? Of course not. "long long" is always exactly 64 bits, except on systems where it doesn't exist at all. There isn't really any 128 bit integer type in widespread use, aside from multi precision arithmetic libraries and such. long on Windows is always 32bits, as I said. The pointer sized types are: size_t, ptrdiff_t, ssize_t, INTEGER, and any pointer Surely sizeof(long) == sizeof(void*) was considered for Win64, but rejected due to the wider spread source incompatibility it would have caused. Yes, I know, every other 64 bit system took a different route -- Alpha, AIX, Solaris, IRIX, Darwin -- but they all probably had far less code to deal with. I have also programmed with a 16bit int, but nobody seems to care about portability to that these days/decades/centuries. If folks here want to imagine Modula-3 is portable to such a system, with 16 bit INTEGER, I am willing to entertain discussion and maybe even code as to the ramifications..maybe.. - Jay> Date: Fri, 2 Jan 2009 22:52:26 -0800> From: eiserlohpp@> To: m3devel@> Subject: Re: [M3devel] long vs. INTEGER? ranges vs. word/integer?> > Jay,> > Please don't make size_t 128 bits in size. In "C" a> long is specified by the language spec to be an integral > type big enough to hold a pointer. Longs in "C" may be> bigger than a pointer, but they must be at least that size. > > NOTE: an int (integer) does not have that guarantee.> > In fact, I once programed on a platform (Amiga) that had> two different compilers one used 16-bits and other 32 for> their integers. You can imagine the difficulties.> > Windows machines, as you have been using, give an address> space of 32 bits to user space. This is regardless of how> much RAM it may actually have. I would expect that on a> Win64 platform, pointers are 64 bits, and "long" is also > 64 bits.> > On my AMD64_LINUX box, pointers are 64 bits, and therefore> a long is 64, and a long long is 128. The system type> size_t is 64 bits. If you attempt to map Cstddef.size_t> to 128 bits it will not only break the syscall interfaces> to the kernel, but also be a waste of space.> > From that standpoint the type definitions> size_t = Ctypes.unsigned_long;> ..., etc.> > are correct.> > Please don't define > size_t = Ctypes.unsigned_long_long;> > > The "C" include files> /usr/includes/bits/types.h> /usr/includes/bits/typesizes.h> > play preprocessor games to ensure that the ssize_t are> defined to use the "natural" word size. > > Other types get defined to fixed sizes (ie, _int32 must> always be 32 bits) otherwise external interfaces (file> formats, inodes, ..., etc) would be corrupted. For that> reason explicitly sized types need to be defined.> > Actually, GNU/Modula-2 recently defined explictly sized> types.> > > Peter Eiserloh.> > > > Date: Fri, 2 Jan 2009 23:05:24 +0000> From: Jay > Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer?> To: m3devel , Tony > Message-ID: > Content-Type: text/plain; charset="iso-8859-1"> > > I'd like to avoid using "long" and "ulong" anywhere.> On Unix, they are always pointer sized.> On Windows, they are always 32 bits.> > This divergence of meaning I think it renders it useless.> > I believe for pointer-sized integers, the right types are any of:> unsigned: size_t, Word.T> signed: INTEGER, ssize_t, ptrdiff_t> For 32bit integers: int32_t and uint32_t, perhaps int.> > There is arguably some ambiguity if you consider 16bit platforms.> > Now, I noticed we have:> INTERFACE Cstddef;> > size_t = Ctypes.unsigned_long; ssize_t = Ctypes.long; ptrdiff_t = Ctypes.long;> > I would like to change this, either to:> > 32bits:> size_t = Ctypes.unsigned_int; ssize_t = Ctypes.int; ptrdiff_t = Ctypes.int;> > 64bits:> size_t = Ctypes.unsigned_long_long; ssize_t = Ctypes.long_long; ptrdiff_t = Ctypes.long_long;> > or portable:> size_t = Word.T; ssize_t = INTEGER; ptrdiff_t = INTEGER;> but, my question then is, why isn't the portable version already in use?> Especially for the signed types.> > I mean, you know, we have:> > 32bits/BasicCtypes:> > INTERFACE BasicCtypes;> IMPORT Word, Long;> TYPE (* the four signed integer types *) signed_char = [-16_7f-1 .. 16_7f]; short_int = [-16_7fff-1 .. 16_7fff]; int = [-16_7fffffff-1 .. 16_7fffffff]; long_int = [-16_7fffffff-1 .. 16_7fffffff];> question is, why aren't int and long_int INTEGER?> > 64bits/BasicCtypes:> > long_int = [-16_7fffffffffffffff -1 .. 16_7fffffffffffffff ]; long_long = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];> > why not INTEGER?> > > > +--------------------------------------------------------+> | Peter P. Eiserloh |> +--------------------------------------------------------+> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jan 3 09:04:37 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 3 Jan 2009 08:04:37 +0000 Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer? In-Reply-To: <443283.92057.qm@web56804.mail.re3.yahoo.com> References: <443283.92057.qm@web56804.mail.re3.yahoo.com> Message-ID: Oh I should have read more closely to correct more.. > In "C" a> long is specified by the language spec to be an integral > type big enough to hold a pointer. Longs in "C" may be> bigger than a pointer, but they must be at least that size. No. This is very false.There is (are) the standards, and there is the practical reality, and neither agree with your assertion. In "C89", ANSI C prior to C9x, the integral types are: char -- of wierd/uncertain signedness unsigned char signed char short (aka short int aka signed short ? aka signed short int) unsigned short (aka unsigned short int) int (aka signed int) unsigned (aka unsigned int) long (aka long int aka signed long int) unsigned long (aka unsigned long int) limits.h #defines CHAR_BIT, the number of bits in a char (or signed char or unsigned char) CHAR_BIT must be at least 8. Practically speaking it is always exactly 8, but..perhaps not on a Cray. sizeof(char) == 1, by definition if char is more than 8 bits, then CHAR_BIT must be adjusted, not sizeof(char) sizeof(short) >= 2 sizeof(int) >= sizeof(short) sizeof(long) >= sizeof(int) sizeof(long) >= 4 There are some types size_t and ptrdiff_t that I'm not sure what the standard says. Something like, size_t can hold the index for any array. However, the standard doesn't like speak of address spaces and their sizes, so just what is the maximum index for an array, I don't know. Practically speaking, size_t and ptrdiff_t are the exact same size as a pointer. Practially speaking, all pointers are of the same size. Though that isn't clear in the standard as I understand. Practically speaking, all pointers roundtrip through any pointer type, as well as size_t or ptrdiff_t. There is no relationship between long and pointers, in the standard. Practically speaking: CHAR_BIT == 8 sizeof(short) == 2 sizeof(int) == 4 sizeof(long) == 4 in all 32bit and 64bit (and 16bit) Windows programming environments sizeof(long) == sizeof(void*) in most non-Windows programming environments C9x introduces several new types and typedefs. As I understand, many of the typedefs are in stdint.h, and many are optional. long long I presume is speced as: sizeof(long long) >= sizeof(long) sizeof(long long) >= 8 Practically speaking, sizeof(long long) == 8. stdint.h goes nuts with the obvious options. It defines things like: fast_intN_t -- signed type that is "fast" and at least N bits in size fast_uintN_t -- unsigned ditto least_intN_t -- smallest integer that is at leasrt N bits in size least_uintN_t -- unsigned ditto intN_t -- signed integer exactly N bits in size uintN_t -- usigned ditto intptr_t -- signed integer exactly the size of a pointer uintptr_t -- unsigned ditto Not every type is mandatory though, and "fast" is vague. Then, they go even further, they have #defines for the printf and scanf strings for each type..I think. At least they have a bunch of #defines to abstract printf/scanf, not sure they have every single one. Boom goes the combinatorial explosion. So, personally, I think this is overkill. I think you should have just the exact sized types, plus the pointer-sized types. Throw out the "least" and "fast" types. Printf/scanf is thornier. It does seem a real problem, with no pretty solution. When I am just printing for debugging purposes, I often just hardcode %u or %lu and cast my data. I usually don't care if I lose the upper 32 bits, if they are even there, when I am just debugging. Microsoft long ago introduced %I64u and %I64d, but everyone else use something else, I guess %llu and %lld for long long, or maybe %Lu and %Ld. "long long" and %ll and "least"/"fast" are all nice and abstract, but again, I think it is all overkill in terms of abstraction. As you said, persistance formats are a large concern. Persistance formats frequently guide in-memory representations. Furthermore, I theorize that the abstractions aren't all that useful for in-memory data either. If you want your capacity to grow as address space grows, use size_t. Otherwise, pick a "reasonable" type. uint32_t is almost always reasonably efficent and offers adequate capacity. If you aren't sure, well go with uint64_t, it is still /fairly/ efficient on current 32 bit systems, offers nearly infinite capacity, and is perfectly efficient on 64bit systems..and 32bit should be trending downward..maybe. 64bit is still memory-inefficient, so if you have large structs/arrays and certainly are comfy with fewer bits, use small. So..the decision isn't always trivial, but I still suspect using exactly sized types is plenty adequate, and that worrying about the other types is too much. gcc internally uses pairs of longs to portably represent 64 bits. And they also have "wide" integers -- the hosts widest integral type. I forget what they use them for, but I'm sure they are compatible with a 32 bit "wide" -- gcc is after all portable to a C compiler without long long, but probably not to a compiler with 16 bit int (unless maybe they use long everywhere in that situation? I don't know.) - Jay From: jay.krell at cornell.eduTo: eiserlohpp at yahoo.com; m3devel at elegosoft.comSubject: RE: [M3devel] long vs. INTEGER? ranges vs. word/integer?Date: Sat, 3 Jan 2009 07:45:26 +0000 Peter, Huh? Of course not. "long long" is always exactly 64 bits, except on systems where it doesn't exist at all. There isn't really any 128 bit integer type in widespread use, aside from multi precision arithmetic libraries and such. long on Windows is always 32bits, as I said. The pointer sized types are: size_t, ptrdiff_t, ssize_t, INTEGER, and any pointer Surely sizeof(long) == sizeof(void*) was considered for Win64, but rejected due to the wider spread source incompatibility it would have caused. Yes, I know, every other 64 bit system took a different route -- Alpha, AIX, Solaris, IRIX, Darwin -- but they all probably had far less code to deal with. I have also programmed with a 16bit int, but nobody seems to care about portability to that these days/decades/centuries. If folks here want to imagine Modula-3 is portable to such a system, with 16 bit INTEGER, I am willing to entertain discussion and maybe even code as to the ramifications..maybe.. - Jay> Date: Fri, 2 Jan 2009 22:52:26 -0800> From: eiserlohpp@> To: m3devel@> Subject: Re: [M3devel] long vs. INTEGER? ranges vs. word/integer?> > Jay,> > Please don't make size_t 128 bits in size. In "C" a> long is specified by the language spec to be an integral > type big enough to hold a pointer. Longs in "C" may be> bigger than a pointer, but they must be at least that size. > > NOTE: an int (integer) does not have that guarantee.> > In fact, I once programed on a platform (Amiga) that had> two different compilers one used 16-bits and other 32 for> their integers. You can imagine the difficulties.> > Windows machines, as you have been using, give an address> space of 32 bits to user space. This is regardless of how> much RAM it may actually have. I would expect that on a> Win64 platform, pointers are 64 bits, and "long" is also > 64 bits.> > On my AMD64_LINUX box, pointers are 64 bits, and therefore> a long is 64, and a long long is 128. The system type> size_t is 64 bits. If you attempt to map Cstddef.size_t> to 128 bits it will not only break the syscall interfaces> to the kernel, but also be a waste of space.> > From that standpoint the type definitions> size_t = Ctypes.unsigned_long;> ..., etc.> > are correct.> > Please don't define > size_t = Ctypes.unsigned_long_long;> > > The "C" include files> /usr/includes/bits/types.h> /usr/includes/bits/typesizes.h> > play preprocessor games to ensure that the ssize_t are> defined to use the "natural" word size. > > Other types get defined to fixed sizes (ie, _int32 must> always be 32 bits) otherwise external interfaces (file> formats, inodes, ..., etc) would be corrupted. For that> reason explicitly sized types need to be defined.> > Actually, GNU/Modula-2 recently defined explictly sized> types.> > > Peter Eiserloh.> > > > Date: Fri, 2 Jan 2009 23:05:24 +0000> From: Jay > Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer?> To: m3devel , Tony > Message-ID: > Content-Type: text/plain; charset="iso-8859-1"> > > I'd like to avoid using "long" and "ulong" anywhere.> On Unix, they are always pointer sized.> On Windows, they are always 32 bits.> > This divergence of meaning I think it renders it useless.> > I believe for pointer-sized integers, the right types are any of:> unsigned: size_t, Word.T> signed: INTEGER, ssize_t, ptrdiff_t> For 32bit integers: int32_t and uint32_t, perhaps int.> > There is arguably some ambiguity if you consider 16bit platforms.> > Now, I noticed we have:> INTERFACE Cstddef;> > size_t = Ctypes.unsigned_long; ssize_t = Ctypes.long; ptrdiff_t = Ctypes.long;> > I would like to change this, either to:> > 32bits:> size_t = Ctypes.unsigned_int; ssize_t = Ctypes.int; ptrdiff_t = Ctypes.int;> > 64bits:> size_t = Ctypes.unsigned_long_long; ssize_t = Ctypes.long_long; ptrdiff_t = Ctypes.long_long;> > or portable:> size_t = Word.T; ssize_t = INTEGER; ptrdiff_t = INTEGER;> but, my question then is, why isn't the portable version already in use?> Especially for the signed types.> > I mean, you know, we have:> > 32bits/BasicCtypes:> > INTERFACE BasicCtypes;> IMPORT Word, Long;> TYPE (* the four signed integer types *) signed_char = [-16_7f-1 .. 16_7f]; short_int = [-16_7fff-1 .. 16_7fff]; int = [-16_7fffffff-1 .. 16_7fffffff]; long_int = [-16_7fffffff-1 .. 16_7fffffff];> question is, why aren't int and long_int INTEGER?> > 64bits/BasicCtypes:> > long_int = [-16_7fffffffffffffff -1 .. 16_7fffffffffffffff ]; long_long = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];> > why not INTEGER?> > > > +--------------------------------------------------------+> | Peter P. Eiserloh |> +--------------------------------------------------------+> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.illig at gmx.de Sat Jan 3 10:05:58 2009 From: roland.illig at gmx.de (Roland Illig) Date: Sat, 03 Jan 2009 10:05:58 +0100 Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer? In-Reply-To: <443283.92057.qm@web56804.mail.re3.yahoo.com> References: <443283.92057.qm@web56804.mail.re3.yahoo.com> Message-ID: <495F2A76.7010508@gmx.de> Peter Eiserloh schrieb: > Jay, > > In "C" a > long is specified by the language spec to be an integral > type big enough to hold a pointer. Longs in "C" may be > bigger than a pointer, but they must be at least that size. That's wrong. There is nothing in the C99 standard that guarantees that. The only guarantee is that long is at least as large as int. If your assumption was true, there wouldn't have been the need to add intptr_t and uintptr_t to the language. Even size_t doesn't have to be as large as a pointer. It's perfectly ok to have a computer with a 64-bit address space, in which every object may be only 4 GB large. Then you would have sizeof(void *) == 8, and sizeof(size_t) == 4. Or take the old MS-DOS: sizeof(void *) == 4, sizeof(size_t) == 2. Roland From jay.krell at cornell.edu Sat Jan 3 13:02:23 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 3 Jan 2009 12:02:23 +0000 Subject: [M3devel] FW: variations of waitpid..? In-Reply-To: <495E3E42.1E75.00D7.1@scires.com> References: Your message of "Wed, 31 Dec 2008 07:13:02 GMT." <200812310722.mBV7Mftp025967@camembert.async.caltech.edu> <495E3E42.1E75.00D7.1@scires.com> Message-ID: Eek, it looks like Modula-3's default stack size is quite small, 3000 bytes on user threads, 4k on pthreads. Hm. - Jay From: jay.krell at cornell.eduTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] FW: variations of waitpid..?Date: Sat, 3 Jan 2009 04:44:01 +0000 Perhaps, tangentially, we should strive to reduce stack usage in Trestle?Not as an alternative, granted. - Jay Date: Fri, 2 Jan 2009 16:18:40 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] FW: variations of waitpid..? Jay: Your comment about stack size rang a bell with me. I have had trouble in the past running out of stack space, most notably on HP-UX. Same program built on Windows usually did not suffer the same fate. I seem to recall the most stack space trouble was when a thread did anything with Trestle/FormsVBT etc. So, I added a command line switch to my program that let's you specify a multiplier for the stack size. During initialization, my programs read the command line switches and take appropriate action to increase the thread stack sizes before any threads are created. If you don't specify a stack size multiplier on the command line, I think I wound up using seven (7) as the default. Here is a code excerpt: IF stackMult > 1 THEN WITH default = Thread.GetDefaultStackSize(), desired = default * stackMult, increase = desired - default DO PutText("Increasing default stack size by a factor of " & Fmt.Int(stackMult) & " (" & Fmt.Int(default) & " >>> " & Fmt.Int(desired) & ").\n"); Thread.IncDefaultStackSize(increase); END; (* with *) WITH default = Thread.GetDefaultStackSize() DO PutText("Thread stacks are now " & Fmt.Int(default) & " bytes.\n"); END; (* with *) END; (* if *) Regards, Randy >>> Jay 12/31/2008 8:59 PM >>>[truncated just slightly..and probably will be again given more rambling..] ps: the internal use in m3core could be easily removed, just by compiling one branch of the if or the other.I just wanted them in the same file to keep similar code closer together. So it comes down that m3core does expose Uwaitpid.waitpid and Uexec.waitpid, and as long as they are...or as long as user threads exist..imho there is some obligation of m3core to expose perhaps surprising characteristics of its thread library. You might say the entire interface is already and has always been fully exposed in Thread.i3, but I don't believe it. User threads and kernel threads have too divergent too visible artifacts, that I don't think are previously exposed in the public interface. I claim it is somewhat "surprising", or at least important to know the detail of, whether or not waitpid yields to other threads. You know, I mean..let's say I am some really clever waitpid user and I really must use it. And I am using Modula-3 threads. And my child process is reading the output of Modula-3 threads. Aren't I kind of stuck? Isn't there /some/ obligation of m3core to help just a teeny tiny bit? Or, would you argue, I am obligated, if I am using Modula-3, to use the higher level interfaces, that already know about this? Well, ok, m3core did already know about, I fixed it only a few months ago, but then even the likes of sysutils is stuck? Another example, that may or may not be well exposed, is willingness/ability to set thread stack size. Mika mentions creation thousands of threads. 32bit kernel threads are going to be more limited here. Whereas 32bit user threads might be willing to create much smaller stacks, and 64 bit anything has essentially infinite address space for infinite stacks (but still beware working set, physical memory is not infinite). (Personally I have seen precious little code that cares about stack size, just seems to somehow get along, combined with the fact that the current Modula-3 pthread code very likely leaks on some platforms attempting to deal with stack size, makes me inclined to just rip out the code..but yeah..just fix the leak...) - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: mika at async.caltech.edu; m3devel at elegosoft.comSubject: RE: [M3devel] variations of waitpid..?Date: Thu, 1 Jan 2009 01:49:28 +0000 > If someone uses waitpid they get what they paid for. But someone is us -- m3core/libm3 (I think just m3core), sysutils, and then cm3 uses them. I guess there is a point that this "grand new interface" SchedulerPosix.DoesWaitPidYield has precious few users. (It isn't grand. It takes no parameters and just returns a boolean, hardcoded, depending on thread library.) m3core now (today) uses it internally -- no need for a public interface.Sysutils can't use it until the baseline m3core is newer, so arguably, not a user. Instead (today) sysutils uses m3core's m3makefiles to decide the value. Heck, waitpid is therefore only used internally by m3core, and sysutils.If sysutils could be (partly) merged into m3core, then m3core's waitpid need not be public. - Jay> CC: mika> From: hosking> To: jay> Subject: Re: [M3devel] variations of waitpid..?> Date: Thu, 1 Jan 2009 12:29:24 +1100> > If someone uses waitpid they get what they paid for. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jan 3 13:14:02 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 3 Jan 2009 12:14:02 +0000 Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer? In-Reply-To: References: <443283.92057.qm@web56804.mail.re3.yahoo.com> Message-ID: Sorry, big mistakes, below: NOT sizeof(short) >= 2 NOT sizeof(long) >= 4 but rather sizeof(short) * CHAR_BIT >= 16sizeof(long) * CHAR_BIT >= 32 A conforming implementation, as I understand, could have: #define CHAR_BIT 32 sizeof(char) = sizeof(short) = sizeof(int) = sizeof(long) = 1 Though /practically/ speaking, CHAR_BIT is always 8 and what I said is true. You know..what is it..the Matlab model? Where everything is a 64 bit double with >= 32 bit mantissa, therefore everything could be a double? - Jay From: jay.krell at cornell.eduTo: eiserlohpp at yahoo.com; m3devel at elegosoft.comDate: Sat, 3 Jan 2009 08:04:37 +0000Subject: Re: [M3devel] long vs. INTEGER? ranges vs. word/integer? Oh I should have read more closely to correct more.. > In "C" a> long is specified by the language spec to be an integral > type big enough to hold a pointer. Longs in "C" may be> bigger than a pointer, but they must be at least that size. No. This is very false.There is (are) the standards, and there is the practical reality,and neither agree with your assertion. In "C89", ANSI C prior to C9x, the integral types are: char -- of wierd/uncertain signedness unsigned char signed char short (aka short int aka signed short ? aka signed short int) unsigned short (aka unsigned short int) int (aka signed int) unsigned (aka unsigned int) long (aka long int aka signed long int) unsigned long (aka unsigned long int) limits.h #defines CHAR_BIT, the number of bits in a char (or signed char or unsigned char) CHAR_BIT must be at least 8.Practically speaking it is always exactly 8, but..perhaps not on a Cray. sizeof(char) == 1, by definition if char is more than 8 bits, then CHAR_BIT must be adjusted, not sizeof(char) sizeof(short) >= 2 sizeof(int) >= sizeof(short)sizeof(long) >= sizeof(int)sizeof(long) >= 4 There are some types size_t and ptrdiff_t that I'm not sure what the standard says.Something like, size_t can hold the index for any array.However, the standard doesn't like speak of address spaces and their sizes, so just what is the maximum index for an array, I don't know. Practically speaking, size_t and ptrdiff_t are the exact same size as a pointer.Practially speaking, all pointers are of the same size. Though that isn't clear in the standard as I understand.Practically speaking, all pointers roundtrip through any pointer type, as well as size_t or ptrdiff_t. There is no relationship between long and pointers, in the standard. Practically speaking:CHAR_BIT == 8sizeof(short) == 2sizeof(int) == 4sizeof(long) == 4 in all 32bit and 64bit (and 16bit) Windows programming environmentssizeof(long) == sizeof(void*) in most non-Windows programming environments C9x introduces several new types and typedefs.As I understand, many of the typedefs are in stdint.h, and many are optional. long long I presume is speced as:sizeof(long long) >= sizeof(long)sizeof(long long) >= 8 Practically speaking, sizeof(long long) == 8. stdint.h goes nuts with the obvious options.It defines things like: fast_intN_t -- signed type that is "fast" and at least N bits in size fast_uintN_t -- unsigned ditto least_intN_t -- smallest integer that is at leasrt N bits in size least_uintN_t -- unsigned ditto intN_t -- signed integer exactly N bits in size uintN_t -- usigned ditto intptr_t -- signed integer exactly the size of a pointer uintptr_t -- unsigned ditto Not every type is mandatory though, and "fast" is vague. Then, they go even further, they have #defines for the printf and scanf strings for each type..I think. At least they have a bunch of #defines to abstract printf/scanf, not sure they have every single one.Boom goes the combinatorial explosion. So, personally, I think this is overkill. I think you should have just the exact sized types, plus the pointer-sized types.Throw out the "least" and "fast" types. Printf/scanf is thornier.It does seem a real problem, with no pretty solution. When I am just printing for debugging purposes, I often just hardcode %u or %lu and cast my data. I usually don't care if I lose the upper 32 bits, if they are even there, when I am just debugging. Microsoft long ago introduced %I64u and %I64d, but everyone else use something else, I guess %llu and %lld for long long, or maybe %Lu and %Ld. "long long" and %ll and "least"/"fast" are all nice and abstract, but again, I think it is all overkill in terms of abstraction. As you said, persistance formats are a large concern.Persistance formats frequently guide in-memory representations.Furthermore, I theorize that the abstractions aren't all that useful for in-memory data either.If you want your capacity to grow as address space grows, use size_t.Otherwise, pick a "reasonable" type.uint32_t is almost always reasonably efficent and offers adequate capacity.If you aren't sure, well go with uint64_t, it is still /fairly/ efficient on current 32 bit systems, offers nearly infinite capacity, and is perfectly efficient on 64bit systems..and 32bit should be trending downward..maybe.64bit is still memory-inefficient, so if you have large structs/arrays and certainly are comfy with fewer bits, use small. So..the decision isn't always trivial, but I still suspect using exactly sized types is plenty adequate, and that worrying about the other types is too much. gcc internally uses pairs of longs to portably represent 64 bits.And they also have "wide" integers -- the hosts widest integral type.I forget what they use them for, but I'm sure they are compatible with a 32 bit "wide" -- gcc is after all portable to a C compiler without long long, but probably not to a compiler with 16 bit int (unless maybe they use long everywhere in that situation? I don't know.) - Jay From: jay.krell at cornell.eduTo: eiserlohpp at yahoo.com; m3devel at elegosoft.comSubject: RE: [M3devel] long vs. INTEGER? ranges vs. word/integer?Date: Sat, 3 Jan 2009 07:45:26 +0000 Peter, Huh? Of course not. "long long" is always exactly 64 bits, except on systems where it doesn't exist at all. There isn't really any 128 bit integer type in widespread use, aside from multi precision arithmetic libraries and such. long on Windows is always 32bits, as I said. The pointer sized types are: size_t, ptrdiff_t, ssize_t, INTEGER, and any pointer Surely sizeof(long) == sizeof(void*) was considered for Win64, but rejected due to the wider spread source incompatibility it would have caused. Yes, I know, every other 64 bit system took a different route -- Alpha, AIX, Solaris, IRIX, Darwin -- but they all probably had far less code to deal with. I have also programmed with a 16bit int, but nobody seems to care about portability to that these days/decades/centuries. If folks here want to imagine Modula-3 is portable to such a system, with 16 bit INTEGER, I am willing to entertain discussion and maybe even code as to the ramifications..maybe.. - Jay> Date: Fri, 2 Jan 2009 22:52:26 -0800> From: eiserlohpp@> To: m3devel@> Subject: Re: [M3devel] long vs. INTEGER? ranges vs. word/integer?> > Jay,> > Please don't make size_t 128 bits in size. In "C" a> long is specified by the language spec to be an integral > type big enough to hold a pointer. Longs in "C" may be> bigger than a pointer, but they must be at least that size. > > NOTE: an int (integer) does not have that guarantee.> > In fact, I once programed on a platform (Amiga) that had> two different compilers one used 16-bits and other 32 for> their integers. You can imagine the difficulties.> > Windows machines, as you have been using, give an address> space of 32 bits to user space. This is regardless of how> much RAM it may actually have. I would expect that on a> Win64 platform, pointers are 64 bits, and "long" is also > 64 bits.> > On my AMD64_LINUX box, pointers are 64 bits, and therefore> a long is 64, and a long long is 128. The system type> size_t is 64 bits. If you attempt to map Cstddef.size_t> to 128 bits it will not only break the syscall interfaces> to the kernel, but also be a waste of space.> > From that standpoint the type definitions> size_t = Ctypes.unsigned_long;> ..., etc.> > are correct.> > Please don't define > size_t = Ctypes.unsigned_long_long;> > > The "C" include files> /usr/includes/bits/types.h> /usr/includes/bits/typesizes.h> > play preprocessor games to ensure that the ssize_t are> defined to use the "natural" word size. > > Other types get defined to fixed sizes (ie, _int32 must> always be 32 bits) otherwise external interfaces (file> formats, inodes, ..., etc) would be corrupted. For that> reason explicitly sized types need to be defined.> > Actually, GNU/Modula-2 recently defined explictly sized> types.> > > Peter Eiserloh.> > > > Date: Fri, 2 Jan 2009 23:05:24 +0000> From: Jay > Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer?> To: m3devel , Tony > Message-ID: > Content-Type: text/plain; charset="iso-8859-1"> > > I'd like to avoid using "long" and "ulong" anywhere.> On Unix, they are always pointer sized.> On Windows, they are always 32 bits.> > This divergence of meaning I think it renders it useless.> > I believe for pointer-sized integers, the right types are any of:> unsigned: size_t, Word.T> signed: INTEGER, ssize_t, ptrdiff_t> For 32bit integers: int32_t and uint32_t, perhaps int.> > There is arguably some ambiguity if you consider 16bit platforms.> > Now, I noticed we have:> INTERFACE Cstddef;> > size_t = Ctypes.unsigned_long; ssize_t = Ctypes.long; ptrdiff_t = Ctypes.long;> > I would like to change this, either to:> > 32bits:> size_t = Ctypes.unsigned_int; ssize_t = Ctypes.int; ptrdiff_t = Ctypes.int;> > 64bits:> size_t = Ctypes.unsigned_long_long; ssize_t = Ctypes.long_long; ptrdiff_t = Ctypes.long_long;> > or portable:> size_t = Word.T; ssize_t = INTEGER; ptrdiff_t = INTEGER;> but, my question then is, why isn't the portable version already in use?> Especially for the signed types.> > I mean, you know, we have:> > 32bits/BasicCtypes:> > INTERFACE BasicCtypes;> IMPORT Word, Long;> TYPE (* the four signed integer types *) signed_char = [-16_7f-1 .. 16_7f]; short_int = [-16_7fff-1 .. 16_7fff]; int = [-16_7fffffff-1 .. 16_7fffffff]; long_int = [-16_7fffffff-1 .. 16_7fffffff];> question is, why aren't int and long_int INTEGER?> > 64bits/BasicCtypes:> > long_int = [-16_7fffffffffffffff -1 .. 16_7fffffffffffffff ]; long_long = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];> > why not INTEGER?> > > > +--------------------------------------------------------+> | Peter P. Eiserloh |> +--------------------------------------------------------+> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stsp at elego.de Sat Jan 3 13:41:52 2009 From: stsp at elego.de (Stefan Sperling) Date: Sat, 3 Jan 2009 13:41:52 +0100 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> <20090101114139.GC10003@jack.stsp.name> Message-ID: <20090103124152.GA25002@jack.stsp.name> On Thu, Jan 01, 2009 at 07:45:44PM +0000, Jay wrote: > > What do you mean by "bootstrap binaries"? > > There are a variety of ways to get a usable system. > > > There is > [1]http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-I386_OP > ENBSD-1.tar.gz > extract it (tar zxf ...) > cd into it (cd ...) > add -lm and -lpthread to the link line > make > mkdir -p /usr/local/cm3/bin > mv cm3 /usr/local/cm3/bin > export PATH=$PATH:/usr/local/cm3/bin > export CM3_ROOT=/usr/src/cm3 or whatever > export CVSROOT=:ext:stefan at m3.elegosoft.com:/usr/cvs > cvs -z3 checkout cm3 > cd /usr/src/scripts/python > ./do-cm3-front.py buildship Thanks. I've tried that, and the ./do-cm3-front.py buildship step fails with: cd . && cd gcc && gmake CC="gcc" CFLAGS="-g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a _m3.log cd . && cd gcc && gmake CC="gcc" CFLAGS="-g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a _m3.log TARGET_CPU_DEFAULT="" \ HEADERS="auto-host.h ansidecl.h" DEFINES="" \ /bin/sh ../../gcc/gcc/mkconfig.sh bconfig.h gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc/gcc -I../../gcc/gcc/build -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I/home/stsp/src/cm3/m3-sys/m3cc/I386_OPENBSD/./gmp -I/home/stsp/src/cm3/m3-sys/m3cc/gcc/gmp -I/home/stsp/src/cm3/m3-sys/m3cc/I386_OPENBSD/./mpfr -I/home/stsp/src/cm3/m3-sys/m3cc/gcc/mpfr -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/local/include -o build/errors.o ../../gcc/gcc/errors.c build/genmodes > tmp-modes.c /bin/sh: build/genmodes: not found gmake: *** [s-modes] Error 127 "/home/stsp/src/cm3/m3-sys/m3cc/src/m3makefile", line 378: quake runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2 --procedure-- -line- -file--- cp_if -- postcp 378 /home/stsp/src/cm3/m3-sys/m3cc/src/m3makefile include_dir 444 /home/stsp/src/cm3/m3-sys/m3cc/src/m3makefile 8 /home/stsp/src/cm3/m3-sys/m3cc/I386_OPENBSD/m3make.args Fatal Error: package build failed *** execution of [, ] failed *** Stefan From eiserlohpp at yahoo.com Sat Jan 3 13:50:53 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sat, 3 Jan 2009 04:50:53 -0800 (PST) Subject: [M3devel] long vs. INTEGER? ranges vs. word/integer? Message-ID: <83996.89296.qm@web56807.mail.re3.yahoo.com> Hi Jay, Sorry, for not speaking up earlier, I have been lurking for the last ten years. The last thing that got me really interested was the discussion about NEW() returning either NULL, or a checked runtime exception on failure to allocate memory. Okay, I wrote a test program. You are right sizeof(long) == sizeof(long long) equals 8 bytes (64 bits). So, I looked it up in the "C A Reference Manual" (CARM) 4th edition. It has been over ten years since I last looked at it. I have been corrected and educated. Sorry about discussing a foreign language, but ... To quote from page 120 (5.3): The size of a pointer is implementation dependent and in some cases varies depending on the type of the object pointed to. For example, data pointers may be shorter or longer than function pointers (section 6.1.5). There is not necessarily any relationship between pointer sizes and the size of any integer type, although it is common to assume that type _long_ is at least as large as any pointer type. Page 123 (5.3.3): 1 - Pointers are often not the same size as _int_, and sometimes not the same size as _long_. Sometimes their size is a compiler option. 2 - Character and void * pointers can be larger that other kinds of pointers, or may use a representation that is incompatible with other kinds of pointers. 3 - Function pointers and data pointer may have significantly different representations, including different sizes. Page 292 (11.1) Type _size_t_ is the unsigned integral type of the result of the sizeof operator -- probably _unsigned long_; pre-ISO implementations often use the (unsigned) type _int_ for this purpose. To paraphrase both Nelson (SPWM3) and Harbison (Modula-3). When doing a LOOPHOLE(e,T), ensure that BITSIZE(e) equals BITSIZE(T). In addition, -(x,y : ADDRESS) : INTEGER The SPWM3 does not have a LONGINT, but we now do as of a few months ago. The above operation on addresses implies that the difference between ANY two addresses can be represented in an INTEGER, with the further implication that an ADDRESS can be represented in an INTEGER (i.e., a size_t is an INTEGER). [Roland] So MS-DOS used a size_t of 2, but void* was 4, wow, that sure sounds broken. 64 KB is the maximum size of an object in memory. Thank god, we don't use MS-DOS anymore. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Sat Jan 3 16:21:23 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 3 Jan 2009 15:21:23 +0000 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: <20090103124152.GA25002@jack.stsp.name> References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> <20090101114139.GC10003@jack.stsp.name> <20090103124152.GA25002@jack.stsp.name> Message-ID: Please try export OMIT_GCC=yes. - Jay> Date: Sat, 3 Jan 2009 13:41:52 +0100> From: stsp at elego.de> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] I386_OPENBSD uploaded-archives> > On Thu, Jan 01, 2009 at 07:45:44PM +0000, Jay wrote:> > > > What do you mean by "bootstrap binaries"?> > > > There are a variety of ways to get a usable system.> > > > > > There is> > [1]http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-I386_OP> > ENBSD-1.tar.gz> > extract it (tar zxf ...)> > cd into it (cd ...)> > add -lm and -lpthread to the link line> > make> > mkdir -p /usr/local/cm3/bin> > mv cm3 /usr/local/cm3/bin> > export PATH=$PATH:/usr/local/cm3/bin> > export CM3_ROOT=/usr/src/cm3 or whatever> > export CVSROOT=:ext:stefan at m3.elegosoft.com:/usr/cvs> > cvs -z3 checkout cm3> > cd /usr/src/scripts/python> > ./do-cm3-front.py buildship> > Thanks. I've tried that, and the ./do-cm3-front.py buildship step fails with:> > cd . && cd gcc && gmake CC="gcc" CFLAGS="-g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a _m3.log> cd . && cd gcc && gmake CC="gcc" CFLAGS="-g" AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: s-modes insn-config.h m3cg | tee -a _m3.log> TARGET_CPU_DEFAULT="" \> HEADERS="auto-host.h ansidecl.h" DEFINES="" \> /bin/sh ../../gcc/gcc/mkconfig.sh bconfig.h> gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc/gcc -I../../gcc/gcc/build -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I/home/stsp/src/cm3/m3-sys/m3cc/I386_OPENBSD/./gmp -I/home/stsp/src/cm3/m3-sys/m3cc/gcc/gmp -I/home/stsp/src/cm3/m3-sys/m3cc/I386_OPENBSD/./mpfr -I/home/stsp/src/cm3/m3-sys/m3cc/gcc/mpfr -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/local/include -o build/errors.o ../../gcc/gcc/errors.c> build/genmodes > tmp-modes.c> /bin/sh: build/genmodes: not found> gmake: *** [s-modes] Error 127> "/home/stsp/src/cm3/m3-sys/m3cc/src/m3makefile", line 378: quake runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2> > --procedure-- -line- -file---> cp_if -- > postcp 378 /home/stsp/src/cm3/m3-sys/m3cc/src/m3makefile> include_dir 444 /home/stsp/src/cm3/m3-sys/m3cc/src/m3makefile> 8 /home/stsp/src/cm3/m3-sys/m3cc/I386_OPENBSD/m3make.args> > Fatal Error: package build failed> *** execution of [, ] failed ***> > > Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From stsp at elego.de Sat Jan 3 16:27:24 2009 From: stsp at elego.de (Stefan Sperling) Date: Sat, 3 Jan 2009 16:27:24 +0100 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> <20090101114139.GC10003@jack.stsp.name> <20090103124152.GA25002@jack.stsp.name> Message-ID: <20090103152724.GC25002@jack.stsp.name> On Sat, Jan 03, 2009 at 03:21:23PM +0000, Jay wrote: > > Please try export OMIT_GCC=yes. No dice: new exporters -> recompiling SchedulerPosix.i3 /bin/sh: m3cg: not found m3_backend => 127 m3cc (aka cm3cg) failed compiling: SchedulerPosix.ic new exporters -> recompiling ThreadF.i3 /bin/sh: m3cg: not found m3_backend => 127 m3cc (aka cm3cg) failed compiling: ThreadF.ic new exporters -> recompiling ThreadInternal.i3 /bin/sh: m3cg: not found m3_backend => 127 m3cc (aka cm3cg) failed compiling: ThreadInternal.ic new exporters -> recompiling Time.i3 /bin/sh: m3cg: not found m3_backend => 127 m3cc (aka cm3cg) failed compiling: Time.ic new exporters -> recompiling Tick.i3 /bin/sh: m3cg: not found m3_backend => 127 m3cc (aka cm3cg) failed compiling: Tick.ic new exporters -> recompiling Date.i3 /bin/sh: m3cg: not found m3_backend => 127 m3cc (aka cm3cg) failed compiling: Date.ic new exporters -> recompiling Text.i3 /bin/sh: m3cg: not found m3_backend => 127 m3cc (aka cm3cg) failed compiling: Text.ic compilation failed => not building library "libm3core.a" Fatal Error: package build failed *** execution of [, ] failed *** Stefan From jay.krell at cornell.edu Sat Jan 3 16:30:38 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 3 Jan 2009 15:30:38 +0000 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: <20090103152724.GC25002@jack.stsp.name> References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> <20090101114139.GC10003@jack.stsp.name> <20090103124152.GA25002@jack.stsp.name> <20090103152724.GC25002@jack.stsp.name> Message-ID: Both the "min" and "std" archives should have cm3cg. Wherever you extracted the archive, did you put its bin directory in $PATH? ie: are you running cm3 by full path or via $PATH? - Jay> Date: Sat, 3 Jan 2009 16:27:24 +0100> From: stsp at elego.de> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] I386_OPENBSD uploaded-archives> > On Sat, Jan 03, 2009 at 03:21:23PM +0000, Jay wrote:> > > > Please try export OMIT_GCC=yes.> > No dice:> > new exporters -> recompiling SchedulerPosix.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: SchedulerPosix.ic> new exporters -> recompiling ThreadF.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: ThreadF.ic> new exporters -> recompiling ThreadInternal.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: ThreadInternal.ic> new exporters -> recompiling Time.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Time.ic> new exporters -> recompiling Tick.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Tick.ic> new exporters -> recompiling Date.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Date.ic> new exporters -> recompiling Text.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Text.ic> compilation failed => not building library "libm3core.a"> Fatal Error: package build failed> *** execution of [, ] failed ***> > > Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jan 3 16:59:42 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 3 Jan 2009 15:59:42 +0000 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: <20090103152724.GC25002@jack.stsp.name> References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> <20090101114139.GC10003@jack.stsp.name> <20090103124152.GA25002@jack.stsp.name> <20090103152724.GC25002@jack.stsp.name> Message-ID: > Both the "min" and "std" archives should have cm3cg. Confirmed at least for min: C:\net\modula3>lzma -d cm3-min-I386_OPENBSD-d5.7.0.tar.lzma C:\net\modula3>tar tf cm3-min-I386_OPENBSD-d5.7.0.tar | morecm3-min-I386_OPENBSD-d5.7.0cm3-min-I386_OPENBSD-d5.7.0/bincm3-min-I386_OPENBSD-d5.7.0/bin/cm3cm3-min-I386_OPENBSD-d5.7.0/bin/cm3cgcm3-min-I386_OPENBSD-d5.7.0/bin/mklibcm3-min-I386_OPENBSD-d5.7.0/bin/I386_OPENBSDcm3-min-I386_OPENBSD-d5.7.0/bin/Unix.commoncm3-min-I386_OPENBSD-d5.7.0/bin/cm3cfg.common I guess all that probing I put in (and that I use all the time, doing cross builds) MIGHT confuse things. You can look in cm3cfg.common for a big nested loop and remove it all and let it fall back to just running "cm3cg", whatever is first in $PATH. - Jay From: jay.krell at cornell.eduTo: stsp at elego.deCC: m3devel at elegosoft.comSubject: RE: [M3devel] I386_OPENBSD uploaded-archivesDate: Sat, 3 Jan 2009 15:30:38 +0000 Both the "min" and "std" archives should have cm3cg.Wherever you extracted the archive, did you put its bin directory in $PATH?ie: are you running cm3 by full path or via $PATH? - Jay> Date: Sat, 3 Jan 2009 16:27:24 +0100> From: stsp at elego.de> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] I386_OPENBSD uploaded-archives> > On Sat, Jan 03, 2009 at 03:21:23PM +0000, Jay wrote:> > > > Please try export OMIT_GCC=yes.> > No dice:> > new exporters -> recompiling SchedulerPosix.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: SchedulerPosix.ic> new exporters -> recompiling ThreadF.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: ThreadF.ic> new exporters -> recompiling ThreadInternal.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: ThreadInternal.ic> new exporters -> recompiling Time.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Time.ic> new exporters -> recompiling Tick.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Tick.ic> new exporters -> recompiling Date.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Date.ic> new exporters -> recompiling Text.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Text.ic> compilation failed => not building library "libm3core.a"> Fatal Error: package build failed> *** execution of [, ] failed ***> > > Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jan 3 17:07:05 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 3 Jan 2009 16:07:05 +0000 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: <20090103152724.GC25002@jack.stsp.name> References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> <20090101114139.GC10003@jack.stsp.name> <20090103124152.GA25002@jack.stsp.name> <20090103152724.GC25002@jack.stsp.name> Message-ID: I think I see the problem. In the file cm3cfg.common, find: % write("using m3cg in PATH (if there is one)\n") m3back = "@m3cg " & m3back_flags and change it to: % write("using cm3cg in PATH (if there is one)\n") m3back = "@cm3cg " & m3back_flags OR copy/rename/link the file to match, either way. You should be able to take the file I just commited to CVS, seconds ago. It works for me because the probing always finds my unshipped backends. This doesn't explain why you can't build in the m3cc directory. - Jay From: jay.krell at cornell.eduTo: stsp at elego.deCC: m3devel at elegosoft.comSubject: RE: [M3devel] I386_OPENBSD uploaded-archivesDate: Sat, 3 Jan 2009 15:59:42 +0000 > Both the "min" and "std" archives should have cm3cg.Confirmed at least for min: C:\net\modula3>lzma -d cm3-min-I386_OPENBSD-d5.7.0.tar.lzmaC:\net\modula3>tar tf cm3-min-I386_OPENBSD-d5.7.0.tar | morecm3-min-I386_OPENBSD-d5.7.0cm3-min-I386_OPENBSD-d5.7.0/bincm3-min-I386_OPENBSD-d5.7.0/bin/cm3cm3-min-I386_OPENBSD-d5.7.0/bin/cm3cgcm3-min-I386_OPENBSD-d5.7.0/bin/mklibcm3-min-I386_OPENBSD-d5.7.0/bin/I386_OPENBSDcm3-min-I386_OPENBSD-d5.7.0/bin/Unix.commoncm3-min-I386_OPENBSD-d5.7.0/bin/cm3cfg.commonI guess all that probing I put in (and that I use all the time, doing cross builds) MIGHT confuse things.You can look in cm3cfg.common for a big nested loop and remove it all and let it fall back to just running "cm3cg", whatever is first in $PATH. - Jay From: jay.krell at cornell.eduTo: stsp at elego.deCC: m3devel at elegosoft.comSubject: RE: [M3devel] I386_OPENBSD uploaded-archivesDate: Sat, 3 Jan 2009 15:30:38 +0000 Both the "min" and "std" archives should have cm3cg.Wherever you extracted the archive, did you put its bin directory in $PATH?ie: are you running cm3 by full path or via $PATH? - Jay> Date: Sat, 3 Jan 2009 16:27:24 +0100> From: stsp at elego.de> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] I386_OPENBSD uploaded-archives> > On Sat, Jan 03, 2009 at 03:21:23PM +0000, Jay wrote:> > > > Please try export OMIT_GCC=yes.> > No dice:> > new exporters -> recompiling SchedulerPosix.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: SchedulerPosix.ic> new exporters -> recompiling ThreadF.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: ThreadF.ic> new exporters -> recompiling ThreadInternal.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: ThreadInternal.ic> new exporters -> recompiling Time.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Time.ic> new exporters -> recompiling Tick.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Tick.ic> new exporters -> recompiling Date.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Date.ic> new exporters -> recompiling Text.i3> /bin/sh: m3cg: not found> m3_backend => 127> m3cc (aka cm3cg) failed compiling: Text.ic> compilation failed => not building library "libm3core.a"> Fatal Error: package build failed> *** execution of [, ] failed ***> > > Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From stsp at elego.de Sat Jan 3 17:20:50 2009 From: stsp at elego.de (Stefan Sperling) Date: Sat, 3 Jan 2009 17:20:50 +0100 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> <20090101114139.GC10003@jack.stsp.name> <20090103124152.GA25002@jack.stsp.name> <20090103152724.GC25002@jack.stsp.name> Message-ID: <20090103162050.GD25002@jack.stsp.name> On Sat, Jan 03, 2009 at 03:30:38PM +0000, Jay wrote: > > Both the "min" and "std" archives should have cm3cg. I'm not using either of those. Your initial description of ho to build this mentioned those as alternatives, but it didn't sound like they were required. Maybe I didn't read carefully enough? I am using just these steps, as you outlined: fetch http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-I386_OPENBSD-1.tar.gz extract it (tar zxf ...) cd into it (cd ...) add -lm and -lpthread to the link line make mkdir -p /usr/local/cm3/bin mv cm3 /usr/local/cm3/bin export PATH=$PATH:/usr/local/cm3/bin export CM3_ROOT=/usr/src/cm3 or whatever export CVSROOT=:ext:stefan at m3.elegosoft.com:/usr/cvs cvs -z3 checkout cm3 cd /usr/src/scripts/python ./do-cm3-front.py buildship The very last step results in the error. The other steps succeed. > Wherever you extracted the archive, Which archive? > did you put its bin directory in $PATH? Following the steps above, I now have this: $ find /usr/local/cm3 /usr/local/cm3 /usr/local/cm3/bin /usr/local/cm3/bin/cm3 $ /usr/local/cm3/bin/cm3 -help Fatal Error: unable to locate configuration file, "cm3.cfg" $ Prior to running do-cm3-front.py, I run: export PATH=$PATH:/usr/local/cm3/bin > ie: are you running cm3 by full path or via $PATH? No idea. Whatever ./doc-m3-front.py buildship does, I guess. Stefan From jay.krell at cornell.edu Sat Jan 3 18:21:21 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 3 Jan 2009 17:21:21 +0000 Subject: [M3devel] I386_OPENBSD uploaded-archives In-Reply-To: <20090103162050.GD25002@jack.stsp.name> References: <20081229203344.692E1B04044@birch.elegosoft.com> <20081230021646.GA8558@jack.stsp.name> <20090101114139.GC10003@jack.stsp.name> <20090103124152.GA25002@jack.stsp.name> <20090103152724.GC25002@jack.stsp.name> <20090103162050.GD25002@jack.stsp.name> Message-ID: Ok, well, you have to change something somewhere. If you can't build in m3cc, which we have no idea why not, and which I have you skip with export OMIT_GCC=yes, then at least get the cm3cg from the "min" or "std" archives and put it in the directory you will put cm3. The failure buildng m3cg/cm3cg/m3cc I cannot tell at all from below. Personally the problem I ran into twice is not having "gmake", but it looks like you got well past that. It doesn't fail as early or clearly as you might hope, but again, I think you got past that. - Jay> Date: Sat, 3 Jan 2009 17:20:50 +0100> From: stsp at elego.de> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] I386_OPENBSD uploaded-archives> > On Sat, Jan 03, 2009 at 03:30:38PM +0000, Jay wrote:> > > > Both the "min" and "std" archives should have cm3cg.> > I'm not using either of those. Your initial description of ho> to build this mentioned those as alternatives, but it didn't> sound like they were required. Maybe I didn't read carefully> enough?> > I am using just these steps, as you outlined:> > fetch http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-I386_OPENBSD-1.tar.gz> extract it (tar zxf ...) > cd into it (cd ...) > add -lm and -lpthread to the link line > make > mkdir -p /usr/local/cm3/bin > mv cm3 /usr/local/cm3/bin > export PATH=$PATH:/usr/local/cm3/bin > export CM3_ROOT=/usr/src/cm3 or whatever > export CVSROOT=:ext:stefan at m3.elegosoft.com:/usr/cvs > cvs -z3 checkout cm3 > cd /usr/src/scripts/python > ./do-cm3-front.py buildship > > The very last step results in the error.> The other steps succeed.> > > Wherever you extracted the archive,> > Which archive?> > > did you put its bin directory in $PATH?> > Following the steps above, I now have this:> > $ find /usr/local/cm3> /usr/local/cm3> /usr/local/cm3/bin> /usr/local/cm3/bin/cm3> $ /usr/local/cm3/bin/cm3 -help> > Fatal Error: unable to locate configuration file, "cm3.cfg"> > $> > Prior to running do-cm3-front.py, I run:> export PATH=$PATH:/usr/local/cm3/bin> > > ie: are you running cm3 by full path or via $PATH?> > No idea. Whatever ./doc-m3-front.py buildship does, I guess.> > Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 4 23:57:09 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 4 Jan 2009 22:57:09 +0000 Subject: [M3devel] determing current processor as string In-Reply-To: <20090102202255.9177E10D5D00@birch.elegosoft.com> References: <20090102202255.9177E10D5D00@birch.elegosoft.com> Message-ID: Thoughts here? Does the processor need to be "friendly" and "precise" including stuff not knowable at compile time (386 vs. 486 vs. 586, etc.), or would just "PowerPC" or "PPC" suffice? This question affects the Posix code. The Posix code tries to fetch some data at runtime from uname, and if that fails it falls back to built in data. Besides that the data is used in an unlikely error path, we bother carrying the data for all systems, which afaik is completely unnecessary. Once I confirm, I'll have Quake generate just what is needed. Similarly, I think cm3 should have -print-host or somesuch. Then the platform probing in sysinfo.sh could probably all go away. (Except for my idea of /cm3/bin/cm3.sh that calls /cm3/bin/target/cm3.) There is more here than just the processor. So some runtime code would remain, even if the processor became hard coded at compile time. You know, there are a few models here: Use data at runtime asis. e.g. GetEnv("PROCESSOR_ARCHITECTURE") and be done. Does that work on CE? Build-in the data at compile time and be done. This requires possibly a revisit for every port, but simple. It goes obsolete in time, but not quietly, it'd be an error in the Quake code when a new platform is introduced. Or, if the string is just then automatically ports, no revisit. This doesn't have the concern "does it work on CE?" or of Posix vs. Win32 portability. Use data at runtime to pick among compile time data. This is the current approach and it goes obsolete quietly in time. As well, these functions are never even used that I can see. Remove them? Or assume they might be used outside the cm3 tree? (That's quite a "line" in decision makiing. It's so much nicer to assume/know you have all the relevant code visible and therefore can make any change, provided you fix the client code, vs. having to assume there is "anything" out there.) - Jay> Date: Fri, 2 Jan 2009 21:22:55 +0000> To: m3commit@> From: jkrell@> Subject: [M3commit] CVS Update: cm3> > 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> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 5 02:12:56 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jan 2009 12:12:56 +1100 Subject: [M3devel] determing current processor as string In-Reply-To: References: <20090102202255.9177E10D5D00@birch.elegosoft.com> Message-ID: <3C9A9351-C543-44CE-A76F-B2490C423641@cs.purdue.edu> As far as I am concerned I think PPC or PowerPC is sufficient, since the gcc-based backend figures out what it needs. Why would the front- ends need to know? Perhaps I am missing your point... On 5 Jan 2009, at 09:57, Jay wrote: > Thoughts here? > > > Does the processor need to be "friendly" and "precise" including stuff > not knowable at compile time (386 vs. 486 vs. 586, etc.), > or would just "PowerPC" or "PPC" suffice? > > > This question affects the Posix code. > > > The Posix code tries to fetch some data at runtime from uname, and > if that fails > it falls back to built in data. Besides that the data is used in an > unlikely > error path, we bother carrying the data for all systems, which afaik > is completely unnecessary. Once I confirm, I'll have Quake generate > just what is needed. > > > Similarly, I think cm3 should have -print-host or somesuch. > Then the platform probing in sysinfo.sh could probably all go away. > (Except for my idea of /cm3/bin/cm3.sh that calls /cm3/bin/target/ > cm3.) > > > There is more here than just the processor. > So some runtime code would remain, even if the processor > became hard coded at compile time. > > You know, there are a few models here: > > Use data at runtime asis. > e.g. GetEnv("PROCESSOR_ARCHITECTURE") and be done. > Does that work on CE? > > Build-in the data at compile time and be done. > This requires possibly a revisit for every port, but simple. > It goes obsolete in time, but not quietly, it'd be an error in > the Quake code > when a new platform is introduced. > Or, if the string is just then automatically ports, no > revisit. > This doesn't have the concern "does it work on CE?" or > of Posix vs. Win32 portability. > > Use data at runtime to pick among compile time data. > This is the current approach and it goes obsolete quietly in > time. > > > As well, these functions are never even used that I can see. > Remove them? > Or assume they might be used outside the cm3 tree? > > (That's quite a "line" in decision makiing. It's so much nicer > to assume/know you have all the relevant code visible and therefore > can make any change, provided you fix the client code, vs. having to > assume there is "anything" out there.) > > - Jay > > > > Date: Fri, 2 Jan 2009 21:22:55 +0000 > > To: m3commit@ > > From: jkrell@ > > Subject: [M3commit] CVS Update: cm3 > > > > 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 5 02:23:45 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 5 Jan 2009 01:23:45 +0000 Subject: [M3devel] determing current processor as string In-Reply-To: <3C9A9351-C543-44CE-A76F-B2490C423641@cs.purdue.edu> References: <20090102202255.9177E10D5D00@birch.elegosoft.com> <3C9A9351-C543-44CE-A76F-B2490C423641@cs.purdue.edu> Message-ID: Sorry, I had a tangent there. The main question was regiarding a library feature, not a compiler issue. libm3/src/os/POSIX/OSConfigPosix.m3 libm3/src/os/POSIX/OSConfig.i3 libm3/src/os/WIN32/OSConfigWin32.m3 libm3/src/os/WIN32/OSConfig.i3 The bulk of this code is never used in the cm3 tree anyway. The tangent was regarding "cm3 -dump-host" or such, though it's more complicated maybe. Some hosts are "biarch" or "multiarch". - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] determing current processor as stringDate: Mon, 5 Jan 2009 12:12:56 +1100 As far as I am concerned I think PPC or PowerPC is sufficient, since the gcc-based backend figures out what it needs. Why would the front-ends need to know? Perhaps I am missing your point... On 5 Jan 2009, at 09:57, Jay wrote: Thoughts here? Does the processor need to be "friendly" and "precise" including stuffnot knowable at compile time (386 vs. 486 vs. 586, etc.),or would just "PowerPC" or "PPC" suffice? This question affects the Posix code. The Posix code tries to fetch some data at runtime from uname, and if that failsit falls back to built in data. Besides that the data is used in an unlikelyerror path, we bother carrying the data for all systems, which afaikis completely unnecessary. Once I confirm, I'll have Quake generatejust what is needed. Similarly, I think cm3 should have -print-host or somesuch.Then the platform probing in sysinfo.sh could probably all go away.(Except for my idea of /cm3/bin/cm3.sh that calls /cm3/bin/target/cm3.) There is more here than just the processor.So some runtime code would remain, even if the processorbecame hard coded at compile time. You know, there are a few models here: Use data at runtime asis. e.g. GetEnv("PROCESSOR_ARCHITECTURE") and be done. Does that work on CE? Build-in the data at compile time and be done. This requires possibly a revisit for every port, but simple. It goes obsolete in time, but not quietly, it'd be an error in the Quake code when a new platform is introduced. Or, if the string is just then automatically ports, no revisit. This doesn't have the concern "does it work on CE?" or of Posix vs. Win32 portability. Use data at runtime to pick among compile time data. This is the current approach and it goes obsolete quietly in time. As well, these functions are never even used that I can see.Remove them?Or assume they might be used outside the cm3 tree? (That's quite a "line" in decision makiing. It's so much nicerto assume/know you have all the relevant code visible and thereforecan make any change, provided you fix the client code, vs. having toassume there is "anything" out there.) - Jay> Date: Fri, 2 Jan 2009 21:22:55 +0000> To: m3commit@> From: jkrell@> Subject: [M3commit] CVS Update: cm3> > 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> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 5 03:17:47 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jan 2009 13:17:47 +1100 Subject: [M3devel] determing current processor as string In-Reply-To: References: <20090102202255.9177E10D5D00@birch.elegosoft.com> <3C9A9351-C543-44CE-A76F-B2490C423641@cs.purdue.edu> Message-ID: <02B4C407-A359-4358-A77E-F8C93EF07380@cs.purdue.edu> Hmm. I'm not sure I know what all the implications are to have an opinion. On 5 Jan 2009, at 12:23, Jay wrote: > Sorry, I had a tangent there. > The main question was regiarding a library feature, not a compiler > issue. > > > libm3/src/os/POSIX/OSConfigPosix.m3 > libm3/src/os/POSIX/OSConfig.i3 > libm3/src/os/WIN32/OSConfigWin32.m3 > libm3/src/os/WIN32/OSConfig.i3 > > The bulk of this code is never used in the cm3 tree anyway. > > The tangent was regarding "cm3 -dump-host" or such, though it's more > complicated maybe. Some hosts are "biarch" or "multiarch". > > - Jay > > > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] determing current processor as string > Date: Mon, 5 Jan 2009 12:12:56 +1100 > > > As far as I am concerned I think PPC or PowerPC is sufficient, since > the gcc-based backend figures out what it needs. Why would the > front-ends need to know? Perhaps I am missing your point... > > On 5 Jan 2009, at 09:57, Jay wrote: > > Thoughts here? > > > Does the processor need to be "friendly" and "precise" including stuff > not knowable at compile time (386 vs. 486 vs. 586, etc.), > or would just "PowerPC" or "PPC" suffice? > > > This question affects the Posix code. > > > The Posix code tries to fetch some data at runtime from uname, and > if that fails > it falls back to built in data. Besides that the data is used in an > unlikely > error path, we bother carrying the data for all systems, which afaik > is completely unnecessary. Once I confirm, I'll have Quake generate > just what is needed. > > > Similarly, I think cm3 should have -print-host or somesuch. > Then the platform probing in sysinfo.sh could probably all go away. > (Except for my idea of /cm3/bin/cm3.sh that calls /cm3/bin/target/ > cm3.) > > > There is more here than just the processor. > So some runtime code would remain, even if the processor > became hard coded at compile time. > > You know, there are a few models here: > > Use data at runtime asis. > e.g. GetEnv("PROCESSOR_ARCHITECTURE") and be done. > Does that work on CE? > > Build-in the data at compile time and be done. > This requires possibly a revisit for every port, but simple. > It goes obsolete in time, but not quietly, it'd be an error in > the Quake code > when a new platform is introduced. > Or, if the string is just then automatically ports, no > revisit. > This doesn't have the concern "does it work on CE?" or > of Posix vs. Win32 portability. > > Use data at runtime to pick among compile time data. > This is the current approach and it goes obsolete quietly in > time. > > > As well, these functions are never even used that I can see. > Remove them? > Or assume they might be used outside the cm3 tree? > > (That's quite a "line" in decision makiing. It's so much nicer > to assume/know you have all the relevant code visible and therefore > can make any change, provided you fix the client code, vs. having to > assume there is "anything" out there.) > > - Jay > > > > Date: Fri, 2 Jan 2009 21:22:55 +0000 > > To: m3commit@ > > From: jkrell@ > > Subject: [M3commit] CVS Update: cm3 > > > > 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 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 5 06:01:49 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 5 Jan 2009 05:01:49 +0000 Subject: [M3devel] race conditions under loose memory models/ compiler/processor reordering In-Reply-To: <20090105043713.783AD10D5E5B@birch.elegosoft.com> References: <20090105043713.783AD10D5E5B@birch.elegosoft.com> Message-ID: This code is very likely buggy, due to compiler or processor reordering, in a multithread environment, which we have. Prior to my change, it only required multiple threads to have a race condition. We need some sort of "barriers", as they are called. The writes to null_done must "divide" the code before it and the code after it. While they appear to, in the source, this is not likely guaranteed by the compiler or processor. It doesn't matter in a single threaded environment, but they don't generally exist. Or maybe an ability to mark variables as "volatile". In C, a fairly portable overkill fix is to sprinkle around volatile, but that generally makes the code more deoptimized than necessary. Volatile inhibits any reads or writes of the variable from being optimized away, and generally any reordering. However not all reads/writes need such treatment. Imagine a function that initialized a global on-demand, and then return that global plus itself -- the addition need only fetch the value once. What to do? VAR null_done := FALSE; null_stat: Ustat.struct_stat; null_fd: INTEGER; PROCEDURE IsDevNull(READONLY statbuf: Ustat.struct_stat): BOOLEAN RAISES {} = VAR result: INTEGER; BEGIN IF NOT null_done THEN null_fd := Unix.open(M3toC.FlatTtoS("/dev/null"), Unix.O_RDONLY, Unix.Mrwrwrw); IF null_fd < 0 THEN; null_done := TRUE; RETURN FALSE ELSE result := Ustat.fstat(null_fd, ADR(null_stat)); EVAL Unix.close(null_fd); IF result # 0 THEN null_fd := -1 END END; null_done := TRUE; END; RETURN null_fd >= 0 AND statbuf.st_rdev = null_stat.st_rdev END IsDevNull; - Jay> Date: Mon, 5 Jan 2009 05:37:13 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > 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..)> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Jan 5 11:49:15 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 05 Jan 2009 02:49:15 -0800 Subject: [M3devel] TEXT & etc. In-Reply-To: Your message of "Wed, 31 Dec 2008 15:52:06 CST." <495BE986.3030806@bellsouth.net> Message-ID: <200901051049.n05AnFrS077134@camembert.async.caltech.edu> Martin Bishop writes: .... >> > >This is somewhat off-topic, but is there a reason why you use CM3 as >opposed to PM3? I was under the impression that PM3 was "dead" and most >of it merged with CM3. I take it you got it backwards? You're asking why I use PM3? I use the following versions of Modula-3: -- on FreeBSD4 : PM3 (I also have CM3 for testing) -- PPC_DARWIN : CM3 (PM3 doesn't work) -- LINUXLIBC6 : CM3 (ditto) -- Windows (2000, XP, 2003 Server) : PM3 (Klagenfurt, very old) My main development and production platform is FreeBSD4, so I mainly use PM3. I used to use Windows 2003 for production as well, but hopefully that is now ended, and I can stick with FreeBSD (I'll run it in VMware on the win2003 system rather than deal with Windows). I have been trying to switch to CM3 for years, but for various reasons I have never managed to pull it off. At one time, CM3 didn't work on Cygwin (I don't care about that anymore, I hope, see above), and because I extensively use Pickles and Network Objects, I really do have to switch the production systems simultaneously from PM3 to CM3. Otherwise, there are the performance issues I raised in my previous email. Much of the code I have does run faster (sometimes a lot faster) under PM3; see some of my previous emails to m3devel on this issue. Most of the reasons I find switching from PM3 to CM3 difficult have, it turns out, something to do with the change in implementation of TEXT. That's why I had a modification to the text package attached to the email you responded to. Mika P.S. Let me add my voice to those calling for easy-to-install Modula-3 systems. I think it is just far too difficult to install the system, on many architecture/OS combinations. I think I am now unable to get one that works right on PPC_DARWIN... the bootstrap on the site is too old to compile the latest sources and it still has GC bugs in it... I know this is easy for people like Tony who do it all the time, but I come to it about once every six months and every time I think "oh no, not this again"... From hosking at cs.purdue.edu Mon Jan 5 11:47:15 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jan 2009 21:47:15 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20090105072548.AB46610D5D2A@birch.elegosoft.com> References: <20090105072548.AB46610D5D2A@birch.elegosoft.com> Message-ID: According to the language spec: The following operations are primarily used for address arithmetic: ADR (VAR x: Any) : ADDRESS infix + (x: ADDRESS, y:INTEGER) : ADDRESS infix - (x: ADDRESS, y:INTEGER) : ADDRESS infix - (x,y: ADDRESS) : INTEGER ADR(x) is the address of the variable x. The actual argument must be a designator but need not be writable. On 5 Jan 2009, at 08:25, Jay Krell wrote: > 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.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Jan 5 12:23:19 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 05 Jan 2009 03:23:19 -0800 Subject: [M3devel] variations of waitpid..? In-Reply-To: Your message of "Fri, 02 Jan 2009 19:15:48 GMT." Message-ID: <200901051123.n05BNJVB078904@camembert.async.caltech.edu> This is all really inside Process.Wait, right? On user threads: I can report (from having tried it) that changing the Wait to a small number doesn't really work. Once you have yielded, as far as the OS is concerned, you've already lost (at least on FreeBSD). The only thing that really works is busy waiting. The "correct" thing to do on unix is to catch SIGCHLD (SIGCLD?)... I started coding this up once, but I'm not sure I shared my code with anyone? I think it was Tony that pointed out that it was unnecessary with pthreads... Mika P.S. Happy New Year, everyone. Jay writes: >--_e7fe8011-c1fe-42de-b7fb-8ae54fa172fc_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >I didn't read that well -- the deadlock risk in sysutils is not there. >The bad perf is probably. >=20 >=20 >To be clear (esp. for folks that might not already know about this=2C >I didn't know about until fairly recently)=2C there are two options: >=20 >=20 >waitpid(pid=2C flags =3D 0) >move along >=20 >=20 >or >while (waitpid(pid=2C flags =3D nohang) !=3D 0) > sleep(some value) >=20 >=20 >The second is what sysutils was doing=2C and works=2C doesn't deadlock=2C i= >s deoptimized. > m3core/libm3 did this for a long time as well. When I complained about per= >f=2C it was pointed out to me. >=20 >The first has deadlock potential with userthreads=2C but is ok and faster w= >ith kernel threads. >=20 >=20 >waitpid(flags =3D nohang =3D don't actually wait=2C just get the exit code= >=2C if there is one) is a way to quickly poll if a process has ended=2C and= > if so=2C get its exit code. In Win32 there are two seperate functions GetE= >xitCodeProcess and WaitForSingleObject or WaitForMultipleObjects ("waiting"= > is generalized across files=2C processes=2C sockets=2C files=2C threads=2C= > semaphores=2C mutexes=2C events and more..but not critical sections..only = >kernel objects). These have a bug too. One particular exit code is reserved= > to mean "the process is still running"=2C but that is easily avoided by us= >ing Wait first. I have seen code get confused by this though. Wait also acc= >epts a timeout=2C 32bit unsigned milliseconds=2C including 0 and infinity= >=2C so also can be used to poll. Win32 also defines the exit code to be 32b= >its=2C whereas Posix only allows for 8 bits which can be an interop problem= >. Perl on Win32 truncates exit codes to 8 bits=2C very bad. Unhandled excep= >tions end up as "large" exit codes. >=20 >Anyway... >=20 >The problem with the polling approach=2C at least part of the problem=2C is= > that if the child process isn't done when waitpid is first called=2C but f= >inishes before sleep(whatever value) ends=2C we will still sleep for the fu= >ll "whatever value". You only really want to sleep until the child process = >is done=2C and no longer. >=20 >=20 >Making just the first sleep shorter might be a good idea. >You know=2C to handle processes that are short-lived=2C but not "zero" live= >d. >("zero" being the amount of time it takes for the code to proceed from fork= >/exec to waitpid=2C surely much smaller than a small sleep() but longer tha= >n no sleep). >=20 >=20 >Calling just waitpid(flags =3D 0) could deadlock if=2C for example=2C a par= >ent thread is writing to a child's stdin=2C and the child won't finish unti= >l the parent has written all that it needs to. The parent and child process= >=2C er=2C other threads in the parent process=2C need to be allowed to run = >concurrently=2C for the sake of at least some reasonable scenarios. >=20 >With kernelthreads=2C the implementation of waitpid knows about threads and= > will itself=2C in a sense=2C do the poll/sleep=2C but not exactly that -- = >it won't sleep beyond the child process finishing. >=20 >=20 >Hopefully this makes sense and lets more folks understand the problem. >=20 >=20 >What you can do=2C of course=2C is like: >=20 >=20 >if kernelthreads > waitpid(flags =3D 0) >else > while (waitpid(flags =3D nohang) !=3D 0) > sleep >=20 >=20 >and that is basically what the code looks like now. >=20 >The part "if kernelthreads" I propose be "if SchedulerPosix.DoesWaitPidYiel= >d()" >though a really direct "if Thread or Scheduler.KernelThreads" might be reas= >onable. >Up to folks then to decide what that implies.. >=20 > - Jay> Date: Fri=2C 2 Jan 2009 11:27:24 +0100> From: wagner at elegosoft.com>= > To: m3devel at elegosoft.com> Subject: Re: [M3devel] variations of waitpid..?= >> > Quoting Tony Hosking :> > > If someone uses wait= >pid they get what they paid for.> It is so long ago that we wrote those sys= >utils routines...> They have only ever be used in simple command line utili= >ties (like cm3)> without much concurrency=2C I think. If there is potential= > for deadlocks> and bad performance=2C we should at least document that in = >the interfaces.> > I am not up-to-date wrt. the M3 system interfaces and th= >reads> implementation: is there a way for a thread to wait for the exit cod= >e> of another process without blocking other threads? If so=2C I'll adapt> = >the sysutils code... If not=2C can we introduce such an interface in> m3cor= >e/libm3?> > Olaf> > > On 1 Jan 2009=2C at 06:24=2C Jay wrote:> >> >>> >> Yo= >u mean=2C this function is easy to misuse?> >>> People who declare their ow= >n <*EXTERNAL*>> >> Like waitpid exposed from m3core?> >>> >> waitpid is alr= >eady easy to misuse=2C on a userthread system=2C leading > >> to possible (= >though I think rare) deadlock.> >> It is easy to misuse on pthreads=2C lead= > "just" to bad performance=2C > >> and in fact I believe cm3 is doing this= >=2C via sysutils.> >> This at least guides you between two patterns of use= >=2C and fix the > >> perf of cm3/sysutils.> >>> >> On a userthread system= >=2C waitpid(pid=2C flags =3D 0) waits for the child > >> process=2C with al= >l parent threads suspended.> >> Generally I doubt the child depends on pare= >nt threads progressing=2C > >> but=2C yeah=2C that could deadlock=2C like i= >f a parent thread is waiting > >> to a file or stdin of the child=2C or rea= >ding a child's stdout.> >>> >> The various uses do waitpid(pid=2C flags =3D= > nohang) and then sleep and > >> try again.> >>> >> pthreads just uses wait= >pid(pid=2C flags =3D 0) and all threads keep running> > > > -- > Olaf Wagne= >r -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C= > 13355 Berlin=2C Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 86= >9 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch=E4ftsf=FChrer: = >Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB = >77719 | USt-IdNr: DE163214194> = > >--_e7fe8011-c1fe-42de-b7fb-8ae54fa172fc_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >I didn't read that well -- the deadlock risk in sysutils is not there.
>The bad perf is probably.
> =3B
> =3B
>To be clear (esp. for folks that might not already know about this=2C
>I didn't know about until fairly recently)=2C there are two options:
> =3B
> =3B
>waitpid(pid=2C flags =3D 0)
>move along
> =3B
> =3B
>or
>while (waitpid(pid=2C flags =3D nohang) !=3D 0)
> =3B =3B sleep(some value)
> =3B
> =3B
>The second is what sysutils was doing=2C and works=2C doesn't deadlock=2C i= >s deoptimized.
> =3Bm3core/libm3 did this for a long time as well. When I complained ab= >out perf=2C it was pointed out to me.
> =3B
>The first has deadlock potential with userthreads=2C but is ok and faster w= >ith kernel threads.
> =3B
> =3B
>waitpid(flags =3D nohang =3D =3Bdon't actually wait=2C just get the exi= >t code=2C if there is one) is a way to quickly poll if a process has ended= >=2C and if so=2C get its exit code. In Win32 there are two seperate functio= >ns GetExitCodeProcess and WaitForSingleObject or WaitForMultipleObjects ("w= >aiting" is generalized across files=2C processes=2C sockets=2C files=2C thr= >eads=2C semaphores=2C mutexes=2C events and more..but not critical sections= >..only kernel objects). These have a bug too. One particular exit code is r= >eserved to mean "the process is still running"=2C but that is easily avoide= >d by using Wait first. I have seen code get confused by this though. Wait a= >lso accepts a timeout=2C 32bit unsigned milliseconds=2C including 0 and inf= >inity=2C so also can be used to poll. Win32 also defines the exit code to b= >e 32bits=2C whereas Posix only allows for 8 bits which can be an interop pr= >oblem. Perl on Win32 truncates exit codes to 8 bits=2C very bad. Unhandled = >exceptions end up as "large" exit codes.
> =3B
>Anyway...
> =3B
>The problem with the polling approach=2C at least part of the problem=2C is= > that if the child process isn't done when waitpid is first called=2C but f= >inishes before sleep(whatever value) ends=2C we will still sleep for the fu= >ll "whatever value". You only really want to sleep until the child process = >is done=2C and no longer.
> =3B
> =3B
>Making just the first sleep shorter might be a good idea.
>You know=2C to handle processes that are short-lived=2C but not "zero" live= >d.
>("zero" being the amount of time it takes for the code to proceed from fork= >/exec to waitpid=2C surely much smaller than a small sleep() but longer tha= >n no sleep).
> =3B
> =3B
>Calling just waitpid(flags =3D 0) could deadlock if=2C for example=2C a par= >ent thread is writing to a child's stdin=2C and the child won't finish unti= >l the parent has written all that it needs to. The parent and child process= >=2C er=2C other threads in the parent process=2C need to be allowed to run = >concurrently=2C for the sake of at least some reasonable scenarios.
> =3B
>With kernelthreads=2C the implementation of waitpid knows about threads and= > will itself=2C in a sense=2C do the poll/sleep=2C but not exactly that -- = >it won't sleep beyond the child process finishing.
> =3B
> =3B
>Hopefully this makes sense and lets more folks understand the problem.
> =3B
> =3B
>What you can do=2C of course=2C is like:
> =3B
> =3B
>if kernelthreads
> =3B waitpid(flags =3D 0)
>else
> =3B while (waitpid(flags =3D nohang) !=3D 0)
> =3B =3Bsleep
> =3B
> =3B
>and that is basically what the code looks like now.
> =3B
>The part "if kernelthreads" I propose be "if SchedulerPosix.DoesWaitPidYiel= >d()"
>though a really direct "if Thread or Scheduler.KernelThreads" might be reas= >onable.
>Up to folks then to decide what that implies..
> =3B
> =3B- Jay


>=3B Date: Fri=2C 2 Jan 2009 11:27:24 +0100
&= >gt=3B From: wagner at elegosoft.com
>=3B To: m3devel at elegosoft.com
>= >=3B Subject: Re: [M3devel] variations of waitpid..?
>=3B
>=3B Qu= >oting Tony Hosking <=3Bhosking at cs.purdue.edu>=3B:
>=3B
>=3B = >>=3B If someone uses waitpid they get what they paid for.
>=3B It is= > so long ago that we wrote those sysutils routines...
>=3B They have o= >nly ever be used in simple command line utilities (like cm3)
>=3B with= >out much concurrency=2C I think. If there is potential for deadlocks
>= >=3B and bad performance=2C we should at least document that in the interfac= >es.
>=3B
>=3B I am not up-to-date wrt. the M3 system interfaces = >and threads
>=3B implementation: is there a way for a thread to wait f= >or the exit code
>=3B of another process without blocking other thread= >s? If so=2C I'll adapt
>=3B the sysutils code... If not=2C can we intr= >oduce such an interface in
>=3B m3core/libm3?
>=3B
>=3B Ola= >f
>=3B
>=3B >=3B On 1 Jan 2009=2C at 06:24=2C Jay wrote:
&g= >t=3B >=3B
>=3B >=3B>=3B
>=3B >=3B>=3B You mean=2C this = >function is easy to misuse?
>=3B >=3B>=3B>=3B People who declare= > their own <=3B*EXTERNAL*>=3B
>=3B >=3B>=3B Like waitpid expos= >ed from m3core?
>=3B >=3B>=3B
>=3B >=3B>=3B waitpid is al= >ready easy to misuse=2C on a userthread system=2C leading
>=3B >=3B= >>=3B to possible (though I think rare) deadlock.
>=3B >=3B>=3B I= >t is easy to misuse on pthreads=2C lead "just" to bad performance=2C
&g= >t=3B >=3B>=3B and in fact I believe cm3 is doing this=2C via sysutils.<= >BR>>=3B >=3B>=3B This at least guides you between two patterns of use= >=2C and fix the
>=3B >=3B>=3B perf of cm3/sysutils.
>=3B >= >=3B>=3B
>=3B >=3B>=3B On a userthread system=2C waitpid(pid=2C f= >lags =3D 0) waits for the child
>=3B >=3B>=3B process=2C with all= > parent threads suspended.
>=3B >=3B>=3B Generally I doubt the chi= >ld depends on parent threads progressing=2C
>=3B >=3B>=3B but=2C = >yeah=2C that could deadlock=2C like if a parent thread is waiting
>= >=3B >=3B>=3B to a file or stdin of the child=2C or reading a child's st= >dout.
>=3B >=3B>=3B
>=3B >=3B>=3B The various uses do wai= >tpid(pid=2C flags =3D nohang) and then sleep and
>=3B >=3B>=3B tr= >y again.
>=3B >=3B>=3B
>=3B >=3B>=3B pthreads just uses w= >aitpid(pid=2C flags =3D 0) and all threads keep running
>=3B
>= >=3B
>=3B
>=3B --
>=3B Olaf Wagner -- elego Software Solut= >ions GmbH
>=3B Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C= > Germany
>=3B phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: = >+49 30 23 45 86 95
>=3B http://www.elegosoft.com | Gesch=E4ftsf=FChrer= >: Olaf Wagner | Sitz: Berlin
>=3B Handelregister: Amtsgericht Charlott= >enburg HRB 77719 | USt-IdNr: DE163214194
>=3B

>= > >--_e7fe8011-c1fe-42de-b7fb-8ae54fa172fc_-- From jay.krell at cornell.edu Mon Jan 5 19:00:43 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 5 Jan 2009 18:00:43 +0000 Subject: [M3devel] variations of waitpid..? In-Reply-To: <200901051123.n05BNJVB078904@camembert.async.caltech.edu> References: Your message of "Fri, 02 Jan 2009 19:15:48 GMT." <200901051123.n05BNJVB078904@camembert.async.caltech.edu> Message-ID: Yes, it is "all" inside Process.Wait, except that sysutils implements this stuff itself, so it is also in there. You can consider that there are two implementations of Process.Wait. Correct, no need on pthreads or NT -- the code has two different modes, "slow" and "fast". Or rather, "slow posix", "fast posix", and "fast NT". The problem was, the posix code didn't know how to chose, so was just always "slow". Imho this just one more reason to never use user threads but I seem to be the only one. > the Wait to a small number doesn't really work. Once you have> yielded, as far as the OS is concerned, you've already lost (at> least on FreeBSD). The only thing that really works is busy waiting. I don't understand. I mean, well, ignoring something for a sec, you must yield. My suggestion, in a commit comment, that maybe the first wait should be much shorter. You know, the sequence is like: fork/exec run through a /little/ bit of code label check if process done if not "sleep" (actual a call into the m3 scheduler which will run other threads goto label A point is that the first check is going to VERY soon after the process starts. The child would have to be VERY quick for the first check to find it is done. Perhaps it is merely "fairly quick", but not "VERY quick" we could win by making just the first wait smaller. You know, the inefficiency here I believe is the time the child takes to run modulo the sleep duration, and then divided by child duration. You want to find the child is done as soon as possible after it is actually done. You don't want to keep waiting. For long running children, the inefficiency is less. For short running children, the inefficiency is likely more. Shrinking the wait has a positive and negative affect on efficiency. You know, making it very small reduces the inefficiency here, but adds inefficiency because we'd spend more time merely checking the process status. Another idea is to "hang" (be fast) if the program is single threaded, however, "single threaded" is nearly impossible to practically discover, since there will always be worker threads, just that they are not dependent or depended-upon the child process. You know, there is the garbage collector thread, at least. Ok, what I was ignoring is your suggestion of handling sigchild. I'll try to look into that, sounds promising. But again, if you just use pthreads, no problem. Again, the previous code was even slow on pthreads, but should be better now. Again, if you just ignore user threads, no longer a problem. - Jay> To: jay.krell at cornell.edu> Date: Mon, 5 Jan 2009 03:23:19 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] variations of waitpid..?> > > This is all really inside Process.Wait, right?> > On user threads: I can report (from having tried it) that changing> the Wait to a small number doesn't really work. Once you have> yielded, as far as the OS is concerned, you've already lost (at> least on FreeBSD). The only thing that really works is busy waiting.> > The "correct" thing to do on unix is to catch SIGCHLD (SIGCLD?)...> > I started coding this up once, but I'm not sure I shared my code> with anyone? I think it was Tony that pointed out that it was> unnecessary with pthreads...> > Mika> > P.S. Happy New Year, everyone.> > > > Jay writes:> >--_e7fe8011-c1fe-42de-b7fb-8ae54fa172fc_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >I didn't read that well -- the deadlock risk in sysutils is not there.> >The bad perf is probably.> >=20> >=20> >To be clear (esp. for folks that might not already know about this=2C> >I didn't know about until fairly recently)=2C there are two options:> >=20> >=20> >waitpid(pid=2C flags =3D 0)> >move along> >=20> >=20> >or> >while (waitpid(pid=2C flags =3D nohang) !=3D 0)> > sleep(some value)> >=20> >=20> >The second is what sysutils was doing=2C and works=2C doesn't deadlock=2C i=> >s deoptimized.> > m3core/libm3 did this for a long time as well. When I complained about per=> >f=2C it was pointed out to me.> >=20> >The first has deadlock potential with userthreads=2C but is ok and faster w=> >ith kernel threads.> >=20> >=20> >waitpid(flags =3D nohang =3D don't actually wait=2C just get the exit code=> >=2C if there is one) is a way to quickly poll if a process has ended=2C and=> > if so=2C get its exit code. In Win32 there are two seperate functions GetE=> >xitCodeProcess and WaitForSingleObject or WaitForMultipleObjects ("waiting"=> > is generalized across files=2C processes=2C sockets=2C files=2C threads=2C=> > semaphores=2C mutexes=2C events and more..but not critical sections..only => >kernel objects). These have a bug too. One particular exit code is reserved=> > to mean "the process is still running"=2C but that is easily avoided by us=> >ing Wait first. I have seen code get confused by this though. Wait also acc=> >epts a timeout=2C 32bit unsigned milliseconds=2C including 0 and infinity=> >=2C so also can be used to poll. Win32 also defines the exit code to be 32b=> >its=2C whereas Posix only allows for 8 bits which can be an interop problem=> >. Perl on Win32 truncates exit codes to 8 bits=2C very bad. Unhandled excep=> >tions end up as "large" exit codes.> >=20> >Anyway...> >=20> >The problem with the polling approach=2C at least part of the problem=2C is=> > that if the child process isn't done when waitpid is first called=2C but f=> >inishes before sleep(whatever value) ends=2C we will still sleep for the fu=> >ll "whatever value". You only really want to sleep until the child process => >is done=2C and no longer.> >=20> >=20> >Making just the first sleep shorter might be a good idea.> >You know=2C to handle processes that are short-lived=2C but not "zero" live=> >d.> >("zero" being the amount of time it takes for the code to proceed from fork=> >/exec to waitpid=2C surely much smaller than a small sleep() but longer tha=> >n no sleep).> >=20> >=20> >Calling just waitpid(flags =3D 0) could deadlock if=2C for example=2C a par=> >ent thread is writing to a child's stdin=2C and the child won't finish unti=> >l the parent has written all that it needs to. The parent and child process=> >=2C er=2C other threads in the parent process=2C need to be allowed to run => >concurrently=2C for the sake of at least some reasonable scenarios.> >=20> >With kernelthreads=2C the implementation of waitpid knows about threads and=> > will itself=2C in a sense=2C do the poll/sleep=2C but not exactly that -- => >it won't sleep beyond the child process finishing.> >=20> >=20> >Hopefully this makes sense and lets more folks understand the problem.> >=20> >=20> >What you can do=2C of course=2C is like:> >=20> >=20> >if kernelthreads> > waitpid(flags =3D 0)> >else> > while (waitpid(flags =3D nohang) !=3D 0)> > sleep> >=20> >=20> >and that is basically what the code looks like now.> >=20> >The part "if kernelthreads" I propose be "if SchedulerPosix.DoesWaitPidYiel=> >d()"> >though a really direct "if Thread or Scheduler.KernelThreads" might be reas=> >onable.> >Up to folks then to decide what that implies..> >=20> > - Jay> Date: Fri=2C 2 Jan 2009 11:27:24 +0100> From: wagner at elegosoft.com>=> > To: m3devel at elegosoft.com> Subject: Re: [M3devel] variations of waitpid..?=> >> > Quoting Tony Hosking :> > > If someone uses wait=> >pid they get what they paid for.> It is so long ago that we wrote those sys=> >utils routines...> They have only ever be used in simple command line utili=> >ties (like cm3)> without much concurrency=2C I think. If there is potential=> > for deadlocks> and bad performance=2C we should at least document that in => >the interfaces.> > I am not up-to-date wrt. the M3 system interfaces and th=> >reads> implementation: is there a way for a thread to wait for the exit cod=> >e> of another process without blocking other threads? If so=2C I'll adapt> => >the sysutils code... If not=2C can we introduce such an interface in> m3cor=> >e/libm3?> > Olaf> > > On 1 Jan 2009=2C at 06:24=2C Jay wrote:> >> >>> >> Yo=> >u mean=2C this function is easy to misuse?> >>> People who declare their ow=> >n <*EXTERNAL*>> >> Like waitpid exposed from m3core?> >>> >> waitpid is alr=> >eady easy to misuse=2C on a userthread system=2C leading > >> to possible (=> >though I think rare) deadlock.> >> It is easy to misuse on pthreads=2C lead=> > "just" to bad performance=2C > >> and in fact I believe cm3 is doing this=> >=2C via sysutils.> >> This at least guides you between two patterns of use=> >=2C and fix the > >> perf of cm3/sysutils.> >>> >> On a userthread system=> >=2C waitpid(pid=2C flags =3D 0) waits for the child > >> process=2C with al=> >l parent threads suspended.> >> Generally I doubt the child depends on pare=> >nt threads progressing=2C > >> but=2C yeah=2C that could deadlock=2C like i=> >f a parent thread is waiting > >> to a file or stdin of the child=2C or rea=> >ding a child's stdout.> >>> >> The various uses do waitpid(pid=2C flags =3D=> > nohang) and then sleep and > >> try again.> >>> >> pthreads just uses wait=> >pid(pid=2C flags =3D 0) and all threads keep running> > > > -- > Olaf Wagne=> >r -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C=> > 13355 Berlin=2C Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 86=> >9 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch=E4ftsf=FChrer: => >Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB => >77719 | USt-IdNr: DE163214194> => >> >--_e7fe8011-c1fe-42de-b7fb-8ae54fa172fc_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >> >I didn't read that well -- the deadlock risk in sysutils is not there.
> >The bad perf is probably.
> > =3B
> > =3B
> >To be clear (esp. for folks that might not already know about this=2C
> >I didn't know about until fairly recently)=2C there are two options:
> > =3B
> > =3B
> >waitpid(pid=2C flags =3D 0)
> >move along
> > =3B
> > =3B
> >or
> >while (waitpid(pid=2C flags =3D nohang) !=3D 0)
> > =3B =3B sleep(some value)
> > =3B
> > =3B
> >The second is what sysutils was doing=2C and works=2C doesn't deadlock=2C i=> >s deoptimized.
> > =3Bm3core/libm3 did this for a long time as well. When I complained ab=> >out perf=2C it was pointed out to me.
> > =3B
> >The first has deadlock potential with userthreads=2C but is ok and faster w=> >ith kernel threads.
> > =3B
> > =3B
> >waitpid(flags =3D nohang =3D =3Bdon't actually wait=2C just get the exi=> >t code=2C if there is one) is a way to quickly poll if a process has ended=> >=2C and if so=2C get its exit code. In Win32 there are two seperate functio=> >ns GetExitCodeProcess and WaitForSingleObject or WaitForMultipleObjects ("w=> >aiting" is generalized across files=2C processes=2C sockets=2C files=2C thr=> >eads=2C semaphores=2C mutexes=2C events and more..but not critical sections=> >..only kernel objects). These have a bug too. One particular exit code is r=> >eserved to mean "the process is still running"=2C but that is easily avoide=> >d by using Wait first. I have seen code get confused by this though. Wait a=> >lso accepts a timeout=2C 32bit unsigned milliseconds=2C including 0 and inf=> >inity=2C so also can be used to poll. Win32 also defines the exit code to b=> >e 32bits=2C whereas Posix only allows for 8 bits which can be an interop pr=> >oblem. Perl on Win32 truncates exit codes to 8 bits=2C very bad. Unhandled => >exceptions end up as "large" exit codes.
> > =3B
> >Anyway...
> > =3B
> >The problem with the polling approach=2C at least part of the problem=2C is=> > that if the child process isn't done when waitpid is first called=2C but f=> >inishes before sleep(whatever value) ends=2C we will still sleep for the fu=> >ll "whatever value". You only really want to sleep until the child process => >is done=2C and no longer.
> > =3B
> > =3B
> >Making just the first sleep shorter might be a good idea.
> >You know=2C to handle processes that are short-lived=2C but not "zero" live=> >d.
> >("zero" being the amount of time it takes for the code to proceed from fork=> >/exec to waitpid=2C surely much smaller than a small sleep() but longer tha=> >n no sleep).
> > =3B
> > =3B
> >Calling just waitpid(flags =3D 0) could deadlock if=2C for example=2C a par=> >ent thread is writing to a child's stdin=2C and the child won't finish unti=> >l the parent has written all that it needs to. The parent and child process=> >=2C er=2C other threads in the parent process=2C need to be allowed to run => >concurrently=2C for the sake of at least some reasonable scenarios.
> > =3B
> >With kernelthreads=2C the implementation of waitpid knows about threads and=> > will itself=2C in a sense=2C do the poll/sleep=2C but not exactly that -- => >it won't sleep beyond the child process finishing.
> > =3B
> > =3B
> >Hopefully this makes sense and lets more folks understand the problem.
> > =3B
> > =3B
> >What you can do=2C of course=2C is like:
> > =3B
> > =3B
> >if kernelthreads
> > =3B waitpid(flags =3D 0)
> >else
> > =3B while (waitpid(flags =3D nohang) !=3D 0)
> > =3B =3Bsleep
> > =3B
> > =3B
> >and that is basically what the code looks like now.
> > =3B
> >The part "if kernelthreads" I propose be "if SchedulerPosix.DoesWaitPidYiel=> >d()"
> >though a really direct "if Thread or Scheduler.KernelThreads" might be reas=> >onable.
> >Up to folks then to decide what that implies..
> > =3B
> > =3B- Jay


>=3B Date: Fri=2C 2 Jan 2009 11:27:24 +0100
&=> >gt=3B From: wagner at elegosoft.com
>=3B To: m3devel at elegosoft.com
>=> >=3B Subject: Re: [M3devel] variations of waitpid..?
>=3B
>=3B Qu=> >oting Tony Hosking <=3Bhosking at cs.purdue.edu>=3B:
>=3B
>=3B => >>=3B If someone uses waitpid they get what they paid for.
>=3B It is=> > so long ago that we wrote those sysutils routines...
>=3B They have o=> >nly ever be used in simple command line utilities (like cm3)
>=3B with=> >out much concurrency=2C I think. If there is potential for deadlocks
>=> >=3B and bad performance=2C we should at least document that in the interfac=> >es.
>=3B
>=3B I am not up-to-date wrt. the M3 system interfaces => >and threads
>=3B implementation: is there a way for a thread to wait f=> >or the exit code
>=3B of another process without blocking other thread=> >s? If so=2C I'll adapt
>=3B the sysutils code... If not=2C can we intr=> >oduce such an interface in
>=3B m3core/libm3?
>=3B
>=3B Ola=> >f
>=3B
>=3B >=3B On 1 Jan 2009=2C at 06:24=2C Jay wrote:
&g=> >t=3B >=3B
>=3B >=3B>=3B
>=3B >=3B>=3B You mean=2C this => >function is easy to misuse?
>=3B >=3B>=3B>=3B People who declare=> > their own <=3B*EXTERNAL*>=3B
>=3B >=3B>=3B Like waitpid expos=> >ed from m3core?
>=3B >=3B>=3B
>=3B >=3B>=3B waitpid is al=> >ready easy to misuse=2C on a userthread system=2C leading
>=3B >=3B=> >>=3B to possible (though I think rare) deadlock.
>=3B >=3B>=3B I=> >t is easy to misuse on pthreads=2C lead "just" to bad performance=2C
&g=> >t=3B >=3B>=3B and in fact I believe cm3 is doing this=2C via sysutils.<=> >BR>>=3B >=3B>=3B This at least guides you between two patterns of use=> >=2C and fix the
>=3B >=3B>=3B perf of cm3/sysutils.
>=3B >=> >=3B>=3B
>=3B >=3B>=3B On a userthread system=2C waitpid(pid=2C f=> >lags =3D 0) waits for the child
>=3B >=3B>=3B process=2C with all=> > parent threads suspended.
>=3B >=3B>=3B Generally I doubt the chi=> >ld depends on parent threads progressing=2C
>=3B >=3B>=3B but=2C => >yeah=2C that could deadlock=2C like if a parent thread is waiting
>=> >=3B >=3B>=3B to a file or stdin of the child=2C or reading a child's st=> >dout.
>=3B >=3B>=3B
>=3B >=3B>=3B The various uses do wai=> >tpid(pid=2C flags =3D nohang) and then sleep and
>=3B >=3B>=3B tr=> >y again.
>=3B >=3B>=3B
>=3B >=3B>=3B pthreads just uses w=> >aitpid(pid=2C flags =3D 0) and all threads keep running
>=3B
>=> >=3B
>=3B
>=3B --
>=3B Olaf Wagner -- elego Software Solut=> >ions GmbH
>=3B Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C=> > Germany
>=3B phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: => >+49 30 23 45 86 95
>=3B http://www.elegosoft.com | Gesch=E4ftsf=FChrer=> >: Olaf Wagner | Sitz: Berlin
>=3B Handelregister: Amtsgericht Charlott=> >enburg HRB 77719 | USt-IdNr: DE163214194
>=3B

> >=> >> >--_e7fe8011-c1fe-42de-b7fb-8ae54fa172fc_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 5 19:04:22 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 5 Jan 2009 18:04:22 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090105072548.AB46610D5D2A@birch.elegosoft.com> Message-ID: Reading the code ...there is a command line option to the compiler to apparently make it: ADR (x: T) : UNTRACED REF T. Good?bad?better?different? Seems more type safe. I haven't tried it. - Jay From: hosking at cs.purdue.eduTo: jkrell at elego.deDate: Mon, 5 Jan 2009 21:47:15 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3According to the language spec: The following operations are primarily used for address arithmetic: ADR (VAR x: Any) : ADDRESS infix + (x: ADDRESS, y:INTEGER) : ADDRESS infix - (x: ADDRESS, y:INTEGER) : ADDRESS infix - (x,y: ADDRESS) : INTEGER ADR(x) is the address of the variable x. The actual argument must be a designator but need not be writable. On 5 Jan 2009, at 08:25, Jay Krell wrote: CVSROOT: /usr/cvsChanges by: jkrell at birch. 09/01/05 08:25:48Modified 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.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Jan 5 19:18:57 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 05 Jan 2009 10:18:57 -0800 Subject: [M3devel] variations of waitpid..? In-Reply-To: Your message of "Mon, 05 Jan 2009 18:00:43 GMT." Message-ID: <200901051818.n05IIviI093998@camembert.async.caltech.edu> Jay writes: >--_5fe387c0-3f5b-4882-b57b-b7299ded497e_ ... > much shorter. >You know=2C the sequence is like: > fork/exec=20 > run through a /little/ bit of code=20 > label=20 > check if process done=20 > if not > "sleep" (actual a call into the m3 scheduler which will run other thre= >ads=20 > goto label=20 >=20 ... You're right, but under user threads, here's what can (and does) happen, e.g., in the compiler itself: - Start child process - Call Process.Wait, which... - Calls Thread.Pause(somesmallnumber) There are no runnable threads, so the runtime yields the processor. I think it calls Unix's sleep? The OS scheduler then schedules the process at a very low priority. In most OSes, processes waiting for I/O have the highest priority, and processes sleeping have the lowest. So you've gone from waiting for a process to exit, at high priority, to sleeping, at very low priority. The OS then takes its time to get around to waking you up again. This is my theory of what happens on FreeBSD anyhow. It is the way I describe my experimental result that you can change that sleep to anything and it doesn't run noticeably faster than with 0.1d0. Getting rid of the Thread.Pause speeds things up substantially :-) Mika From jay.krell at cornell.edu Mon Jan 5 20:04:16 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 5 Jan 2009 19:04:16 +0000 Subject: [M3devel] variations of waitpid..? In-Reply-To: <200901051818.n05IIviI093998@camembert.async.caltech.edu> References: Your message of "Mon, 05 Jan 2009 18:00:43 GMT." <200901051818.n05IIviI093998@camembert.async.caltech.edu> Message-ID: > - Start child process > - Call Process.Wait, which... > - Calls Thread.Pause(somesmallnumber) There is a call to waitpid before the Thread.Pause. If the process finishes /very/ quickly, probably never happens, no pause/sleep. > There are no runnable threads, so the runtime yields the processor. > I think it calls Unix's sleep? Agreed probably no runnable threads typically and sleep(). Perhaps the scheduler knows that none of the threads will become runnable, but I doubt it. > The OS scheduler then schedules the process at a very low priority. > In most OSes, processes waiting for I/O have the highest priority, > and processes sleeping have the lowest. So you've gone from waiting > for a process to exit, at high priority, to sleeping, at very low > priority. The OS then takes its time to get around to waking you > up again. Hm. Why does sleep() imply anything about priority? Why doesn't it mean "don't run at all for a certain duration, and then when the duration elapses, resume running ASAP, with the same priority as it has before sleeping"? Surely "not running at all for a certain duration" does not mean "low priority"? There is a problem -- it will wait the entire duration, even if the process exists half way through. > Getting rid of the Thread.Pause speeds things up substantially :-) But it can also cause damage. If there is a dependency between the child process and other parent threads. Often there is not, sometimes there is. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 5 21:27:50 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 5 Jan 2009 20:27:50 +0000 Subject: [M3devel] SIG_DFL, SIG_IGN duplication (and RTSignal.m3 duplication) Message-ID: SIG_DFL and SIG_IGN are effectively duplicated twice for every platform. Once in Usignal.i3, once in RTSignal.m3. 1) The duplication in RTSignal.m3 I would think wouldn't be needed if module initialization occurs in a "correct" order. ? 2) The duplication in RTSignal.m3 could be eliminated if all platforms defined Usiginal.SIG_DFL, SIG_IGN, like Darwin and Solaris do -- a constant integer that you must LOOPHOLE instead of a correctly type variable that gets initialized (the variables have multiple correct types besides, due to signal handlers having at least three possible prototypes, ANSI C, BSD, and POSIX). Perhaps Usignal could provide both a constant integer for folks to LOOPHOLE, and a typed initialized variable. Since both sides are system-dependent, there isn't a "disconnect", porters just have to check both copies. Apparently the values are always the same across all platforms, but that might be a coincidence of sorts. I rather suspect in the old days, people copied C header content around a lot to other C code, leading to values like becoming impossible to change, including constants and types, not just the arguably "easier" function prototypes. Anyway, my inclination is rewrite the small number of clients in C, fixing both this, and reducing the cloned headers. -- As well stopping the duplication of RTSignal.m3, of which there are 37 nearly identical copies, or roughly 3 variants duplicated 37 times (again, ANSI, BSD, POSIX). Other clients I see are: C:\dev2\cm3.2\m3-libs\m3core\src\float\DS3100\FloatMode.m3(360): ELSIF (p = Usignal.SIG_DFL) THENC:\dev2\cm3.2\m3-libs\m3core\src\float\IRIX5\FloatMode.m3(361): ELSIF (p = Usignal.SIG_DFL) THENC:\dev2\cm3.2\m3-libs\m3core\src\float\DS3100\FloatMode.m3(358): IF (p = Usignal.SIG_IGN) THENC:\dev2\cm3.2\m3-libs\m3core\src\float\IRIX5\FloatMode.m3(359): IF (p = Usignal.SIG_IGN) THEN but these are dead for multiple reasons. The platforms are dead/dormant, and platform-specific FloatMode is dead in general, though perhaps should not be. (I do have a machine running Irix so hope to get that building/working before much longer...DS3100 no.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinbishop at bellsouth.net Tue Jan 6 21:50:56 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Tue, 06 Jan 2009 14:50:56 -0600 Subject: [M3devel] Widechars Message-ID: <4963C430.9020804@bellsouth.net> I'm playing around with WIDECHARS, and having some trouble. VAR wide := ARRAY OF WIDECHAR {'\x304A', '\x306F', '\x3088', '\x3046'}; s := Text.FromWideChars(wide); I get these errors from the compiler: "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: syntax error: missing '}' (4) "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal 9 errors encountered It seems like it's reading '\x304A' as '\x30' (which is why it says "syntax error: missing '}' (4)") Do I need some special literal letter or something? From roland.illig at gmx.de Tue Jan 6 22:31:28 2009 From: roland.illig at gmx.de (Roland Illig) Date: Tue, 06 Jan 2009 22:31:28 +0100 Subject: [M3devel] Widechars In-Reply-To: <4963C430.9020804@bellsouth.net> References: <4963C430.9020804@bellsouth.net> Message-ID: <4963CDB0.9020500@gmx.de> Martin Bishop schrieb: > I'm playing around with WIDECHARS, and having some trouble. > > VAR wide := ARRAY OF WIDECHAR {'\x304A', '\x306F', '\x3088', '\x3046'}; > s := Text.FromWideChars(wide); >From what I just read in the CM3 compiler's source code, it only understands simple octal character escape sequences, and even those return a CHAR, not a WIDECHAR. So the question that remains is: What is the most readable, shortest form of encoding a WIDECHAR literal, or a WIDETEXT? Roland From hendrik at topoi.pooq.com Wed Jan 7 16:33:56 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 7 Jan 2009 10:33:56 -0500 Subject: [M3devel] Widechars In-Reply-To: <4963CDB0.9020500@gmx.de> References: <4963C430.9020804@bellsouth.net> <4963CDB0.9020500@gmx.de> Message-ID: <20090107153356.GA608@topoi.pooq.com> On Tue, Jan 06, 2009 at 10:31:28PM +0100, Roland Illig wrote: > Martin Bishop schrieb: > > I'm playing around with WIDECHARS, and having some trouble. > > > > VAR wide := ARRAY OF WIDECHAR {'\x304A', '\x306F', '\x3088', '\x3046'}; > > s := Text.FromWideChars(wide); > > >From what I just read in the CM3 compiler's source code, it only > understands simple octal character escape sequences, and even those > return a CHAR, not a WIDECHAR. > > So the question that remains is: What is the most readable, shortest > form of encoding a WIDECHAR literal, or a WIDETEXT? Most readable, probably UTF-8. > > Roland From dabenavidesd at yahoo.es Wed Jan 7 06:08:34 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 7 Jan 2009 05:08:34 +0000 (GMT) Subject: [M3devel] Widechars Message-ID: <601806.14495.qm@web28604.mail.ukl.yahoo.com> Hi all, I believe you need to declare wide VAR? with fixed size or create it as a Reference type ? VAR wide := ARRAY [1..4] OF WIDECHAR {'\x304A', '\x306F', '\x3088', '\x3046'};or arrWideChar:= NEW (REF ARRAY OF WIDECHAR, 4); arrWideChar[0]:='\x304A'; .... I'm not sure if you can do this, would be interesting to know: arrWideChar:= NEW (REF ARRAY OF WIDECHAR{'\x304A', '\x306F', '\x3088', '\x3046'} ); See further explanations on:? http://opencm3.net/doc/tutorial/m3/m3_54.html#SEC54 Also the language definition, http://opencm3.net/doc/reference/arrays.html Hope that helps --- El mar, 6/1/09, Martin Bishop wrote: De: Martin Bishop Asunto: [M3devel] Widechars Para: m3devel at elegosoft.com Fecha: martes, 6 enero, 2009 3:50 I'm playing around with WIDECHARS, and having some trouble. VAR wide := ARRAY OF WIDECHAR {'\x304A', '\x306F', '\x3088', '\x3046'}; s := Text.FromWideChars(wide); I get these errors from the compiler: "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: syntax error: missing '}' (4) "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal "../Length.m3", line 5: missing closing quote on character literal 9 errors encountered It seems like it's reading '\x304A' as '\x30' (which is why it says "syntax error: missing '}' (4)") Do I need some special literal letter or something? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Wed Jan 7 04:25:08 2009 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Tue, 06 Jan 2009 21:25:08 -0600 Subject: [M3devel] Widechars In-Reply-To: <4963C430.9020804@bellsouth.net> References: <4963C430.9020804@bellsouth.net> Message-ID: <49642094.7040400@wichita.edu> Literals of type WIDECHAR are written, e.g. W'\x304A', note the 'W'. It makes them have type WIDECHAR and also enables the 16-bit escape sequences you are using. If it is a CHAR or plain TEXT literal (no 'W' or 'w'), octal escapes must have exactly 3 octal digits and hex escapes must have exactly 2 hex digits. In WIDECHAR and wide TEXT literals, octal escapes must have exactly 6 and hex escapes exactly 4. Note that character literals without/with the 'W' are of different types, CHAR and WIDECHAR, respectively. For Text literals, both forms have the same type TEXT, but the lexical formation rules are different without/with the 'W'. I'm not sure where or even whether this is documented. Rodney Bates Martin Bishop wrote: > I'm playing around with WIDECHARS, and having some trouble. > > VAR wide := ARRAY OF WIDECHAR {'\x304A', '\x306F', '\x3088', '\x3046'}; > s := Text.FromWideChars(wide); > > I get these errors from the compiler: > "../Length.m3", line 5: missing closing quote on character literal > "../Length.m3", line 5: syntax error: missing '}' (4) > "../Length.m3", line 5: missing closing quote on character literal > "../Length.m3", line 5: missing closing quote on character literal > "../Length.m3", line 5: missing closing quote on character literal > "../Length.m3", line 5: missing closing quote on character literal > "../Length.m3", line 5: missing closing quote on character literal > "../Length.m3", line 5: missing closing quote on character literal > "../Length.m3", line 5: missing closing quote on character literal > 9 errors encountered > > It seems like it's reading '\x304A' as '\x30' (which is why it says > "syntax error: missing '}' (4)") > > Do I need some special literal letter or something? > > From darko at darko.org Wed Jan 7 07:05:01 2009 From: darko at darko.org (Darko) Date: Wed, 7 Jan 2009 15:05:01 +0900 Subject: [M3devel] Widechars In-Reply-To: <49642094.7040400@wichita.edu> References: <4963C430.9020804@bellsouth.net> <49642094.7040400@wichita.edu> Message-ID: <1817F156-E305-4126-8AC0-B3070E31B330@darko.org> Yes it is documented, if you read the compiler source code. On 07/01/2009, at 12:25 PM, Rodney M. Bates wrote: > Literals of type WIDECHAR are written, e.g. W'\x304A', note the 'W'. > It makes them have type WIDECHAR and also enables the 16-bit escape > sequences you are using. If it is a CHAR or plain TEXT literal > (no 'W' or 'w'), octal escapes must have exactly 3 octal digits and > hex escapes must have exactly 2 hex digits. In WIDECHAR and wide > TEXT literals, octal escapes must have exactly 6 and hex escapes > exactly 4. > > Note that character literals without/with the 'W' are of different > types, CHAR and WIDECHAR, respectively. For Text literals, both > forms have the same type TEXT, but the lexical formation rules > are different without/with the 'W'. > > I'm not sure where or even whether this is documented. > > Rodney Bates > > > Martin Bishop wrote: >> I'm playing around with WIDECHARS, and having some trouble. >> VAR wide := ARRAY OF WIDECHAR {'\x304A', '\x306F', '\x3088', >> '\x3046'}; >> s := Text.FromWideChars(wide); >> I get these errors from the compiler: >> "../Length.m3", line 5: missing closing quote on character literal >> "../Length.m3", line 5: syntax error: missing '}' (4) >> "../Length.m3", line 5: missing closing quote on character literal >> "../Length.m3", line 5: missing closing quote on character literal >> "../Length.m3", line 5: missing closing quote on character literal >> "../Length.m3", line 5: missing closing quote on character literal >> "../Length.m3", line 5: missing closing quote on character literal >> "../Length.m3", line 5: missing closing quote on character literal >> "../Length.m3", line 5: missing closing quote on character literal >> 9 errors encountered >> It seems like it's reading '\x304A' as '\x30' (which is why it says >> "syntax error: missing '}' (4)") >> Do I need some special literal letter or something? > From hendrik at topoi.pooq.com Thu Jan 8 07:13:56 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 8 Jan 2009 01:13:56 -0500 Subject: [M3devel] Widechars In-Reply-To: <49642094.7040400@wichita.edu> References: <4963C430.9020804@bellsouth.net> <49642094.7040400@wichita.edu> Message-ID: <20090108061355.GA2554@topoi.pooq.com> On Tue, Jan 06, 2009 at 09:25:08PM -0600, Rodney M. Bates wrote: > Literals of type WIDECHAR are written, e.g. W'\x304A', note the 'W'. > It makes them have type WIDECHAR and also enables the 16-bit escape > sequences you are using. If it is a CHAR or plain TEXT literal > (no 'W' or 'w'), octal escapes must have exactly 3 octal digits and > hex escapes must have exactly 2 hex digits. In WIDECHAR and wide > TEXT literals, octal escapes must have exactly 6 and hex escapes > exactly 4. I've always thought that octal and hexadecimal escapes should be self-delimiting. In the process of moving from 8- to 16-bit characters, the length of the escapes has changed, and we're going to hit it again when we implement the larger-than-16-bit Unicode charaters. In C, for strings, you can force early termination of an escape by ending the string with a quote, then a space, then starting a new string with another quote (since consecutive strings are implicitly concatenated, so you can write a really long string that doesn't fit on a line). At least, that's what I seem to remember. I haven't actually hacked this stuff for a long time. > > Note that character literals without/with the 'W' are of different > types, CHAR and WIDECHAR, respectively. For Text literals, both > forms have the same type TEXT, but the lexical formation rules > are different without/with the 'W'. Are we going to have to implement 'WW' to avoid retrocompatibility problems? -- hendrik From jay.krell at cornell.edu Wed Jan 7 14:36:20 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 7 Jan 2009 13:36:20 +0000 Subject: [M3devel] duplication between compiler, m3makefile, and libraries; cross build easing Message-ID: duplication between compiler, m3makefile, and libraries. I propose that there should be reduced or no duplicationamong the compiler, m3makefile, and libraries. I propose that the compiler reveal (some) of what it knows. For example, m3makefile shall not specify WORD_SIZE.The compiler should.Granted, this buys very little. m3makefile shall not contain tables identifiying endianness.Compiler shall defined TARGET_ENDIAN to "BIG" or "LITTLE",or perhaps "big" or "little".Granted, this buys very little. Libraries shall not define jumpbuf, in a sense.Compile shall define, something like: TARGET_JUMPBUF_ELEMENT = "INTEGER" or "LONGINT". aka jmpbuf alignment. TARGET_JUMPBUF_SIZE = a decimal integer. Leaving library to say: TYPE jmpbuf = ARRAY [1..size] OF element which m3makefile shall produce. or perhaps even compiler shall inject the type itself,as it injects a few things like INTERFACE Word functions. or compiler shall define TARGET_JUMPBUF_ALIGN = 32 or 64,and TARGET_JUMPBUF_SIZE in bytesleaving m3makefile to map 32 to Ctypes.int and 64 to LONGINT itself. The jumpbuf size/align bothers me more than word size and endianness.Word size and endianness are more widely known to humans I think.Endianness and word size are usually fairly obvious, thoughnot 100%. I didn't know the endianness of e.g. 88k, vax, and the historicallyterse names don't make it obvious. However, let me not confuse "jumpbuf" with "Thread.State" or such.Assume user threads stops using setjmp/longjmp and modifyor generalize proposal accordingly. Wonder if exception handling should use set/get/make/swapcontext also??Assume jumpbuf might remain on some platforms? ? As well, one should be able to specify m3config on the command line.One should be able to specify target on the command line.Compiler shall take specified target and search /somehow/ for the right config file.Perhaps in path to cm3\..\config\target.Don't probe like crazy -- not like I have it coded in Quake currently.That really bites when there is more than one, and you edit the wrong one. Probably something like, probe for path to cm3\..\config\target. but if defined $CM3_CONFIG_DIRECTORY, search instead $CM3_CONFIG_DIRECTORY\target.however this is perhaps colon or semicolon delimited, so maybe CM3_CONFIG_PATH.(In particular, I have nearly all my config files in m3-sys/cminstall/src/config-no-install,except NT386, which I'd really like to move, but will probably break something anddoesn't seem important). Reasonable ideas? Personally what I do is my Python scripts accept a target name anywhere on thecommand line, and if present, they set $M3CONFIG.So I have what I want via python already.You know, kind of a successful (imho) prototype, that should perhaps be elevatedinto the "real" stuff? You know, make it easier and easier to contruct cross-capable installations,where switching targets is changing environment variables and/or command lines,and not editing/copying files. If there isn't already, there should be a mode that doesn't run cm3cg.And possibly can still ship.That way /any/ system can do a bunch of cross-build "checking".And the file system layout for creating a "boot" archive becomesabout the same as the layout of a "real" system. Not like what I use -- I use one flat directory, since Modula-3 requires that every..basically ever .i3, .m3, .o file have a unique name. (.i3 and .m3 can clash with each other, once each, that's it). - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jan 7 15:34:12 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 7 Jan 2009 14:34:12 +0000 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: <20090103011227.vgpfs347400088sg@mail.elegosoft.com> References: <20090103011227.vgpfs347400088sg@mail.elegosoft.com> Message-ID: I looked into this a bit..and I think it's actually pretty easy.It hardly churns the code even. I have other things I want to do first. In the meantime, specify the directive?There are actually a large number of subtle options. Can I ask for any of n libraries -- NT, pthreads, user threads? setjmp vs. context? Or is it just a boolean, user vs. kernel? Is the option to "favor" or "require" a certain library? Can I set it on libraries or only programs? What if the requests clash? Is it "Favor" or "Require"? Is it a function call or setting a global variable? I favor function call, but TARGET, WORD_SIZE, BUILD_DIR establish the other precedent, and either can work. Is it flags in the moduleinfo like incgc, gengc, or separate data that there is just one of in RTLinker? Probably separate data, unless it is allowed in libraries. What are the names of the libraries? "posix" and "pthreads" ? "user" and "kernel" ? "true" and "false" (or vice versa) ? Should NT implement user threads, using fibers? Presumably it works with both standalone and shared/dynamic programs. Presumably it is ok to always bloat up m3core.dll with both libraries. Presumably it is ok to have everyone pay a teeny tiny perf. That is, there is a microscopic dispatching layer, that everyone ends up going through, not chosing to link in one library or the other. And as part of this, whenever it happens, can we bump up the minimum bootstrap to a version that includes SchedulerPosix.DoesWaitPidYield()? Or does it become VAR Scheduler.UsingKerneThreads? (no, it should be a function; but naming matter remains). (ie. as I said, the decision currently is baked into m3core.dll, but now it is also baked into sysutils.dll, but these should change together; m3core.dll should manage the knowledge). - Jay> Date: Sat, 3 Jan 2009 01:12:27 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] dynamic chose between user/kernel threads?> > An option to cm3 or a quake directive to use in the m3makefiles> would suffice in my opinion (and be a great improvement).> > Olaf> > Quoting Jay :> > >> > Should the user/kernel thread chose be available:> >> >> > On the command line to a Modula-3 executable (or even an executable > > where main is in another language, but which static or dynamic > > Modula-3 libs are used)?> >> >> > Via a quake directive when building programs?> >> >> > You know, imagine you have a bunch of Modula-3 programs and some but > > not all use a very large number of threads and benefit from > > userthreads.> >> >> > Currently the chose is locked into m3core when it is built.> >> >> > - Jay> > > -- > Olaf -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Wed Jan 7 18:32:24 2009 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 07 Jan 2009 11:32:24 -0600 Subject: [M3devel] Widechars In-Reply-To: <20090108061355.GA2554@topoi.pooq.com> References: <4963C430.9020804@bellsouth.net> <49642094.7040400@wichita.edu> <20090108061355.GA2554@topoi.pooq.com> Message-ID: <4964E728.4050306@wichita.edu> hendrik at topoi.pooq.com wrote: > On Tue, Jan 06, 2009 at 09:25:08PM -0600, Rodney M. Bates wrote: >> Literals of type WIDECHAR are written, e.g. W'\x304A', note the 'W'. >> It makes them have type WIDECHAR and also enables the 16-bit escape >> sequences you are using. If it is a CHAR or plain TEXT literal >> (no 'W' or 'w'), octal escapes must have exactly 3 octal digits and >> hex escapes must have exactly 2 hex digits. In WIDECHAR and wide >> TEXT literals, octal escapes must have exactly 6 and hex escapes >> exactly 4. > > I've always thought that octal and hexadecimal escapes should be > self-delimiting. In the process of moving from 8- to 16-bit characters, > the length of the escapes has changed, and we're going to hit it again > when we implement the larger-than-16-bit Unicode charaters. > > In C, for strings, you can force early termination of an escape by > ending the string with a quote, then a space, then starting a new string > with another quote (since consecutive strings are implicitly > concatenated, so you can write a really long string that doesn't fit on > a line). At least, that's what I seem to remember. I haven't actually > hacked this stuff for a long time. This would be easy to implement, wouldn't break any existing code, and concatenating the fragments without an explicit '&' operator between would not suffer from ambiguity over whether the programmer expected runtime concatenation. I have liked this facility in C for long strings, just because I find wrapped long lines both very difficult to read and ugly. We could also easily make escapes prematurely terminated by a closing quote legal, again without breaking any existing code, which might be occasionally useful. However, if somebody wants to put a lot of escape-specified characters in a row in a TEXT literal, and not have to give every one all the most significant digits, terminating with a closing quote, then starting another literal would make things even more pedantic than they are. I have been thinking of a new set of escape letters (like the 'x', that immediately follow the backslash) that can be given independently of the 'W', and each one implies the base and number of digits. In theory, this could break existing code, if somebody had already redundantly escaped one of these new escape letters. This seems rather unlikely to have happened. > >> Note that character literals without/with the 'W' are of different >> types, CHAR and WIDECHAR, respectively. For Text literals, both >> forms have the same type TEXT, but the lexical formation rules >> are different without/with the 'W'. > > Are we going to have to implement 'WW' to avoid retrocompatibility > problems? > > -- hendrik Rodney Bates From hendrik at topoi.pooq.com Thu Jan 8 12:55:30 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 8 Jan 2009 06:55:30 -0500 Subject: [M3devel] Widechars In-Reply-To: <4964E728.4050306@wichita.edu> References: <4963C430.9020804@bellsouth.net> <49642094.7040400@wichita.edu> <20090108061355.GA2554@topoi.pooq.com> <4964E728.4050306@wichita.edu> Message-ID: <20090108115529.GA3157@topoi.pooq.com> On Wed, Jan 07, 2009 at 11:32:24AM -0600, Rodney M. Bates wrote: > hendrik at topoi.pooq.com wrote: > >On Tue, Jan 06, 2009 at 09:25:08PM -0600, Rodney M. Bates wrote: > >>Literals of type WIDECHAR are written, e.g. W'\x304A', note the 'W'. > >>It makes them have type WIDECHAR and also enables the 16-bit escape > >>sequences you are using. If it is a CHAR or plain TEXT literal > >>(no 'W' or 'w'), octal escapes must have exactly 3 octal digits and > >>hex escapes must have exactly 2 hex digits. In WIDECHAR and wide > >>TEXT literals, octal escapes must have exactly 6 and hex escapes > >>exactly 4. > > > >I've always thought that octal and hexadecimal escapes should be > >self-delimiting. In the process of moving from 8- to 16-bit characters, > >the length of the escapes has changed, and we're going to hit it again > >when we implement the larger-than-16-bit Unicode charaters. > > > >In C, for strings, you can force early termination of an escape by > >ending the string with a quote, then a space, then starting a new string > >with another quote (since consecutive strings are implicitly > >concatenated, so you can write a really long string that doesn't fit on > >a line). At least, that's what I seem to remember. I haven't actually > >hacked this stuff for a long time. > > This would be easy to implement, wouldn't break any existing code, and > concatenating the fragments without an explicit '&' operator between > would not suffer from ambiguity over whether the programmer expected > runtime concatenation. I have liked this facility in C for long strings, > just because I find wrapped long lines both very difficult to read and > ugly. In C you don't have a concatenation operator. I guess compile-time concatenation does really have different semantics from run-time, in the sense that compile-time gives you just one copy of the string, and run-time gives you a new one every time. > > We could also easily make escapes prematurely terminated by a closing > quote legal, again without breaking any existing code, which might be > occasionally useful. Of course, escapes could also be terminated by the backslash of the next escape. I don't like this as much as an explicit terminator. > > However, if somebody wants to put a lot of escape-specified characters > in a row in a TEXT literal, and not have to give every one all the > most significant digits, terminating with a closing quote, then > starting another literal would make things even more pedantic than > they are. Well, you could choose a character that does nothing but terminate an escape. Then you wouldn't have to start a new string. But it would break existing code that happens to have that character after a string. > > I have been thinking of a new set of escape letters (like the 'x', > that immediately follow the backslash) that can be given independently > of the 'W', and each one implies the base and number of digits. In > theory, this could break existing code, if somebody had already > redundantly escaped one of these new escape letters. This seems rather > unlikely to have happened. > > > > >>Note that character literals without/with the 'W' are of different > >>types, CHAR and WIDECHAR, respectively. For Text literals, both > >>forms have the same type TEXT, but the lexical formation rules > >>are different without/with the 'W'. > > > >Are we going to have to implement 'WW' to avoid retrocompatibility > >problems? > > > >-- hendrik > > Rodney Bates > > From hosking at cs.purdue.edu Thu Jan 8 03:46:58 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 8 Jan 2009 13:46:58 +1100 Subject: [M3devel] duplication between compiler, m3makefile, and libraries; cross build easing In-Reply-To: References: Message-ID: Why would the compiler know anything about jmpbuf in general? (Yes, I know it is used for exception handling). I would prefer that we had table-based exception handling as on SOLgnu for all targets, but that depends on support for stack unwinding for each target. I would hate for the compiler to inject a type for something like jmpbuf which is an *internal* detail of the exceptions implementation rather than a language-defined type. Also, there are advantages in the current approach, which decouples communication of information amongst the tool-chain components. Why would you use setcontext, getcontext, etc. for exception handling. setjmp/longjmp are perfectly adequate to the task. setcontext/getcontext are intended for user-thread switching, etc. I think you'll find there already is a compiler mode that does not invoke cm3cg. 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 8 Jan 2009, at 00:36, Jay wrote: > duplication between compiler, m3makefile, and libraries. > > > I propose that there should be reduced or no duplication > among the compiler, m3makefile, and libraries. > > > I propose that the compiler reveal (some) of what it knows. > > > For example, m3makefile shall not specify WORD_SIZE. > The compiler should. > Granted, this buys very little. > > > m3makefile shall not contain tables identifiying endianness. > Compiler shall defined TARGET_ENDIAN to "BIG" or "LITTLE", > or perhaps "big" or "little". > Granted, this buys very little. > > > Libraries shall not define jumpbuf, in a sense. > Compile shall define, something like: > TARGET_JUMPBUF_ELEMENT = "INTEGER" or "LONGINT". > aka jmpbuf alignment. > TARGET_JUMPBUF_SIZE = a decimal integer. > Leaving library to say: > TYPE jmpbuf = ARRAY [1..size] OF element > which m3makefile shall produce. > > > or perhaps even compiler shall inject the type itself, > as it injects a few things like INTERFACE Word functions. > > > or compiler shall define TARGET_JUMPBUF_ALIGN = 32 or 64, > and TARGET_JUMPBUF_SIZE in bytes > leaving m3makefile to map 32 to Ctypes.int and 64 to LONGINT itself. > > > The jumpbuf size/align bothers me more than word size and endianness. > Word size and endianness are more widely known to humans I think. > Endianness and word size are usually fairly obvious, though > not 100%. I didn't know the endianness of e.g. 88k, vax, and the > historically > terse names don't make it obvious. > > > However, let me not confuse "jumpbuf" with "Thread.State" or such. > Assume user threads stops using setjmp/longjmp and modify > or generalize proposal accordingly. > > Wonder if exception handling should use set/get/make/swapcontext > also?? > Assume jumpbuf might remain on some platforms? > > ? > > As well, one should be able to specify m3config on the command line. > One should be able to specify target on the command line. > Compiler shall take specified target and search /somehow/ for the > right config file. > Perhaps in path to cm3\..\config\target. > Don't probe like crazy -- not like I have it coded in Quake currently. > That really bites when there is more than one, and you edit the > wrong one. > > Probably something like, > probe for path to cm3\..\config\target. > > but if defined $CM3_CONFIG_DIRECTORY, search instead > $CM3_CONFIG_DIRECTORY\target. > however this is perhaps colon or semicolon delimited, so maybe > CM3_CONFIG_PATH. > (In particular, I have nearly all my config files in m3-sys/ > cminstall/src/config-no-install, > except NT386, which I'd really like to move, but will probably break > something and > doesn't seem important). > > Reasonable ideas? > > > Personally what I do is my Python scripts accept a target name > anywhere on the > command line, and if present, they set $M3CONFIG. > So I have what I want via python already. > You know, kind of a successful (imho) prototype, that should perhaps > be elevated > into the "real" stuff? > > > You know, make it easier and easier to contruct cross-capable > installations, > where switching targets is changing environment variables and/or > command lines, > and not editing/copying files. > > > If there isn't already, there should be a mode that doesn't run cm3cg. > And possibly can still ship. > That way /any/ system can do a bunch of cross-build "checking". > And the file system layout for creating a "boot" archive becomes > about the same as the layout of a "real" system. > Not like what I use -- I use one flat directory, since Modula-3 > requires that every..basically ever .i3, .m3, .o file have a unique > name. > (.i3 and .m3 can clash with each other, once each, that's it). > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jan 8 03:51:15 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 8 Jan 2009 13:51:15 +1100 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: References: <20090103011227.vgpfs347400088sg@mail.elegosoft.com> Message-ID: <44664E56-D816-4A94-AD2E-96A0DB383DDF@cs.purdue.edu> Jay, perhaps you can provide some context and motivation for your proposals. I am unable to evaluate your proposals in the form of a simple laundry-list. On 8 Jan 2009, at 01:34, Jay wrote: > I looked into this a bit..and I think it's actually pretty easy. > It hardly churns the code even. > > > I have other things I want to do first. > > > In the meantime, specify the directive? > There are actually a large number of subtle options. > > > Can I ask for any of n libraries -- NT, pthreads, user threads? > setjmp vs. context? Or is it just a boolean, user vs. kernel? > > > Is the option to "favor" or "require" a certain library? > > > Can I set it on libraries or only programs? > What if the requests clash? > > > Is it "Favor" or "Require"? > Is it a function call or setting a global variable? > I favor function call, but TARGET, WORD_SIZE, BUILD_DIR establish > the other precedent, > and either can work. > > Is it flags in the moduleinfo like incgc, gengc, or separate data that > there is just one of in RTLinker? Probably separate data, unless it > is allowed in libraries. > > > What are the names of the libraries? > "posix" and "pthreads" ? > "user" and "kernel" ? > "true" and "false" (or vice versa) ? > > > Should NT implement user threads, using fibers? > > > Presumably it works with both standalone and shared/dynamic programs. > Presumably it is ok to always bloat up m3core.dll with both libraries. > Presumably it is ok to have everyone pay a teeny tiny perf. > That is, there is a microscopic dispatching layer, that everyone > ends up going through, not chosing to link in one library or the > other. > > > And as part of this, whenever it happens, can we bump up the minimum > bootstrap to a version that includes > SchedulerPosix.DoesWaitPidYield()? > Or does it become VAR Scheduler.UsingKerneThreads? > (no, it should be a function; but naming matter remains). > > > (ie. as I said, the decision currently is baked into m3core.dll, but > now it is also baked into sysutils.dll, but these should change > together; > m3core.dll should manage the knowledge). > > > - Jay > > > > Date: Sat, 3 Jan 2009 01:12:27 +0100 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] dynamic chose between user/kernel threads? > > > > An option to cm3 or a quake directive to use in the m3makefiles > > would suffice in my opinion (and be a great improvement). > > > > Olaf > > > > Quoting Jay : > > > > > > > > Should the user/kernel thread chose be available: > > > > > > > > > On the command line to a Modula-3 executable (or even an > executable > > > where main is in another language, but which static or dynamic > > > Modula-3 libs are used)? > > > > > > > > > Via a quake directive when building programs? > > > > > > > > > You know, imagine you have a bunch of Modula-3 programs and some > but > > > not all use a very large number of threads and benefit from > > > userthreads. > > > > > > > > > Currently the chose is locked into m3core when it is built. > > > > > > > > > - Jay > > > > > > -- > > Olaf -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 8 04:10:49 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 8 Jan 2009 03:10:49 +0000 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: <44664E56-D816-4A94-AD2E-96A0DB383DDF@cs.purdue.edu> References: <20090103011227.vgpfs347400088sg@mail.elegosoft.com> <44664E56-D816-4A94-AD2E-96A0DB383DDF@cs.purdue.edu> Message-ID: Olaf understood the point (I think). :) Some programs, people say, and I believe, run "better" (faster, without running out of address space) with user threads instead of kernel threads. On systems that have both. A good example might be a program that needs lots of threads and therefore small stacks, and the kernel threads, due to code below the Modula-3 runtime, might force fairly large stacks. (Such a program might have to adjust thread size differently for different threads, and only call into the underlying system on threads with larger stacks.) It might be nice for such programs to be able to mandate or request (two slightly different things) that the user thread library be used by them, even if the platform's default is to use kernel threads. The only minor detail then is, how to express the request, and the precise meaning. It is a request or a mandate? As well, if the issue is address space, sholud there a "built in" way to only make the request on 32bit platforms, or should uses manually say if equal (WORD_SIZE, "32BITS")? Is it a boolean or an enum? Cygwin might conceivably get pthreads support (Cygwin has it, but Modula-3/Cygwin does not). Therefore, is the choice among "posix" threads, "pthreads" and "NT" threads? Or just user vs. kernel? I think the "important" part here is easy to implement. But again.. The easier straightforward implementation always links both pieces of code in and makes a choice early in startup as to which to use, either setting a boolean, or an enum, or a pointer to a record of function pointers. This means that people that don't care to ever use user threads pay a small price, in code bloat and probably in a few extra instructions per certain functions. This is probably ok. However if that was not ok, the choice could be made at link time and only be supported for standalone programs. - Jay CC: wagner at elegosoft.com; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] dynamic chose between user/kernel threads?Date: Thu, 8 Jan 2009 13:51:15 +1100 Jay, perhaps you can provide some context and motivation for your proposals. I am unable to evaluate your proposals in the form of a simple laundry-list. On 8 Jan 2009, at 01:34, Jay wrote: I looked into this a bit..and I think it's actually pretty easy.It hardly churns the code even. I have other things I want to do first. In the meantime, specify the directive?There are actually a large number of subtle options. Can I ask for any of n libraries -- NT, pthreads, user threads? setjmp vs. context? Or is it just a boolean, user vs. kernel? Is the option to "favor" or "require" a certain library? Can I set it on libraries or only programs? What if the requests clash? Is it "Favor" or "Require"?Is it a function call or setting a global variable?I favor function call, but TARGET, WORD_SIZE, BUILD_DIR establish the other precedent,and either can work. Is it flags in the moduleinfo like incgc, gengc, or separate data thatthere is just one of in RTLinker? Probably separate data, unless it is allowed in libraries. What are the names of the libraries? "posix" and "pthreads" ? "user" and "kernel" ? "true" and "false" (or vice versa) ? Should NT implement user threads, using fibers? Presumably it works with both standalone and shared/dynamic programs.Presumably it is ok to always bloat up m3core.dll with both libraries.Presumably it is ok to have everyone pay a teeny tiny perf. That is, there is a microscopic dispatching layer, that everyone ends up going through, not chosing to link in one library or the other. And as part of this, whenever it happens, can we bump up the minimumbootstrap to a version that includes SchedulerPosix.DoesWaitPidYield()?Or does it become VAR Scheduler.UsingKerneThreads?(no, it should be a function; but naming matter remains). (ie. as I said, the decision currently is baked into m3core.dll, butnow it is also baked into sysutils.dll, but these should change together;m3core.dll should manage the knowledge). - Jay> Date: Sat, 3 Jan 2009 01:12:27 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] dynamic chose between user/kernel threads?> > An option to cm3 or a quake directive to use in the m3makefiles> would suffice in my opinion (and be a great improvement).> > Olaf> > Quoting Jay :> > >> > Should the user/kernel thread chose be available:> >> >> > On the command line to a Modula-3 executable (or even an executable > > where main is in another language, but which static or dynamic > > Modula-3 libs are used)?> >> >> > Via a quake directive when building programs?> >> >> > You know, imagine you have a bunch of Modula-3 programs and some but > > not all use a very large number of threads and benefit from > > userthreads.> >> >> > Currently the chose is locked into m3core when it is built.> >> >> > - Jay> > > -- > Olaf -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 8 04:44:40 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 8 Jan 2009 03:44:40 +0000 Subject: [M3devel] duplication between compiler, m3makefile, and libraries; cross build easing In-Reply-To: References: Message-ID: Is table-based exception handling close to being feasible on many targets? I figured it was mostly a lost cause but wouldn't mind being wrong. Perhaps the evolution of gcc has made it much easier these days? You know, what with Ada and C++ exception handling support being whatever it is? Imho target-specific information should be kept to a minimum kept to a minimum number of places/files perhaps kept to a minimum distance from other target-specific information (places/files) and like other information, not duplicated If jumpbuf wasn't used by the compiler, then my position weakens. However currently the size and alignment of jumpbuf is duplicated. And endianness is duplicated. And wordsize is duplicated. I wouldn't mind if jumpbuf was only, say, Csetjmp.i3, and wordsize was only in the config file. But duplication bugs me. > why context for exception handling vs. setjmp/longjmp. Just my ignorant questioning. If setjmp/longjmp suffice, ok. They are just similar and perhaps if switch one, switch the other. I realize that longjmp can only officially be called once per setjmp, and that contexts are "reusable" (can be swapped an arbitrary number of times). - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Thu, 8 Jan 2009 13:46:58 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] duplication between compiler, m3makefile, and libraries; cross build easingWhy would the compiler know anything about jmpbuf in general? (Yes, I know it is used for exception handling). I would prefer that we had table-based exception handling as on SOLgnu for all targets, but that depends on support for stack unwinding for each target. I would hate for the compiler to inject a type for something like jmpbuf which is an *internal* detail of the exceptions implementation rather than a language-defined type. Also, there are advantages in the current approach, which decouples communication of information amongst the tool-chain components. Why would you use setcontext, getcontext, etc. for exception handling. setjmp/longjmp are perfectly adequate to the task. setcontext/getcontext are intended for user-thread switching, etc. I think you'll find there already is a compiler mode that does not invoke cm3cg. 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 8 Jan 2009, at 00:36, Jay wrote: duplication between compiler, m3makefile, and libraries. I propose that there should be reduced or no duplicationamong the compiler, m3makefile, and libraries. I propose that the compiler reveal (some) of what it knows. For example, m3makefile shall not specify WORD_SIZE.The compiler should.Granted, this buys very little. m3makefile shall not contain tables identifiying endianness.Compiler shall defined TARGET_ENDIAN to "BIG" or "LITTLE",or perhaps "big" or "little".Granted, this buys very little. Libraries shall not define jumpbuf, in a sense.Compile shall define, something like: TARGET_JUMPBUF_ELEMENT = "INTEGER" or "LONGINT". aka jmpbuf alignment. TARGET_JUMPBUF_SIZE = a decimal integer.Leaving library to say: TYPE jmpbuf = ARRAY [1..size] OF elementwhich m3makefile shall produce. or perhaps even compiler shall inject the type itself,as it injects a few things like INTERFACE Word functions. or compiler shall define TARGET_JUMPBUF_ALIGN = 32 or 64,and TARGET_JUMPBUF_SIZE in bytesleaving m3makefile to map 32 to Ctypes.int and 64 to LONGINT itself. The jumpbuf size/align bothers me more than word size and endianness.Word size and endianness are more widely known to humans I think.Endianness and word size are usually fairly obvious, thoughnot 100%. I didn't know the endianness of e.g. 88k, vax, and the historicallyterse names don't make it obvious. However, let me not confuse "jumpbuf" with "Thread.State" or such.Assume user threads stops using setjmp/longjmp and modifyor generalize proposal accordingly.Wonder if exception handling should use set/get/make/swapcontext also??Assume jumpbuf might remain on some platforms? ?As well, one should be able to specify m3config on the command line.One should be able to specify target on the command line.Compiler shall take specified target and search /somehow/ for the right config file.Perhaps in path to cm3\..\config\target.Don't probe like crazy -- not like I have it coded in Quake currently.That really bites when there is more than one, and you edit the wrong one.Probably something like, probe for path to cm3\..\config\target.but if defined $CM3_CONFIG_DIRECTORY, search instead $CM3_CONFIG_DIRECTORY\target.however this is perhaps colon or semicolon delimited, so maybe CM3_CONFIG_PATH.(In particular, I have nearly all my config files in m3-sys/cminstall/src/config-no-install,except NT386, which I'd really like to move, but will probably break something anddoesn't seem important).Reasonable ideas? Personally what I do is my Python scripts accept a target name anywhere on thecommand line, and if present, they set $M3CONFIG.So I have what I want via python already.You know, kind of a successful (imho) prototype, that should perhaps be elevatedinto the "real" stuff? You know, make it easier and easier to contruct cross-capable installations,where switching targets is changing environment variables and/or command lines,and not editing/copying files. If there isn't already, there should be a mode that doesn't run cm3cg.And possibly can still ship.That way /any/ system can do a bunch of cross-build "checking".And the file system layout for creating a "boot" archive becomesabout the same as the layout of a "real" system. Not like what I use -- I use one flat directory, since Modula-3 requires that every..basically ever .i3, .m3, .o file have a unique name. (.i3 and .m3 can clash with each other, once each, that's it). - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 8 04:50:54 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 8 Jan 2009 03:50:54 +0000 Subject: [M3devel] duplication between compiler, m3makefile, and libraries; cross build easing In-Reply-To: References: Message-ID: > I would hate for the compiler to inject a type for > something like jmpbuf which is an *internal* detail > of the exceptions implementation rather than a language-defined type The compiler and runtime are unavoidably somewhat interdependent on each other. You know, that the compiler generates calls to RTHooks.i3. If you want the ability to retarget the compiler to a slightly different runtime, then the runtime should inform the compiler, and not the other way around, but they remain interdepenent. There are similar issues here probably regarding RT0.i3 and RTBuiltin.c. I guess you don't want the compiler to clutter the global type/modulespace, as a communications channel, to share information. But I think language and library are somewhat murky. Is INTERFACE Word in the language or the library? Is LOCK language or library? These are both in-between. INTERFACE Word is in the "standard library", and I think it is only in the compiler as an implementation specific optimization. LOCK is necessarily in both. - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] duplication between compiler, m3makefile, and libraries; cross build easingDate: Thu, 8 Jan 2009 03:44:40 +0000 Is table-based exception handling close to being feasible on many targets?I figured it was mostly a lost cause but wouldn't mind being wrong.Perhaps the evolution of gcc has made it much easier these days?You know, what with Ada and C++ exception handling support being whatever it is? Imho target-specific information should be kept to a minimum kept to a minimum number of places/files perhaps kept to a minimum distance from other target-specific information (places/files) and like other information, not duplicated If jumpbuf wasn't used by the compiler, then my position weakens.However currently the size and alignment of jumpbuf is duplicated.And endianness is duplicated. And wordsize is duplicated.I wouldn't mind if jumpbuf was only, say, Csetjmp.i3, and wordsize was only in the config file.But duplication bugs me. > why context for exception handling vs. setjmp/longjmp. Just my ignorant questioning. If setjmp/longjmp suffice, ok.They are just similar and perhaps if switch one, switch the other.I realize that longjmp can only officially be called once per setjmp, and that contexts are "reusable" (can be swapped an arbitrary number of times). - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Thu, 8 Jan 2009 13:46:58 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] duplication between compiler, m3makefile, and libraries; cross build easingWhy would the compiler know anything about jmpbuf in general? (Yes, I know it is used for exception handling). I would prefer that we had table-based exception handling as on SOLgnu for all targets, but that depends on support for stack unwinding for each target. I would hate for the compiler to inject a type for something like jmpbuf which is an *internal* detail of the exceptions implementation rather than a language-defined type. Also, there are advantages in the current approach, which decouples communication of information amongst the tool-chain components. Why would you use setcontext, getcontext, etc. for exception handling. setjmp/longjmp are perfectly adequate to the task. setcontext/getcontext are intended for user-thread switching, etc. I think you'll find there already is a compiler mode that does not invoke cm3cg. 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 8 Jan 2009, at 00:36, Jay wrote: duplication between compiler, m3makefile, and libraries. I propose that there should be reduced or no duplicationamong the compiler, m3makefile, and libraries. I propose that the compiler reveal (some) of what it knows. For example, m3makefile shall not specify WORD_SIZE.The compiler should.Granted, this buys very little. m3makefile shall not contain tables identifiying endianness.Compiler shall defined TARGET_ENDIAN to "BIG" or "LITTLE",or perhaps "big" or "little".Granted, this buys very little. Libraries shall not define jumpbuf, in a sense.Compile shall define, something like: TARGET_JUMPBUF_ELEMENT = "INTEGER" or "LONGINT". aka jmpbuf alignment. TARGET_JUMPBUF_SIZE = a decimal integer.Leaving library to say: TYPE jmpbuf = ARRAY [1..size] OF elementwhich m3makefile shall produce. or perhaps even compiler shall inject the type itself,as it injects a few things like INTERFACE Word functions. or compiler shall define TARGET_JUMPBUF_ALIGN = 32 or 64,and TARGET_JUMPBUF_SIZE in bytesleaving m3makefile to map 32 to Ctypes.int and 64 to LONGINT itself. The jumpbuf size/align bothers me more than word size and endianness.Word size and endianness are more widely known to humans I think.Endianness and word size are usually fairly obvious, thoughnot 100%. I didn't know the endianness of e.g. 88k, vax, and the historicallyterse names don't make it obvious. However, let me not confuse "jumpbuf" with "Thread.State" or such.Assume user threads stops using setjmp/longjmp and modifyor generalize proposal accordingly.Wonder if exception handling should use set/get/make/swapcontext also??Assume jumpbuf might remain on some platforms? ?As well, one should be able to specify m3config on the command line.One should be able to specify target on the command line.Compiler shall take specified target and search /somehow/ for the right config file.Perhaps in path to cm3\..\config\target.Don't probe like crazy -- not like I have it coded in Quake currently.That really bites when there is more than one, and you edit the wrong one.Probably something like, probe for path to cm3\..\config\target.but if defined $CM3_CONFIG_DIRECTORY, search instead $CM3_CONFIG_DIRECTORY\target.however this is perhaps colon or semicolon delimited, so maybe CM3_CONFIG_PATH.(In particular, I have nearly all my config files in m3-sys/cminstall/src/config-no-install,except NT386, which I'd really like to move, but will probably break something anddoesn't seem important).Reasonable ideas? Personally what I do is my Python scripts accept a target name anywhere on thecommand line, and if present, they set $M3CONFIG.So I have what I want via python already.You know, kind of a successful (imho) prototype, that should perhaps be elevatedinto the "real" stuff? You know, make it easier and easier to contruct cross-capable installations,where switching targets is changing environment variables and/or command lines,and not editing/copying files. If there isn't already, there should be a mode that doesn't run cm3cg.And possibly can still ship.That way /any/ system can do a bunch of cross-build "checking".And the file system layout for creating a "boot" archive becomesabout the same as the layout of a "real" system. Not like what I use -- I use one flat directory, since Modula-3 requires that every..basically ever .i3, .m3, .o file have a unique name. (.i3 and .m3 can clash with each other, once each, that's it). - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jan 8 05:58:38 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 8 Jan 2009 15:58:38 +1100 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: References: <20090103011227.vgpfs347400088sg@mail.elegosoft.com> <44664E56-D816-4A94-AD2E-96A0DB383DDF@cs.purdue.edu> Message-ID: <234B3116-4C98-470B-9929-3E2AC72D67DC@cs.purdue.edu> On 8 Jan 2009, at 14:10, Jay wrote: > Olaf understood the point (I think). :) > > Some programs, people say, and I believe, run "better" (faster, > without running out of address space) with user threads instead of > kernel threads. Is this still true for modern kernel thread systems? > On systems that have both. > A good example might be a program that needs lots of threads and > therefore small stacks, and the kernel threads, due to code below > the Modula-3 runtime, might force fairly large stacks. (Such a > program might have to adjust thread size differently for different > threads, and only call into the underlying system on threads with > larger stacks.) In a systems programming language like Modula-3 shouldn't threads have a relationship to the system? > It might be nice for such programs to be able to mandate or request > (two slightly different things) that the user thread library be used > by them, even if the platform's default is to use kernel threads. This will need to be a link-time distinction. I would hate to have both kernel and user thread code live in the same compiled run-time system. > The only minor detail then is, how to express the request, and the > precise meaning. > It is a request or a mandate? I see no problem with factoring out the threads subsystem as a separate library and linking accordingly. > As well, if the issue is address space, sholud there a "built in" > way to only make the request on 32bit platforms, or should uses > manually say if equal (WORD_SIZE, "32BITS")? > > Is it a boolean or an enum? > Cygwin might conceivably get pthreads support (Cygwin has it, but > Modula-3/Cygwin does not). > Therefore, is the choice among "posix" threads, "pthreads" and "NT" > threads? > Or just user vs. kernel? I would argue for user vs. kernel. > I think the "important" part here is easy to implement. > But again.. And managing the state-space explosion that multiple choices might entail. I would like to avoid that. > The easier straightforward implementation always links both pieces > of code in and makes a choice early in startup as to which to use, > either setting a boolean, or an enum, or a pointer to a record of > function pointers. This means that people that don't care to ever > use user threads pay a small price, in code bloat and probably in a > few extra instructions per certain functions. This is probably ok. I am not so sure, since it would entail some fairly low-level and expensive decisions that would best instead be done at link-time. > However if that was not ok, the choice could be made at link time > and only be supported for standalone programs. Actually, for non-standalone (dynamically-linked) code we could make the choice at dynamic load time using the OS's support for dynamic library choice. I note that Solaris (but not Solaris Modula-3) currently lets dynamically linked C programs choose among 3 different threads implementations dynamically. > > > - Jay > > > > > CC: wagner at elegosoft.com; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] dynamic chose between user/kernel threads? > Date: Thu, 8 Jan 2009 13:51:15 +1100 > > > Jay, perhaps you can provide some context and motivation for your > proposals. I am unable to evaluate your proposals in the form of a > simple laundry-list. > > On 8 Jan 2009, at 01:34, Jay wrote: > > I looked into this a bit..and I think it's actually pretty easy. > It hardly churns the code even. > > > I have other things I want to do first. > > > In the meantime, specify the directive? > There are actually a large number of subtle options. > > > Can I ask for any of n libraries -- NT, pthreads, user threads? > setjmp vs. context? Or is it just a boolean, user vs. kernel? > > > Is the option to "favor" or "require" a certain library? > > > Can I set it on libraries or only programs? > What if the requests clash? > > > Is it "Favor" or "Require"? > Is it a function call or setting a global variable? > I favor function call, but TARGET, WORD_SIZE, BUILD_DIR establish > the other precedent, > and either can work. > > Is it flags in the moduleinfo like incgc, gengc, or separate data that > there is just one of in RTLinker? Probably separate data, unless it > is allowed in libraries. > > > What are the names of the libraries? > "posix" and "pthreads" ? > "user" and "kernel" ? > "true" and "false" (or vice versa) ? > > > Should NT implement user threads, using fibers? > > > Presumably it works with both standalone and shared/dynamic programs. > Presumably it is ok to always bloat up m3core.dll with both libraries. > Presumably it is ok to have everyone pay a teeny tiny perf. > That is, there is a microscopic dispatching layer, that everyone > ends up going through, not chosing to link in one library or the > other. > > > And as part of this, whenever it happens, can we bump up the minimum > bootstrap to a version that includes > SchedulerPosix.DoesWaitPidYield()? > Or does it become VAR Scheduler.UsingKerneThreads? > (no, it should be a function; but naming matter remains). > > > (ie. as I said, the decision currently is baked into m3core.dll, but > now it is also baked into sysutils.dll, but these should change > together; > m3core.dll should manage the knowledge). > > > - Jay > > > > Date: Sat, 3 Jan 2009 01:12:27 +0100 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] dynamic chose between user/kernel threads? > > > > An option to cm3 or a quake directive to use in the m3makefiles > > would suffice in my opinion (and be a great improvement). > > > > Olaf > > > > Quoting Jay : > > > > > > > > Should the user/kernel thread chose be available: > > > > > > > > > On the command line to a Modula-3 executable (or even an > executable > > > where main is in another language, but which static or dynamic > > > Modula-3 libs are used)? > > > > > > > > > Via a quake directive when building programs? > > > > > > > > > You know, imagine you have a bunch of Modula-3 programs and some > but > > > not all use a very large number of threads and benefit from > > > userthreads. > > > > > > > > > Currently the chose is locked into m3core when it is built. > > > > > > > > > - Jay > > > > > > -- > > Olaf > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jan 8 06:03:51 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 8 Jan 2009 16:03:51 +1100 Subject: [M3devel] duplication between compiler, m3makefile, and libraries; cross build easing In-Reply-To: References: Message-ID: <41260DC6-BBA1-4628-BAEE-8482D4531EFA@cs.purdue.edu> On 8 Jan 2009, at 14:44, Jay wrote: > Is table-based exception handling close to being feasible on many > targets? We could make use of libunwind (http://www.nongnu.org/libunwind/) to do the unwinding and use the table-based scheme. I note that gcc already comes with a version of libunwind for some targets. > I figured it was mostly a lost cause but wouldn't mind being wrong. I hope not, since setjmp/longjmp is needlessly expensive. > Perhaps the evolution of gcc has made it much easier these days? > You know, what with Ada and C++ exception handling support being > whatever it is? Indeed. > Imho target-specific information should be > kept to a minimum > kept to a minimum number of places/files > perhaps kept to a minimum distance from other target-specific > information (places/files) > and like other information, not duplicated Yes, a laudable goal. > If jumpbuf wasn't used by the compiler, then my position weakens. > However currently the size and alignment of jumpbuf is duplicated. > And endianness is duplicated. And wordsize is duplicated. > I wouldn't mind if jumpbuf was only, say, Csetjmp.i3, and wordsize > was only in the config file. > But duplication bugs me. Indeed. > > why context for exception handling vs. setjmp/longjmp. > > Just my ignorant questioning. If setjmp/longjmp suffice, ok. > They are just similar and perhaps if switch one, switch the other. > I realize that longjmp can only officially be called once per > setjmp, and that contexts are "reusable" (can be swapped an > arbitrary number of times). Yes, that is the distinction -- I expect that has some impact on the underlying implementation and efficiency. > > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Thu, 8 Jan 2009 13:46:58 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] duplication between compiler, m3makefile, and > libraries; cross build easing > > Why would the compiler know anything about jmpbuf in general? (Yes, > I know it is used for exception handling). I would prefer that we > had table-based exception handling as on SOLgnu for all targets, but > that depends on support for stack unwinding for each target. I > would hate for the compiler to inject a type for something like > jmpbuf which is an *internal* detail of the exceptions > implementation rather than a language-defined type. Also, there are > advantages in the current approach, which decouples communication of > information amongst the tool-chain components. > > Why would you use setcontext, getcontext, etc. for exception > handling. setjmp/longjmp are perfectly adequate to the task. > setcontext/getcontext are intended for user-thread switching, etc. > > I think you'll find there already is a compiler mode that does not > invoke cm3cg. > > 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 8 Jan 2009, at 00:36, Jay wrote: > > duplication between compiler, m3makefile, and libraries. > > > I propose that there should be reduced or no duplication > among the compiler, m3makefile, and libraries. > > > I propose that the compiler reveal (some) of what it knows. > > > For example, m3makefile shall not specify WORD_SIZE. > The compiler should. > Granted, this buys very little. > > > m3makefile shall not contain tables identifiying endianness. > Compiler shall defined TARGET_ENDIAN to "BIG" or "LITTLE", > or perhaps "big" or "little". > Granted, this buys very little. > > > Libraries shall not define jumpbuf, in a sense. > Compile shall define, something like: > TARGET_JUMPBUF_ELEMENT = "INTEGER" or "LONGINT". > aka jmpbuf alignment. > TARGET_JUMPBUF_SIZE = a decimal integer. > Leaving library to say: > TYPE jmpbuf = ARRAY [1..size] OF element > which m3makefile shall produce. > > > or perhaps even compiler shall inject the type itself, > as it injects a few things like INTERFACE Word functions. > > > or compiler shall define TARGET_JUMPBUF_ALIGN = 32 or 64, > and TARGET_JUMPBUF_SIZE in bytes > leaving m3makefile to map 32 to Ctypes.int and 64 to LONGINT itself. > > > The jumpbuf size/align bothers me more than word size and endianness. > Word size and endianness are more widely known to humans I think. > Endianness and word size are usually fairly obvious, though > not 100%. I didn't know the endianness of e.g. 88k, vax, and the > historically > terse names don't make it obvious. > > > However, let me not confuse "jumpbuf" with "Thread.State" or such. > Assume user threads stops using setjmp/longjmp and modify > or generalize proposal accordingly. > > Wonder if exception handling should use set/get/make/swapcontext > also?? > Assume jumpbuf might remain on some platforms? > > ? > > As well, one should be able to specify m3config on the command line. > One should be able to specify target on the command line. > Compiler shall take specified target and search /somehow/ for the > right config file. > Perhaps in path to cm3\..\config\target. > Don't probe like crazy -- not like I have it coded in Quake currently. > That really bites when there is more than one, and you edit the > wrong one. > > Probably something like, > probe for path to cm3\..\config\target. > > but if defined $CM3_CONFIG_DIRECTORY, search instead > $CM3_CONFIG_DIRECTORY\target. > however this is perhaps colon or semicolon delimited, so maybe > CM3_CONFIG_PATH. > (In particular, I have nearly all my config files in m3-sys/ > cminstall/src/config-no-install, > except NT386, which I'd really like to move, but will probably break > something and > doesn't seem important). > > Reasonable ideas? > > > Personally what I do is my Python scripts accept a target name > anywhere on the > command line, and if present, they set $M3CONFIG. > So I have what I want via python already. > You know, kind of a successful (imho) prototype, that should perhaps > be elevated > into the "real" stuff? > > > You know, make it easier and easier to contruct cross-capable > installations, > where switching targets is changing environment variables and/or > command lines, > and not editing/copying files. > > > If there isn't already, there should be a mode that doesn't run cm3cg. > And possibly can still ship. > That way /any/ system can do a bunch of cross-build "checking". > And the file system layout for creating a "boot" archive becomes > about the same as the layout of a "real" system. > Not like what I use -- I use one flat directory, since Modula-3 > requires that every..basically ever .i3, .m3, .o file have a unique > name. > (.i3 and .m3 can clash with each other, once each, that's it). > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jan 8 06:05:43 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 8 Jan 2009 16:05:43 +1100 Subject: [M3devel] duplication between compiler, m3makefile, and libraries; cross build easing In-Reply-To: References: Message-ID: On 8 Jan 2009, at 14:50, Jay wrote: > > I would hate for the compiler to inject a type for > > something like jmpbuf which is an *internal* detail > > of the exceptions implementation rather than a language-defined > type > > The compiler and runtime are unavoidably somewhat interdependent on > each other. > You know, that the compiler generates calls to RTHooks.i3. Yes, of course they are, but we want to keep the interface between them as narrow as possible. > If you want the ability to retarget the compiler to a slightly > different runtime, then the runtime should > inform the compiler, and not the other way around, but they remain > interdepenent. Not sure how you would achieve that. > There are similar issues here probably regarding RT0.i3 and > RTBuiltin.c. Here be dragons... > I guess you don't want the compiler to clutter the global type/ > modulespace, as a communications channel, to share information. Precisely. > But I think language and library are somewhat murky. True. Java has a simple core language, but lots of powerful libraries. > Is INTERFACE Word in the language or the library? > Is LOCK language or library? > These are both in-between. > INTERFACE Word is in the "standard library", and I think it is only > in the compiler as an implementation specific optimization. LOCK is > necessarily in both. > > - Jay > > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] duplication between compiler, m3makefile, and > libraries; cross build easing > Date: Thu, 8 Jan 2009 03:44:40 +0000 > > Is table-based exception handling close to being feasible on many > targets? > I figured it was mostly a lost cause but wouldn't mind being wrong. > Perhaps the evolution of gcc has made it much easier these days? > You know, what with Ada and C++ exception handling support being > whatever it is? > > Imho target-specific information should be > kept to a minimum > kept to a minimum number of places/files > perhaps kept to a minimum distance from other target-specific > information (places/files) > and like other information, not duplicated > > > If jumpbuf wasn't used by the compiler, then my position weakens. > However currently the size and alignment of jumpbuf is duplicated. > And endianness is duplicated. And wordsize is duplicated. > I wouldn't mind if jumpbuf was only, say, Csetjmp.i3, and wordsize > was only in the config file. > But duplication bugs me. > > > why context for exception handling vs. setjmp/longjmp. > > Just my ignorant questioning. If setjmp/longjmp suffice, ok. > They are just similar and perhaps if switch one, switch the other. > I realize that longjmp can only officially be called once per > setjmp, and that contexts are "reusable" (can be swapped an > arbitrary number of times). > > - Jay > > > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Thu, 8 Jan 2009 13:46:58 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] duplication between compiler, m3makefile, and > libraries; cross build easing > > Why would the compiler know anything about jmpbuf in general? (Yes, > I know it is used for exception handling). I would prefer that we > had table-based exception handling as on SOLgnu for all targets, but > that depends on support for stack unwinding for each target. I > would hate for the compiler to inject a type for something like > jmpbuf which is an *internal* detail of the exceptions > implementation rather than a language-defined type. Also, there are > advantages in the current approach, which decouples communication of > information amongst the tool-chain components. > > > Why would you use setcontext, getcontext, etc. for exception > handling. setjmp/longjmp are perfectly adequate to the task. > setcontext/getcontext are intended for user-thread switching, etc. > > I think you'll find there already is a compiler mode that does not > invoke cm3cg. > > 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 8 Jan 2009, at 00:36, Jay wrote: > > duplication between compiler, m3makefile, and libraries. > > > I propose that there should be reduced or no duplication > among the compiler, m3makefile, and libraries. > > > I propose that the compiler reveal (some) of what it knows. > > > For example, m3makefile shall not specify WORD_SIZE. > The compiler should. > Granted, this buys very little. > > > m3makefile shall not contain tables identifiying endianness. > Compiler shall defined TARGET_ENDIAN to "BIG" or "LITTLE", > or perhaps "big" or "little". > Granted, this buys very little. > > > Libraries shall not define jumpbuf, in a sense. > Compile shall define, something like: > TARGET_JUMPBUF_ELEMENT = "INTEGER" or "LONGINT". > aka jmpbuf alignment. > TARGET_JUMPBUF_SIZE = a decimal integer. > Leaving library to say: > TYPE jmpbuf = ARRAY [1..size] OF element > which m3makefile shall produce. > > > or perhaps even compiler shall inject the type itself, > as it injects a few things like INTERFACE Word functions. > > > or compiler shall define TARGET_JUMPBUF_ALIGN = 32 or 64, > and TARGET_JUMPBUF_SIZE in bytes > leaving m3makefile to map 32 to Ctypes.int and 64 to LONGINT itself. > > > The jumpbuf size/align bothers me more than word size and endianness. > Word size and endianness are more widely known to humans I think. > Endianness and word size are usually fairly obvious, though > not 100%. I didn't know the endianness of e.g. 88k, vax, and the > historically > terse names don't make it obvious. > > > However, let me not confuse "jumpbuf" with "Thread.State" or such. > Assume user threads stops using setjmp/longjmp and modify > or generalize proposal accordingly. > > Wonder if exception handling should use set/get/make/swapcontext > also?? > Assume jumpbuf might remain on some platforms? > > ? > > As well, one should be able to specify m3config on the command line. > One should be able to specify target on the command line. > Compiler shall take specified target and search /somehow/ for the > right config file. > Perhaps in path to cm3\..\config\target. > Don't probe like crazy -- not like I have it coded in Quake currently. > That really bites when there is more than one, and you edit the > wrong one. > > Probably something like, > probe for path to cm3\..\config\target. > > but if defined $CM3_CONFIG_DIRECTORY, search instead > $CM3_CONFIG_DIRECTORY\target. > however this is perhaps colon or semicolon delimited, so maybe > CM3_CONFIG_PATH. > (In particular, I have nearly all my config files in m3-sys/ > cminstall/src/config-no-install, > except NT386, which I'd really like to move, but will probably break > something and > doesn't seem important). > > Reasonable ideas? > > > Personally what I do is my Python scripts accept a target name > anywhere on the > command line, and if present, they set $M3CONFIG. > So I have what I want via python already. > You know, kind of a successful (imho) prototype, that should perhaps > be elevated > into the "real" stuff? > > > You know, make it easier and easier to contruct cross-capable > installations, > where switching targets is changing environment variables and/or > command lines, > and not editing/copying files. > > > If there isn't already, there should be a mode that doesn't run cm3cg. > And possibly can still ship. > That way /any/ system can do a bunch of cross-build "checking". > And the file system layout for creating a "boot" archive becomes > about the same as the layout of a "real" system. > Not like what I use -- I use one flat directory, since Modula-3 > requires that every..basically ever .i3, .m3, .o file have a unique > name. > (.i3 and .m3 can clash with each other, once each, that's it). > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 8 06:28:12 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 8 Jan 2009 05:28:12 +0000 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: <234B3116-4C98-470B-9929-3E2AC72D67DC@cs.purdue.edu> References: <20090103011227.vgpfs347400088sg@mail.elegosoft.com> <44664E56-D816-4A94-AD2E-96A0DB383DDF@cs.purdue.edu> <234B3116-4C98-470B-9929-3E2AC72D67DC@cs.purdue.edu> Message-ID: > [Jay] Some programs "better" with user threads > [Tony] Is this still true for modern kernel thread systems? I really don't know. Olaf /kind of/ indicated so (just in saying that it'd be a nice option to have). > [Jay] small stacks for many threads vs. larger stacks for calls to "the system" > [Tony] In a systems programming language like Modula-3 shouldn't threads have a relationship to the system? Some might just be doing computation? > This will need to be a link-time distinction. > I would hate to have both kernel and user thread code live in the same compiled run-time system. I understand the principle, and I don't have a working implementation to argue with, but I do find this surprising. In my mind, you take MODULE ThreadPThread EXPORTS Scheduler, Thread, etc. change it to MODULE ThreadPThread Exports SchedulerPThread, ThreadPThread, etc. and introduce MODULE Thread EXPORTS Scheduler, Thread, etc. PROCEDURE Fork()= BEGIN IF KernelThreads RETURN ThreadPThread.Fork(); ELSE RETURN ThreadPosix.Fork(); END; END Fork. And so on. The potential bloat would be, you get both copies of code, both copies of globals, possibly initialization (but this most likely be avoided) and if any of the types are transparent, such that caller can allocate them on the stack, you end up either with the larger of the two sizes, or using a heap allocation with a dynamically chosen size. It seems to be roughly one source file each of bloat. >[Tony]I see no problem with factoring out the threads subsystem as a separate library and linking accordingly. That would prevent the bloat, indeed. However, if you mean, like m3coreuserthreads.dll, m3corekernelthreads.dll, well, the vast bulk of each of those two files would be identical. You could maybe factor out m3kernelthreads.dll m3userthreads.dll out of m3core.dll and have m3core.dll dynamically chose one of them. That might be good. But personally..I'd like fewer .dlls, even if that means larger .dlls. >I would argue for user vs. kernel. I think you are right. Kind of like the NT386 platform argument. There are many real implementation choices, but they need not be all exposed to the user, esp. unless/until someone asks. If Cygwin pthreads made to work, and then if there are proponents of it over NT threads, and vice versa, add a switch, pick a default. In the meantime, I only made one of three options work. >And managing the state-space explosion that multiple choices might entail. I would like to avoid that. What do you mean? Growing types to the union? The globals and code bloat? Globals could all be pushed into a heap allocated pointer anyway, paying a perf cost that would unlikely be noticed. Again, I kind'a'thunk linking both in would be pretty ok, it's basically just one source file, but I haven't done it yet. Before I do this I need to be working on a platform with user threads, and then make them work, and then make them "switchable", and I want to bring up more platforms before I work on any user threads. AMD64_FREEBSD I think will be next. > I am not so sure, since it would entail some fairly low-level > and expensive decisions that would best instead be done at link-time. Again this doesn't agree with my /suspicion/ but I didn't do enough research/work to be all that informed.. > Actually, for non-standalone (dynamically-linked) code > we could make the choice at dynamic load time using the OS's support for dynamic library choice. I'd rather not use dlopen et. al. at least not until I understand various details of dynamic loading across more platforms. I always though Win32 did it all just about right, and then I find a surprising array of other implementation choices and options on other systems.. > I note that Solaris (but not Solaris Modula-3) currently lets > dynamically linked C programs choose among 3 different threads implementations dynamically. Too much of a good thing imho... At least in Windows, there are a lot of "in-process plugins", and often times, interoperating code has to agree on the same underlying pieces, so wherever there is a choice, is an opportunity to fail. For example, if I call malloc and give you the result to free, or I call fopen and give it to you to fwrite, we need to be using the same C runtime. Even Linux has a few to chose from -- glibc, dietlibc, uclibc, newlib, etc. If you push "plugins" out of process, things become usually easier. Then folks either interoperate through carefully formatted files / pipes, network protocols, or RPC, and not via function calls. I only knew of two threading libraries on Solaris, "pre-pthreads" and "pthreads". Oh, maybe "lwp" and "thr"? I was wondering -- these are all built on the same kernel threads, right? So if you use a mix of them in a process, you still get reasonable global scheduling, right? ie: There's no point in writing ThreadSolarisThis.m3 or ThreadSolarisThat.m3, ThreadPThread.m3 suffices plenty? Coming back to the bloat issue. If you make the transform I show, you could also have a variant of Thread.m3 that just calls ThreadPThread.m3 directly. That is, it should be easy (still not having done it) to alter the code to build both of m3coreboth.dll and m3corejustkernel.dll. They can both have the interface that accepts the request or mandate for user threads, and m3corejustkernel.dll could either ignore or error on it. Users could install one or the other .dll as m3core.dll. Of course you could alos build m3corejustuser.dll. (These are stupid names, I know.) I really need to try it and see, it's fairly hypothetical right now. It sounds like I might be missing something. But first some other things.. - Jay CC: wagner at elegosoft.com; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] dynamic chose between user/kernel threads?Date: Thu, 8 Jan 2009 13:51:15 +1100 Jay, perhaps you can provide some context and motivation for your proposals. I am unable to evaluate your proposals in the form of a simple laundry-list. On 8 Jan 2009, at 01:34, Jay wrote: I looked into this a bit..and I think it's actually pretty easy.It hardly churns the code even. I have other things I want to do first. In the meantime, specify the directive?There are actually a large number of subtle options. Can I ask for any of n libraries -- NT, pthreads, user threads? setjmp vs. context? Or is it just a boolean, user vs. kernel? Is the option to "favor" or "require" a certain library? Can I set it on libraries or only programs? What if the requests clash? Is it "Favor" or "Require"?Is it a function call or setting a global variable?I favor function call, but TARGET, WORD_SIZE, BUILD_DIR establish the other precedent,and either can work. Is it flags in the moduleinfo like incgc, gengc, or separate data thatthere is just one of in RTLinker? Probably separate data, unless it is allowed in libraries. What are the names of the libraries? "posix" and "pthreads" ? "user" and "kernel" ? "true" and "false" (or vice versa) ? Should NT implement user threads, using fibers? Presumably it works with both standalone and shared/dynamic programs.Presumably it is ok to always bloat up m3core.dll with both libraries.Presumably it is ok to have everyone pay a teeny tiny perf. That is, there is a microscopic dispatching layer, that everyone ends up going through, not chosing to link in one library or the other. And as part of this, whenever it happens, can we bump up the minimumbootstrap to a version that includes SchedulerPosix.DoesWaitPidYield()?Or does it become VAR Scheduler.UsingKerneThreads?(no, it should be a function; but naming matter remains). (ie. as I said, the decision currently is baked into m3core.dll, butnow it is also baked into sysutils.dll, but these should change together;m3core.dll should manage the knowledge). - Jay> Date: Sat, 3 Jan 2009 01:12:27 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] dynamic chose between user/kernel threads?> > An option to cm3 or a quake directive to use in the m3makefiles> would suffice in my opinion (and be a great improvement).> > Olaf> > Quoting Jay :> > >> > Should the user/kernel thread chose be available:> >> >> > On the command line to a Modula-3 executable (or even an executable > > where main is in another language, but which static or dynamic > > Modula-3 libs are used)?> >> >> > Via a quake directive when building programs?> >> >> > You know, imagine you have a bunch of Modula-3 programs and some but > > not all use a very large number of threads and benefit from > > userthreads.> >> >> > Currently the chose is locked into m3core when it is built.> >> >> > - Jay> > > -- > Olaf -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 8 07:36:44 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 8 Jan 2009 06:36:44 +0000 Subject: [M3devel] making Uerror "portable"? Message-ID: I've been thinking about "fixing" Uerrorto remove the system-dependentness of it. I have about given up. There are multiple easy options, but theyall have downsides that make me think itmight not be worth it. today it looks like: INTERFACE Uerror; CONST ENOFILE = 1; ENOMEM = 2; END Uerror; The values are intended the correct native values. There are a fair number of users. Fewer than 10 probably.They include switch/case statements, which requireconstants. The following are some of the possible changes,that make porting to basically any future systembe a no-op in this area, except for the occasional missing or possiblyequal errnos (if there is a switch in the C code; I ran into this case). - Change to VAR and initialize them in portable C code. disadvantages: more startup code possibly startup code runs too late more writable/written data (readonly data is best) slower to access not constant, not switchable, not source quite compatible You have to change the switch statements to "if ladders" (if/elseif/elseif/elseif). Compatible with most source, and incompatible source easily fixed. possible issues around "dynamic linking data" (not explained here, ask?) However not really a problem. More of a problem only on NT, and easily worked around just like is done for hand.obj. - change to VAR and const static initialize them in portable C "data" no additional startup code -- guaranteed initialized early enough no writable/written data slower to access not constant, not switchable, not source compatible (same as previous) same non-issue around dynamic linking of data - change to functions GetENOFILE(), GetENOMEM(), etc. slower to access definitely no problem dynamic linking easier to write the C code/data, no matter, the above are easy enough not constant, not switchable, not source compatible (similar to previous) - "translation"; introduce our own arbitrary values for any errno the system uses; change Cerrno.GetErrno to have a switch and translate from the native values to ours. This is fully source compatible, dynamic link compatible, in-between perf wise (slower to GetErrnor, but then constant and just as comparable/switchable), no initialization cost. Question then though what does any raised exception look like? Do the values get translated back? Or translated to strings? SetErrno translates back? Translation is at first simple and is unique among portable solutions in its source compatibility, but I am leary of it. I would rather a solution that traffics in unmodified native errnos values, but I don't that is viable with both constness and portability. To a large extent, translation is ok. If you look at SocketPosix.i3, it uses the errno very briefly to determine the next step to take. I don't think it ever returns or RAISEs it (or an exception containing it). But other parts of the system Fmt.Int(errno) and raise that, thus these become values that move through more of the system and therefore disagreement with the underlying system might show through. There is also question of how to chose "Max". Set it large, like 200? Set it "correctly"? Probably a better option is to make the cache that is currently Max-sized be instead small and fixed-size (e.g. 64), and "search" it quickly instead of "indexing" it very quickly, and always kick out the least recently used. I also have to check what the contents actually are, perhaps they are constant-initializable. Thoughts? I was somewhat keen to do something here, but have pretty much given up and will just generate Uerror.i3 for Solaris, NetBSD, FreeBSD, AIX, Irix, HP-UX, etc.. I might still be able to remove the Usignal and Ustat system-dependentness in m3core/src/unix, but Uerror will probably stand asis (in linux-common, openbsd-common, cygwin). In particular, I was putting off any more ports till I got the amount of work needed to port reduced to my satisfaction. I think I'm nearly there. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Thu Jan 8 09:19:26 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 08 Jan 2009 00:19:26 -0800 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: Your message of "Thu, 08 Jan 2009 05:28:12 GMT." Message-ID: <200901080819.n088JQtJ021157@camembert.async.caltech.edu> Jay writes: >--_659eacae-e435-4dfa-807c-8eaabce063a9_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > ... >PROCEDURE Fork()=3D >BEGIN IF KernelThreads > RETURN ThreadPThread.Fork()=3B > ELSE > RETURN ThreadPosix.Fork()=3B > END=3B > END Fork. ... If it's implemented properly, on many architectures LOCK should be at most a couple of instructions. I think adding a couple of branches to it may make a significant difference. On those architectures it really ought to be inlined, too... Here's the "quick path" for LockMutex under user threads: INC (inCritical); IF m.holder = NIL THEN <* ASSERT self # NIL *> m.holder := self; DEC (inCritical); RETURN; END; Mika From jay.krell at cornell.edu Thu Jan 8 10:46:28 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 8 Jan 2009 09:46:28 +0000 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: <200901080819.n088JQtJ021157@camembert.async.caltech.edu> References: Your message of "Thu, 08 Jan 2009 05:28:12 GMT." <200901080819.n088JQtJ021157@camembert.async.caltech.edu> Message-ID: Ok, then make it function pointers. That is a little more work. It won't likely be inlined, but I doubt it ever is currently anyway. A good implementation will have that be zero or one instructions, but it might impede the processor reading ahead in the instruction stream. Zero instructions if the interfaces are actually exposed as function pointers, one instruction if they remain functions that just jump through a pointer. One instruction being much easier to implement probably. (Actually conditional branches better preserve inlinability, but it takes a sophisticated compiler to benefit). > at most a couple of instructions It's pretty hard to do anything in 2 instructions..esp. without inlining.. call, return, budget gone. Here's the uncontended non-recursive EnterCriticalSection for comparison, not as an example of exactly what Modula-3 does, but as what is surely an example of a fairly well implemented lock (albeit the data structure is on the large size, and does support recursion). 0:000> u ntdll!RtlEnterCriticalSectionntdll!RtlEnterCriticalSection:00000000`76d87850 fff3 push rbx00000000`76d87852 4883ec20 sub rsp,20h00000000`76d87856 f00fba710800 lock btr dword ptr [rcx+8],000000000`76d8785c 488bd1 mov rdx,rcx00000000`76d8785f 0f832c58ffff jae 00000000`76d7d091 contention or recursion presumably 00000000`76d87865 65488b042530000000 mov rax,qword ptr gs:[30h]00000000`76d8786e 488b4848 mov rcx,qword ptr [rax+48h]00000000`76d87872 c7420c01000000 mov dword ptr [rdx+0Ch],100000000`76d87879 33c0 xor eax,eax00000000`76d8787b 48894a10 mov qword ptr [rdx+10h],rcx00000000`76d8787f 4883c420 add rsp,20h00000000`76d87883 5b pop rbx00000000`76d87884 c3 ret and then let's follow the contended/recursive path: 0:000> u 76d7d09100000000`76d7d091 65488b042530000000 mov rax,qword ptr gs:[30h]00000000`76d7d09a 488bd9 mov rbx,rcx00000000`76d7d09d 488b5048 mov rdx,qword ptr [rax+48h] Presumably this is a check to see if this thread already has the critical section.00000000`76d7d0a1 48395110 cmp qword ptr [rcx+10h],rdx00000000`76d7d0a5 0f851413feff jne 00000000`76d5e3bf if not wait for other guy00000000`76d7d0ab 83410c01 add dword ptr [rcx+0Ch],1 if so, increment recursion count and done00000000`76d7d0af 33c0 xor eax,eax00000000`76d7d0b1 4883c420 add rsp,20h00000000`76d7d0b5 5b pop rbx00000000`76d7d0b6 c3 ret contended path not shown. So that's 13 instructions for initial entry, 15 instructions for recursive entry. 0:000> u ntdll!RtlLeaveCriticalSectionntdll!RtlLeaveCriticalSection:00000000`76d87800 4883ec28 sub rsp,28h00000000`76d87804 83410cff add dword ptr [rcx+0Ch],0FFFFFFFFh00000000`76d87808 7535 jne ntdll!RtlLeaveCriticalSection+0x3f (00000000`76d8783f)00000000`76d8780a 48895c2430 mov qword ptr [rsp+30h],rbx00000000`76d8780f 48897c2420 mov qword ptr [rsp+20h],rdi00000000`76d87814 48c7411000000000 mov qword ptr [rcx+10h],000000000`76d8781c bf01000000 mov edi,100000000`76d87821 488bd9 mov rbx,rcx00000000`76d87824 f00fc17908 lock xadd dword ptr [rcx+8],edi00000000`76d87829 83c701 add edi,100000000`76d8782c 83ffff cmp edi,0FFFFFFFFh00000000`76d8782f 0f854380fdff jne 00000000`76d5f87800000000`76d87835 488b5c2430 mov rbx,qword ptr [rsp+30h]00000000`76d8783a 488b7c2420 mov rdi,qword ptr [rsp+20h]00000000`76d8783f 33c0 xor eax,eax00000000`76d87841 4883c428 add rsp,28h00000000`76d87845 c3 ret 6 instructions for recursive exit. 17 instructions for last exit..I assume the conditional branch is to wake waiters. x86: 0:000> u ntdll!RtlEnterCriticalSectionntdll!RtlEnterCriticalSection:76f03580 8bff mov edi,edi76f03582 55 push ebp76f03583 8bec mov ebp,esp76f03585 83ec0c sub esp,0Ch76f03588 56 push esi76f03589 57 push edi76f0358a 8b7d08 mov edi,dword ptr [ebp+8]76f0358d 8d7704 lea esi,[edi+4]76f03590 8bc6 mov eax,esi76f03592 f00fba3000 lock btr dword ptr [eax],076f03597 0f83bec60000 jae (76f0fc5b)76f0359d 64a118000000 mov eax,dword ptr fs:[00000018h]76f035a3 8b4824 mov ecx,dword ptr [eax+24h]76f035a6 894f0c mov dword ptr [edi+0Ch],ecx76f035a9 c7470801000000 mov dword ptr [edi+8],176f035b0 5f pop edi76f035b1 33c0 xor eax,eax76f035b3 5e pop esi76f035b4 8be5 mov esp,ebp76f035b6 5d pop ebp76f035b7 c20400 ret 4 21 instructions for initial entry 0:000> u 76f0fc5b76f0fc5b 648b0d18000000 mov ecx,dword ptr fs:[18h]76f0fc62 8b570c mov edx,dword ptr [edi+0Ch]76f0fc65 3b5124 cmp edx,dword ptr [ecx+24h]76f0fc68 0f8584de0000 jne 76f1daf276f0fc6e 83470801 add dword ptr [edi+8],176f0fc72 5f pop edi76f0fc73 33c0 xor eax,eax76f0fc75 5e pop esi76f0fc76 8be5 mov esp,ebp76f0fc78 5d pop ebp76f0fc79 c20400 ret 4 22 for recursive entry. ntdll!RtlLeaveCriticalSection:76f035c0 8bff mov edi,edi76f035c2 55 push ebp76f035c3 8bec mov ebp,esp76f035c5 56 push esi76f035c6 8b7508 mov esi,dword ptr [ebp+8]76f035c9 834608ff add dword ptr [esi+8],0FFFFFFFFh76f035cd 7525 jne ntdll!RtlLeaveCriticalSection+0x34 (76f035f4)76f035cf 53 push ebx76f035d0 57 push edi76f035d1 8d7e04 lea edi,[esi+4]76f035d4 c7460c00000000 mov dword ptr [esi+0Ch],076f035db bb01000000 mov ebx,176f035e0 8bc7 mov eax,edi76f035e2 f00fc118 lock xadd dword ptr [eax],ebx76f035e6 83c301 add ebx,176f035e9 83fbff cmp ebx,0FFFFFFFFh76f035ec 0f85d8a50100 jne 76f1dbca76f035f2 5f pop edi76f035f3 5b pop ebx76f035f4 33c0 xor eax,eax76f035f6 5e pop esi76f035f7 5d pop ebp76f035f8 c20400 ret 4 11 instructions for recursive exit.23 instructions for last exit, I guess, without waiters. - Jay> To: jay.krell at cornell.edu> Date: Thu, 8 Jan 2009 00:19:26 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] dynamic chose between user/kernel threads?> > Jay writes:> >--_659eacae-e435-4dfa-807c-8eaabce063a9_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> ...> >PROCEDURE Fork()=3D> >BEGIN IF KernelThreads> > RETURN ThreadPThread.Fork()=3B> > ELSE> > RETURN ThreadPosix.Fork()=3B> > END=3B> > END Fork.> ...> > If it's implemented properly, on many architectures LOCK should be> at most a couple of instructions. I think adding a couple of> branches to it may make a significant difference. On those> architectures it really ought to be inlined, too...> > Here's the "quick path" for LockMutex under user threads:> > INC (inCritical);> IF m.holder = NIL THEN> <* ASSERT self # NIL *>> m.holder := self;> DEC (inCritical);> RETURN;> END;> > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jan 8 14:38:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 08 Jan 2009 14:38:25 +0100 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: <234B3116-4C98-470B-9929-3E2AC72D67DC@cs.purdue.edu> References: <20090103011227.vgpfs347400088sg@mail.elegosoft.com> <44664E56-D816-4A94-AD2E-96A0DB383DDF@cs.purdue.edu> <234B3116-4C98-470B-9929-3E2AC72D67DC@cs.purdue.edu> Message-ID: <20090108143825.2rggu3h0xkwgws80@mail.elegosoft.com> As I noted earlier, I think that a link-time choice between (M3) user and system (kernel/p) threads would be completely satisfactory. Default could be pthreads/system threads, and cm3 -uthreads or cm3 -m3threads could substitute the old but efficient M3 implementation (with proper getcontext/makecontext for all target platforms ;-). Olaf Quoting Tony Hosking : > On 8 Jan 2009, at 14:10, Jay wrote: > >> Olaf understood the point (I think). :) >> >> Some programs, people say, and I believe, run "better" (faster, >> without running out of address space) with user threads instead of >> kernel threads. > > Is this still true for modern kernel thread systems? > >> On systems that have both. >> A good example might be a program that needs lots of threads and >> therefore small stacks, and the kernel threads, due to code below >> the Modula-3 runtime, might force fairly large stacks. (Such a >> program might have to adjust thread size differently for different >> threads, and only call into the underlying system on threads with >> larger stacks.) > > In a systems programming language like Modula-3 shouldn't threads have > a relationship to the system? > >> It might be nice for such programs to be able to mandate or request >> (two slightly different things) that the user thread library be >> used by them, even if the platform's default is to use kernel >> threads. > > This will need to be a link-time distinction. I would hate to have > both kernel and user thread code live in the same compiled run-time > system. > >> The only minor detail then is, how to express the request, and the >> precise meaning. >> It is a request or a mandate? > > I see no problem with factoring out the threads subsystem as a > separate library and linking accordingly. > >> As well, if the issue is address space, sholud there a "built in" >> way to only make the request on 32bit platforms, or should uses >> manually say if equal (WORD_SIZE, "32BITS")? >> >> Is it a boolean or an enum? >> Cygwin might conceivably get pthreads support (Cygwin has it, but >> Modula-3/Cygwin does not). >> Therefore, is the choice among "posix" threads, "pthreads" and "NT" >> threads? >> Or just user vs. kernel? > > I would argue for user vs. kernel. > >> I think the "important" part here is easy to implement. >> But again.. > > And managing the state-space explosion that multiple choices might > entail. I would like to avoid that. > >> The easier straightforward implementation always links both pieces >> of code in and makes a choice early in startup as to which to use, >> either setting a boolean, or an enum, or a pointer to a record of >> function pointers. This means that people that don't care to ever >> use user threads pay a small price, in code bloat and probably in >> a few extra instructions per certain functions. This is probably >> ok. > > I am not so sure, since it would entail some fairly low-level and > expensive decisions that would best instead be done at link-time. > >> However if that was not ok, the choice could be made at link time >> and only be supported for standalone programs. > > Actually, for non-standalone (dynamically-linked) code we could make > the choice at dynamic load time using the OS's support for dynamic > library choice. > > I note that Solaris (but not Solaris Modula-3) currently lets > dynamically linked C programs choose among 3 different threads > implementations dynamically. > >> >> >> - Jay >> >> >> >> >> CC: wagner at elegosoft.com; m3devel at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Subject: Re: [M3devel] dynamic chose between user/kernel threads? >> Date: Thu, 8 Jan 2009 13:51:15 +1100 >> >> >> Jay, perhaps you can provide some context and motivation for your >> proposals. I am unable to evaluate your proposals in the form of a >> simple laundry-list. >> >> On 8 Jan 2009, at 01:34, Jay wrote: >> >> I looked into this a bit..and I think it's actually pretty easy. >> It hardly churns the code even. >> >> >> I have other things I want to do first. >> >> >> In the meantime, specify the directive? >> There are actually a large number of subtle options. >> >> >> Can I ask for any of n libraries -- NT, pthreads, user threads? >> setjmp vs. context? Or is it just a boolean, user vs. kernel? >> >> >> Is the option to "favor" or "require" a certain library? >> >> >> Can I set it on libraries or only programs? >> What if the requests clash? >> >> >> Is it "Favor" or "Require"? >> Is it a function call or setting a global variable? >> I favor function call, but TARGET, WORD_SIZE, BUILD_DIR establish >> the other precedent, >> and either can work. >> >> Is it flags in the moduleinfo like incgc, gengc, or separate data that >> there is just one of in RTLinker? Probably separate data, unless it >> is allowed in libraries. >> >> >> What are the names of the libraries? >> "posix" and "pthreads" ? >> "user" and "kernel" ? >> "true" and "false" (or vice versa) ? >> >> >> Should NT implement user threads, using fibers? >> >> >> Presumably it works with both standalone and shared/dynamic programs. >> Presumably it is ok to always bloat up m3core.dll with both libraries. >> Presumably it is ok to have everyone pay a teeny tiny perf. >> That is, there is a microscopic dispatching layer, that everyone >> ends up going through, not chosing to link in one library or the other. >> >> >> And as part of this, whenever it happens, can we bump up the minimum >> bootstrap to a version that includes SchedulerPosix.DoesWaitPidYield()? >> Or does it become VAR Scheduler.UsingKerneThreads? >> (no, it should be a function; but naming matter remains). >> >> >> (ie. as I said, the decision currently is baked into m3core.dll, but >> now it is also baked into sysutils.dll, but these should change together; >> m3core.dll should manage the knowledge). >> >> >> - Jay >> >> >>> Date: Sat, 3 Jan 2009 01:12:27 +0100 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] dynamic chose between user/kernel threads? >>> >>> An option to cm3 or a quake directive to use in the m3makefiles >>> would suffice in my opinion (and be a great improvement). >>> >>> Olaf >>> >>> Quoting Jay : >>> >>> > >>> > Should the user/kernel thread chose be available: >>> > >>> > >>> > On the command line to a Modula-3 executable (or even an executable >>> > where main is in another language, but which static or dynamic >>> > Modula-3 libs are used)? >>> > >>> > >>> > Via a quake directive when building programs? >>> > >>> > >>> > You know, imagine you have a bunch of Modula-3 programs and some but >>> > not all use a very large number of threads and benefit from >>> > userthreads. >>> > >>> > >>> > Currently the chose is locked into m3core when it is built. >>> > >>> > >>> > - Jay >>> >>> >>> -- >>> Olaf >> >> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jan 8 15:51:05 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 8 Jan 2009 14:51:05 +0000 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: <20090108143825.2rggu3h0xkwgws80@mail.elegosoft.com> References: <20090103011227.vgpfs347400088sg@mail.elegosoft.com> <44664E56-D816-4A94-AD2E-96A0DB383DDF@cs.purdue.edu> <234B3116-4C98-470B-9929-3E2AC72D67DC@cs.purdue.edu> <20090108143825.2rggu3h0xkwgws80@mail.elegosoft.com> Message-ID: I think you didn't realize some of what I was lumping into "link time". It could mean "constructing main to pass a parameter to RTLinker". Or setting a flag in the Main module (like how gengc/incgc flags are set in all modules, but this is a more difficult and likely wasteful change, no need to burn a bit in all modules, just the main module). I still think function pointers would suffice, costing zero or one instruction per function call.. But I haven't tried it yet. Systems with "build variants" tend to get "explosive" -- combinatorial explosions of "configurations". Boost is good (bad) example of this. - Jay> Date: Thu, 8 Jan 2009 14:38:25 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] dynamic chose between user/kernel threads?> > As I noted earlier, I think that a link-time choice between> (M3) user and system (kernel/p) threads would be completely> satisfactory. Default could be pthreads/system threads, and> cm3 -uthreads or cm3 -m3threads could substitute the old but> efficient M3 implementation (with proper getcontext/makecontext> for all target platforms ;-).> > Olaf> > Quoting Tony Hosking :> > > On 8 Jan 2009, at 14:10, Jay wrote:> >> >> Olaf understood the point (I think). :)> >>> >> Some programs, people say, and I believe, run "better" (faster, > >> without running out of address space) with user threads instead of > >> kernel threads.> >> > Is this still true for modern kernel thread systems?> >> >> On systems that have both.> >> A good example might be a program that needs lots of threads and > >> therefore small stacks, and the kernel threads, due to code below > >> the Modula-3 runtime, might force fairly large stacks. (Such a > >> program might have to adjust thread size differently for different > >> threads, and only call into the underlying system on threads with > >> larger stacks.)> >> > In a systems programming language like Modula-3 shouldn't threads have> > a relationship to the system?> >> >> It might be nice for such programs to be able to mandate or request > >> (two slightly different things) that the user thread library be > >> used by them, even if the platform's default is to use kernel > >> threads.> >> > This will need to be a link-time distinction. I would hate to have> > both kernel and user thread code live in the same compiled run-time> > system.> >> >> The only minor detail then is, how to express the request, and the > >> precise meaning.> >> It is a request or a mandate?> >> > I see no problem with factoring out the threads subsystem as a> > separate library and linking accordingly.> >> >> As well, if the issue is address space, sholud there a "built in" > >> way to only make the request on 32bit platforms, or should uses > >> manually say if equal (WORD_SIZE, "32BITS")?> >>> >> Is it a boolean or an enum?> >> Cygwin might conceivably get pthreads support (Cygwin has it, but > >> Modula-3/Cygwin does not).> >> Therefore, is the choice among "posix" threads, "pthreads" and "NT" > >> threads?> >> Or just user vs. kernel?> >> > I would argue for user vs. kernel.> >> >> I think the "important" part here is easy to implement.> >> But again..> >> > And managing the state-space explosion that multiple choices might> > entail. I would like to avoid that.> >> >> The easier straightforward implementation always links both pieces > >> of code in and makes a choice early in startup as to which to use, > >> either setting a boolean, or an enum, or a pointer to a record of > >> function pointers. This means that people that don't care to ever > >> use user threads pay a small price, in code bloat and probably in > >> a few extra instructions per certain functions. This is probably > >> ok.> >> > I am not so sure, since it would entail some fairly low-level and> > expensive decisions that would best instead be done at link-time.> >> >> However if that was not ok, the choice could be made at link time > >> and only be supported for standalone programs.> >> > Actually, for non-standalone (dynamically-linked) code we could make> > the choice at dynamic load time using the OS's support for dynamic> > library choice.> >> > I note that Solaris (but not Solaris Modula-3) currently lets> > dynamically linked C programs choose among 3 different threads> > implementations dynamically.> >> >>> >>> >> - Jay> >>> >>> >>> >>> >> CC: wagner at elegosoft.com; m3devel at elegosoft.com> >> From: hosking at cs.purdue.edu> >> To: jay.krell at cornell.edu> >> Subject: Re: [M3devel] dynamic chose between user/kernel threads?> >> Date: Thu, 8 Jan 2009 13:51:15 +1100> >>> >>> >> Jay, perhaps you can provide some context and motivation for your > >> proposals. I am unable to evaluate your proposals in the form of a > >> simple laundry-list.> >>> >> On 8 Jan 2009, at 01:34, Jay wrote:> >>> >> I looked into this a bit..and I think it's actually pretty easy.> >> It hardly churns the code even.> >>> >>> >> I have other things I want to do first.> >>> >>> >> In the meantime, specify the directive?> >> There are actually a large number of subtle options.> >>> >>> >> Can I ask for any of n libraries -- NT, pthreads, user threads?> >> setjmp vs. context? Or is it just a boolean, user vs. kernel?> >>> >>> >> Is the option to "favor" or "require" a certain library?> >>> >>> >> Can I set it on libraries or only programs?> >> What if the requests clash?> >>> >>> >> Is it "Favor" or "Require"?> >> Is it a function call or setting a global variable?> >> I favor function call, but TARGET, WORD_SIZE, BUILD_DIR establish > >> the other precedent,> >> and either can work.> >>> >> Is it flags in the moduleinfo like incgc, gengc, or separate data that> >> there is just one of in RTLinker? Probably separate data, unless it > >> is allowed in libraries.> >>> >>> >> What are the names of the libraries?> >> "posix" and "pthreads" ?> >> "user" and "kernel" ?> >> "true" and "false" (or vice versa) ?> >>> >>> >> Should NT implement user threads, using fibers?> >>> >>> >> Presumably it works with both standalone and shared/dynamic programs.> >> Presumably it is ok to always bloat up m3core.dll with both libraries.> >> Presumably it is ok to have everyone pay a teeny tiny perf.> >> That is, there is a microscopic dispatching layer, that everyone> >> ends up going through, not chosing to link in one library or the other.> >>> >>> >> And as part of this, whenever it happens, can we bump up the minimum> >> bootstrap to a version that includes SchedulerPosix.DoesWaitPidYield()?> >> Or does it become VAR Scheduler.UsingKerneThreads?> >> (no, it should be a function; but naming matter remains).> >>> >>> >> (ie. as I said, the decision currently is baked into m3core.dll, but> >> now it is also baked into sysutils.dll, but these should change together;> >> m3core.dll should manage the knowledge).> >>> >>> >> - Jay> >>> >>> >>> Date: Sat, 3 Jan 2009 01:12:27 +0100> >>> From: wagner at elegosoft.com> >>> To: m3devel at elegosoft.com> >>> Subject: Re: [M3devel] dynamic chose between user/kernel threads?> >>>> >>> An option to cm3 or a quake directive to use in the m3makefiles> >>> would suffice in my opinion (and be a great improvement).> >>>> >>> Olaf> >>>> >>> Quoting Jay :> >>>> >>> >> >>> > Should the user/kernel thread chose be available:> >>> >> >>> >> >>> > On the command line to a Modula-3 executable (or even an executable> >>> > where main is in another language, but which static or dynamic> >>> > Modula-3 libs are used)?> >>> >> >>> >> >>> > Via a quake directive when building programs?> >>> >> >>> >> >>> > You know, imagine you have a bunch of Modula-3 programs and some but> >>> > not all use a very large number of threads and benefit from> >>> > userthreads.> >>> >> >>> >> >>> > Currently the chose is locked into m3core when it is built.> >>> >> >>> >> >>> > - Jay> >>>> >>>> >>> --> >>> Olaf> >>> >>> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Jan 9 01:01:26 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 9 Jan 2009 11:01:26 +1100 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: <20090108143825.2rggu3h0xkwgws80@mail.elegosoft.com> References: <20090103011227.vgpfs347400088sg@mail.elegosoft.com> <44664E56-D816-4A94-AD2E-96A0DB383DDF@cs.purdue.edu> <234B3116-4C98-470B-9929-3E2AC72D67DC@cs.purdue.edu> <20090108143825.2rggu3h0xkwgws80@mail.elegosoft.com> Message-ID: I err on the side of simplicity, until there is an obvious need for adding complexity. In this case, I concur with Olaf that the most we would need is a simple link-time switch. 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 9 Jan 2009, at 00:38, Olaf Wagner wrote: > As I noted earlier, I think that a link-time choice between > (M3) user and system (kernel/p) threads would be completely > satisfactory. Default could be pthreads/system threads, and > cm3 -uthreads or cm3 -m3threads could substitute the old but > efficient M3 implementation (with proper getcontext/makecontext > for all target platforms ;-). > > Olaf > > Quoting Tony Hosking : > >> On 8 Jan 2009, at 14:10, Jay wrote: >> >>> Olaf understood the point (I think). :) >>> >>> Some programs, people say, and I believe, run "better" (faster, >>> without running out of address space) with user threads instead >>> of kernel threads. >> >> Is this still true for modern kernel thread systems? >> >>> On systems that have both. >>> A good example might be a program that needs lots of threads and >>> therefore small stacks, and the kernel threads, due to code >>> below the Modula-3 runtime, might force fairly large stacks. >>> (Such a program might have to adjust thread size differently for >>> different threads, and only call into the underlying system on >>> threads with larger stacks.) >> >> In a systems programming language like Modula-3 shouldn't threads >> have >> a relationship to the system? >> >>> It might be nice for such programs to be able to mandate or >>> request (two slightly different things) that the user thread >>> library be used by them, even if the platform's default is to >>> use kernel threads. >> >> This will need to be a link-time distinction. I would hate to have >> both kernel and user thread code live in the same compiled run-time >> system. >> >>> The only minor detail then is, how to express the request, and >>> the precise meaning. >>> It is a request or a mandate? >> >> I see no problem with factoring out the threads subsystem as a >> separate library and linking accordingly. >> >>> As well, if the issue is address space, sholud there a "built >>> in" way to only make the request on 32bit platforms, or should >>> uses manually say if equal (WORD_SIZE, "32BITS")? >>> >>> Is it a boolean or an enum? >>> Cygwin might conceivably get pthreads support (Cygwin has it, >>> but Modula-3/Cygwin does not). >>> Therefore, is the choice among "posix" threads, "pthreads" and >>> "NT" threads? >>> Or just user vs. kernel? >> >> I would argue for user vs. kernel. >> >>> I think the "important" part here is easy to implement. >>> But again.. >> >> And managing the state-space explosion that multiple choices might >> entail. I would like to avoid that. >> >>> The easier straightforward implementation always links both >>> pieces of code in and makes a choice early in startup as to >>> which to use, either setting a boolean, or an enum, or a pointer >>> to a record of function pointers. This means that people that >>> don't care to ever use user threads pay a small price, in code >>> bloat and probably in a few extra instructions per certain >>> functions. This is probably ok. >> >> I am not so sure, since it would entail some fairly low-level and >> expensive decisions that would best instead be done at link-time. >> >>> However if that was not ok, the choice could be made at link >>> time and only be supported for standalone programs. >> >> Actually, for non-standalone (dynamically-linked) code we could make >> the choice at dynamic load time using the OS's support for dynamic >> library choice. >> >> I note that Solaris (but not Solaris Modula-3) currently lets >> dynamically linked C programs choose among 3 different threads >> implementations dynamically. >> >>> >>> >>> - Jay >>> >>> >>> >>> >>> CC: wagner at elegosoft.com; m3devel at elegosoft.com >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Subject: Re: [M3devel] dynamic chose between user/kernel threads? >>> Date: Thu, 8 Jan 2009 13:51:15 +1100 >>> >>> >>> Jay, perhaps you can provide some context and motivation for >>> your proposals. I am unable to evaluate your proposals in the >>> form of a simple laundry-list. >>> >>> On 8 Jan 2009, at 01:34, Jay wrote: >>> >>> I looked into this a bit..and I think it's actually pretty easy. >>> It hardly churns the code even. >>> >>> >>> I have other things I want to do first. >>> >>> >>> In the meantime, specify the directive? >>> There are actually a large number of subtle options. >>> >>> >>> Can I ask for any of n libraries -- NT, pthreads, user threads? >>> setjmp vs. context? Or is it just a boolean, user vs. kernel? >>> >>> >>> Is the option to "favor" or "require" a certain library? >>> >>> >>> Can I set it on libraries or only programs? >>> What if the requests clash? >>> >>> >>> Is it "Favor" or "Require"? >>> Is it a function call or setting a global variable? >>> I favor function call, but TARGET, WORD_SIZE, BUILD_DIR >>> establish the other precedent, >>> and either can work. >>> >>> Is it flags in the moduleinfo like incgc, gengc, or separate data >>> that >>> there is just one of in RTLinker? Probably separate data, unless >>> it is allowed in libraries. >>> >>> >>> What are the names of the libraries? >>> "posix" and "pthreads" ? >>> "user" and "kernel" ? >>> "true" and "false" (or vice versa) ? >>> >>> >>> Should NT implement user threads, using fibers? >>> >>> >>> Presumably it works with both standalone and shared/dynamic >>> programs. >>> Presumably it is ok to always bloat up m3core.dll with both >>> libraries. >>> Presumably it is ok to have everyone pay a teeny tiny perf. >>> That is, there is a microscopic dispatching layer, that everyone >>> ends up going through, not chosing to link in one library or the >>> other. >>> >>> >>> And as part of this, whenever it happens, can we bump up the minimum >>> bootstrap to a version that includes >>> SchedulerPosix.DoesWaitPidYield()? >>> Or does it become VAR Scheduler.UsingKerneThreads? >>> (no, it should be a function; but naming matter remains). >>> >>> >>> (ie. as I said, the decision currently is baked into m3core.dll, but >>> now it is also baked into sysutils.dll, but these should change >>> together; >>> m3core.dll should manage the knowledge). >>> >>> >>> - Jay >>> >>> >>>> Date: Sat, 3 Jan 2009 01:12:27 +0100 >>>> From: wagner at elegosoft.com >>>> To: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] dynamic chose between user/kernel threads? >>>> >>>> An option to cm3 or a quake directive to use in the m3makefiles >>>> would suffice in my opinion (and be a great improvement). >>>> >>>> Olaf >>>> >>>> Quoting Jay : >>>> >>>> > >>>> > Should the user/kernel thread chose be available: >>>> > >>>> > >>>> > On the command line to a Modula-3 executable (or even an >>>> executable >>>> > where main is in another language, but which static or dynamic >>>> > Modula-3 libs are used)? >>>> > >>>> > >>>> > Via a quake directive when building programs? >>>> > >>>> > >>>> > You know, imagine you have a bunch of Modula-3 programs and >>>> some but >>>> > not all use a very large number of threads and benefit from >>>> > userthreads. >>>> > >>>> > >>>> > Currently the chose is locked into m3core when it is built. >>>> > >>>> > >>>> > - Jay >>>> >>>> >>>> -- >>>> Olaf >>> >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 11 04:02:41 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Jan 2009 03:02:41 +0000 Subject: [M3devel] fw: alignment greater than longint? In-Reply-To: <20090111004447.5014E10D535B@birch.elegosoft.com> References: <20090111004447.5014E10D535B@birch.elegosoft.com> Message-ID: Well, I'm not a fan of cloning headers..and in this case it doesn't matter anyway, and I'm actively uncloning them, but a way to be explicit about alignment might be good..? PPC_LINUX setjmp.h declares jmpbuf to be aligned to 16, though the comments say that 4 aligned suffices. I made it have an array of LONGINT to get as close as I could. - Jay> Date: Sun, 11 Jan 2009 01:44:47 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > 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> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 11 09:58:55 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Jan 2009 08:58:55 +0000 Subject: [M3devel] making Uerror "portable"? Message-ID: I still find pushing the system dependencies and cloned headers out of the system very tempting. To reduce what it takes to port to other systems, to raise the confidence of the correctness of any port, to keep ports correct in the face of possible underlying change. I think I'll change the case statements to if/else ladders and the consts to vars, that are actually statically initialized in C. This treatment is reasonable for other constants that remain in the cloned headers, system dependent or otherwise. - Jay From: jay.krell at cornell.eduTo: m3devel at elegosoft.comSubject: making Uerror "portable"?Date: Thu, 8 Jan 2009 06:36:44 +0000 I've been thinking about "fixing" Uerrorto remove the system-dependentness of it. I have about given up. There are multiple easy options, but theyall have downsides that make me think itmight not be worth it. today it looks like: INTERFACE Uerror;CONST ENOFILE = 1; ENOMEM = 2;END Uerror; The values are intended the correct native values.There are a fair number of users.Fewer than 10 probably.They include switch/case statements, which requireconstants. The following are some of the possible changes,that make porting to basically any future systembe a no-op in this area, except for the occasional missing or possiblyequal errnos (if there is a switch in the C code; I ran into this case). - Change to VAR and initialize them in portable C code. disadvantages: more startup code possibly startup code runs too late more writable/written data (readonly data is best) slower to access not constant, not switchable, not source quite compatible You have to change the switch statements to "if ladders" (if/elseif/elseif/elseif). Compatible with most source, and incompatible source easily fixed. possible issues around "dynamic linking data" (not explained here, ask?) However not really a problem. More of a problem only on NT, and easily worked around just like is done for hand.obj. - change to VAR and const static initialize them in portable C "data" no additional startup code -- guaranteed initialized early enough no writable/written data slower to access not constant, not switchable, not source compatible (same as previous) same non-issue around dynamic linking of data - change to functions GetENOFILE(), GetENOMEM(), etc. slower to access definitely no problem dynamic linking easier to write the C code/data, no matter, the above are easy enough not constant, not switchable, not source compatible (similar to previous) - "translation"; introduce our own arbitrary values for any errno the system uses; change Cerrno.GetErrno to have a switch and translate from the native values to ours. This is fully source compatible, dynamic link compatible, in-between perf wise (slower to GetErrnor, but then constant and just as comparable/switchable), no initialization cost. Question then though what does any raised exception look like? Do the values get translated back? Or translated to strings? SetErrno translates back? Translation is at first simple and is unique among portable solutions in its source compatibility, but I am leary of it. I would rather a solution that traffics in unmodified native errnos values, but I don't that is viable with both constness and portability. To a large extent, translation is ok. If you look at SocketPosix.i3, it uses the errno very briefly to determine the next step to take. I don't think it ever returns or RAISEs it (or an exception containing it). But other parts of the system Fmt.Int(errno) and raise that, thus these become values that move through more of the system and therefore disagreement with the underlying system might show through. There is also question of how to chose "Max". Set it large, like 200? Set it "correctly"? Probably a better option is to make the cache that is currently Max-sized be instead small and fixed-size (e.g. 64), and "search" it quickly instead of "indexing" it very quickly, and always kick out the least recently used. I also have to check what the contents actually are, perhaps they are constant-initializable. Thoughts? I was somewhat keen to do something here, but have pretty much given up and will just generate Uerror.i3 for Solaris, NetBSD, FreeBSD, AIX, Irix, HP-UX, etc.. I might still be able to remove the Usignal and Ustat system-dependentness in m3core/src/unix, but Uerror will probably stand asis (in linux-common, openbsd-common, cygwin). In particular, I was putting off any more ports till I got the amount of work neededto port reduced to my satisfaction. I think I'm nearly there. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 11 13:57:13 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Jan 2009 12:57:13 +0000 Subject: [M3devel] Juno (X) networking problem on AMD64_FREEBSD Message-ID: Hi. Unix network programming question.. AMD64_FREEBSD: $DISPLAY is set to point back to Cygwin host.It works for PPC_LINUX. [jay at fbsdamd64a /cm3/bin]$ ./Juno ****** runtime error:*** Exception "IPError.FatalError" not in RAISES list*** file "../src/common/IPError.m3", line 27*** Abort trap: 6 (core dumped)[jay at fbsdamd64a /cm3/bin]$ IP.m3: PROCEDURE GetHostAddr(): Address = VAR hname: ARRAY [0..255] OF CHAR; BEGIN LOCK mu DO IF Unix.gethostname(ADR(hname[0]), BYTESIZE(hname)) # 0 THEN IPError.Die (); END; VAR h := Unetdb.gethostbyname(ADR(hname[0])); BEGIN IF h = NIL THEN IPError.Die(); END; RETURN GetAddress(h); END; END; END GetHostAddr; PROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Address = VAR ua: Uin.struct_in_addr; BEGIN <* ASSERT ent.h_length <= BYTESIZE(Address) *> ua := LOOPHOLE(ent.h_addr_list, UNTRACED REF UNTRACED REF Uin.struct_in_addr)^^; RETURN LOOPHOLE(ua.s_addr, Address); END GetAddress; gethostbyname is failing. Analogous C code also fails: [jay at fbsdamd64a /cm3/bin]$ cat ~/5.c#include #include #include #include typedef struct hostent hostent_t; int main(){ char hostname[200]; hostent_t* h; int i; i = gethostname(hostname, 200); assert(i == 0); printf("hostname: %s\n", hostname); h = gethostbyname(hostname); herror("foo"); printf("%p %d %d\n", h, errno, h_errno); assert(h); return 0;} herror says "unknown host". Stack is: at ../src/runtime/ex_frame/RTExFrame.m3:58#13 0x0000000801a7f2b3 in RTHooks__Raise (M3_AJWxb1_ex=Error accessing memory address 0x8000ffffd278: Bad address.) at ../src/runtime/common/RTHooks.m3:79#14 0x000000080169c8d3 in IPError__Die () at ../src/common/IPError.m3:27#15 0x0000000801698a3e in IP__GetHostAddr (M3_BCxjPn__result=Error accessing memory address 0x8000ffffd338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x00000008012133d0 in XSharedMem__SameHost (M3_AQuuui_trsl=Error accessing memory address 0x8000ffffd4d8: Bad address.) at ../src/xvbt/XSharedMem.m3:96#17 0x0000000801212ab7 in XSharedMem__InitXClient (M3_AQuuui_v=Error accessing memory address 0x8000ffffd648: Bad address.) at ../src/xvbt/XSharedMem.m3:29#18 0x0000000801211819 in XExtensions__InitXClient (M3_AQuuui_xclient=Error accessing memory address 0x8000ffffd7f8: Bad address.) at ../src/xvbt/XExtensions.m3:14#19 0x00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst=0x1879b, M3_AQuuui_trsl=0x6) at ../src/xvbt/XClientF.m3:583---Type to continue, or q to quit---(More stack frames follow...)(gdb) (* return TRUE if server and client are on same host *)PROCEDURE SameHost (trsl: XClient.T): BOOLEAN = VAR display := DisplayHost(trsl); displayAddr: IP.Address; BEGIN IF display = NIL THEN RETURN TRUE; END; TRY IF NOT IP.GetHostByName(display, displayAddr) THEN RETURN FALSE; END; RETURN displayAddr = IP.GetHostAddr(); EXCEPT | IP.Error => RETURN FALSE; END; END SameHost; Thoughts? Perhaps my network isn't setup well, like I should add the local machine to /etc/hosts.I think this can be made to fail gracefully though.It seems like it has nothing to do with AMD64_FREEBSD, but could have to do with FreeBSD. Seems like SocketPosix has nearly the exact same code but appearsmore forgiving.. IOError instead of Fatal? SocketPosix.m3: PROCEDURE GetHostAddr (): Address RAISES {OSError.E} = VAR host : ARRAY [0..255] OF CHAR; info : Unetdb.struct_hostent_star; ua : Uin.struct_in_addr; BEGIN IF Unix.gethostname (ADR (host[0]), BYTESIZE (host)) # 0 THEN IOError (Unexpected); END; info := Unetdb.gethostbyname (ADR (host[0])); IF info = NIL THEN IOError (Unexpected); END; <* ASSERT info.h_length <= BYTESIZE (Address) *> ua := LOOPHOLE(info.h_addr_list, UNTRACED REF UNTRACED REF Uin.struct_in_addr)^^; RETURN LOOPHOLE (ua.s_addr, Address); END GetHostAddr; It is again disappointing to see such code duplication. I guess SameHost can duplicate the logic to predict the error state and return false upon error? Duplicating the logic for a third time. :( - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 11 14:37:37 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Jan 2009 13:37:37 +0000 Subject: [M3devel] Juno (X) networking problem on AMD64_FREEBSD In-Reply-To: References: Message-ID: I commited a workaround here, that introduces essentially a third copy of relevant code. Anyone have further ideas? (* This is a clone of IP.GetHostAddr that returns TRUE if IP.GetHostAddr is likely to succeed and FALSE if IP.GetHostAddr is likely to fail. *) VAR mu := NEW(MUTEX); PROCEDURE PredictIPGetHostAddrSuccess(): BOOLEAN = VAR hname: ARRAY [0..255] OF CHAR; BEGIN LOCK mu DO RETURN (Unix.gethostname(ADR(hname[0]), BYTESIZE(hname)) = 0) AND (Unetdb.gethostbyname(ADR(hname[0])) # NIL); END; END PredictIPGetHostAddrSuccess; (* return TRUE if server and client are on same host *) PROCEDURE SameHost (trsl: XClient.T): BOOLEAN = VAR display := DisplayHost(trsl); displayAddr: IP.Address; BEGIN IF display = NIL THEN RETURN TRUE; END; TRY IF NOT IP.GetHostByName(display, displayAddr) THEN RETURN FALSE; END; (* IP.GetHostAddr can return a fatal exception; try to avoid that by predicting its success. *) IF NOT PredictIPGetHostAddrSuccess() THEN RETURN FALSE; END; RETURN displayAddr = IP.GetHostAddr(); EXCEPT | IP.Error => RETURN FALSE; END; END SameHost; - Jay From: jay.krell at cornell.eduTo: m3devel at elegosoft.comDate: Sun, 11 Jan 2009 12:57:13 +0000Subject: [M3devel] Juno (X) networking problem on AMD64_FREEBSD Hi. Unix network programming question..AMD64_FREEBSD:$DISPLAY is set to point back to Cygwin host.It works for PPC_LINUX.[jay at fbsdamd64a /cm3/bin]$ ./Juno****** runtime error:*** Exception "IPError.FatalError" not in RAISES list*** file "../src/common/IPError.m3", line 27***Abort trap: 6 (core dumped)[jay at fbsdamd64a /cm3/bin]$IP.m3: PROCEDURE GetHostAddr(): Address = VAR hname: ARRAY [0..255] OF CHAR; BEGIN LOCK mu DO IF Unix.gethostname(ADR(hname[0]), BYTESIZE(hname)) # 0 THEN IPError.Die (); END; VAR h := Unetdb.gethostbyname(ADR(hname[0])); BEGIN IF h = NIL THEN IPError.Die(); END; RETURN GetAddress(h); END; END; END GetHostAddr;PROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Address = VAR ua: Uin.struct_in_addr; BEGIN <* ASSERT ent.h_length <= BYTESIZE(Address) *> ua := LOOPHOLE(ent.h_addr_list, UNTRACED REF UNTRACED REF Uin.struct_in_addr)^^; RETURN LOOPHOLE(ua.s_addr, Address); END GetAddress; gethostbyname is failing. Analogous C code also fails: [jay at fbsdamd64a /cm3/bin]$ cat ~/5.c#include #include #include #include typedef struct hostent hostent_t; int main(){ char hostname[200]; hostent_t* h; int i; i = gethostname(hostname, 200); assert(i == 0); printf("hostname: %s\n", hostname); h = gethostbyname(hostname); herror("foo"); printf("%p %d %d\n", h, errno, h_errno); assert(h); return 0;} herror says "unknown host".Stack is: at ../src/runtime/ex_frame/RTExFrame.m3:58#13 0x0000000801a7f2b3 in RTHooks__Raise (M3_AJWxb1_ex=Error accessing memory address 0x8000ffffd278: Bad address.) at ../src/runtime/common/RTHooks.m3:79#14 0x000000080169c8d3 in IPError__Die () at ../src/common/IPError.m3:27#15 0x0000000801698a3e in IP__GetHostAddr (M3_BCxjPn__result=Error accessing memory address 0x8000ffffd338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x00000008012133d0 in XSharedMem__SameHost (M3_AQuuui_trsl=Error accessing memory address 0x8000ffffd4d8: Bad address.) at ../src/xvbt/XSharedMem.m3:96#17 0x0000000801212ab7 in XSharedMem__InitXClient (M3_AQuuui_v=Error accessing memory address 0x8000ffffd648: Bad address.) at ../src/xvbt/XSharedMem.m3:29#18 0x0000000801211819 in XExtensions__InitXClient (M3_AQuuui_xclient=Error accessing memory address 0x8000ffffd7f8: Bad address.) at ../src/xvbt/XExtensions.m3:14#19 0x00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst=0x1879b, M3_AQuuui_trsl=0x6) at ../src/xvbt/XClientF.m3:583---Type to continue, or q to quit---(More stack frames follow...)(gdb)(* return TRUE if server and client are on same host *)PROCEDURE SameHost (trsl: XClient.T): BOOLEAN = VAR display := DisplayHost(trsl); displayAddr: IP.Address; BEGIN IF display = NIL THEN RETURN TRUE; END; TRY IF NOT IP.GetHostByName(display, displayAddr) THEN RETURN FALSE; END; RETURN displayAddr = IP.GetHostAddr(); EXCEPT | IP.Error => RETURN FALSE; END; END SameHost; Thoughts? Perhaps my network isn't setup well, like I should add the local machine to /etc/hosts.I think this can be made to fail gracefully though.It seems like it has nothing to do with AMD64_FREEBSD, but could have to do with FreeBSD. Seems like SocketPosix has nearly the exact same code but appearsmore forgiving.. IOError instead of Fatal? SocketPosix.m3: PROCEDURE GetHostAddr (): Address RAISES {OSError.E} = VAR host : ARRAY [0..255] OF CHAR; info : Unetdb.struct_hostent_star; ua : Uin.struct_in_addr; BEGIN IF Unix.gethostname (ADR (host[0]), BYTESIZE (host)) # 0 THEN IOError (Unexpected); END; info := Unetdb.gethostbyname (ADR (host[0])); IF info = NIL THEN IOError (Unexpected); END; <* ASSERT info.h_length <= BYTESIZE (Address) *> ua := LOOPHOLE(info.h_addr_list, UNTRACED REF UNTRACED REF Uin.struct_in_addr)^^; RETURN LOOPHOLE (ua.s_addr, Address); END GetHostAddr; It is again disappointing to see such code duplication. I guess SameHost can duplicate the logic to predict the error state and return false upon error?Duplicating the logic for a third time. :( - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 11 15:44:14 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Jan 2009 14:44:14 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? Message-ID: Is there a way in Modula-3 to declare that a type exists, and there are <*external*> instances of it, without "fully" declaring it, so that no Modula-3 can instantiate it? I have done this for sigset_t and sem_t, but they could erroneously be instantiated by Modula-3 and I'd like to remove that ability to mess up so easily. (* This type is not declared correctly. It is only instantiated in C code. *) sigset_t = RECORD END; (* This type is not declared correctly. It is only instantiated in C code. *) sem_t = RECORD END; In C I believe you can do this, like: typedef struct foo foo_t; extern foo_t foo; void UseFoo(foo_t*); foo_t* GetFoo(void); Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Jan 11 17:02:18 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 11 Jan 2009 08:02:18 -0800 Subject: [M3devel] Juno (X) networking problem on AMD64_FREEBSD In-Reply-To: Your message of "Sun, 11 Jan 2009 12:57:13 GMT." Message-ID: <200901111602.n0BG2IUG047813@camembert.async.caltech.edu> This is a screwy thing in Modula-3. A bug I would call it. I've noticed a lot of networking M3 programs don't work right unless the return value of Unix's "hostname" maps to a real IP address via gethostbyname. I accomplish it in practice by adding my hostname to /etc/hosts. This is obviously not the right way to fix it... Mika Jay writes: >--_9e67232c-a064-417d-879e-227a77e310f9_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Hi. Unix network programming question.. >AMD64_FREEBSD: >$DISPLAY is set to point back to Cygwin host.It works for PPC_LINUX. >[jay at fbsdamd64a /cm3/bin]$ ./Juno >****** runtime error:*** Exception "IPError.FatalError" not in RAISES li= >st*** file "../src/common/IPError.m3"=2C line 27*** >Abort trap: 6 (core dumped)[jay at fbsdamd64a /cm3/bin]$ >IP.m3: >=20 >PROCEDURE GetHostAddr(): Address =3D VAR hname: ARRAY [0..255] OF CHAR=3B = > BEGIN LOCK mu DO IF Unix.gethostname(ADR(hname[0])=2C BYTESIZE(hna= >me)) # 0 THEN IPError.Die ()=3B END=3B VAR h :=3D Unetdb.g= >ethostbyname(ADR(hname[0]))=3B BEGIN IF h =3D NIL THEN IPError.Die()= >=3B END=3B RETURN GetAddress(h)=3B END=3B END=3B END GetHos= >tAddr=3B >PROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Address =3D VAR ua= >: Uin.struct_in_addr=3B BEGIN <* ASSERT ent.h_length <=3D BYTESIZE(Addr= >ess) *> ua :=3D LOOPHOLE(ent.h_addr_list=2C UNTRACED = >REF UNTRACED REF Uin.struct_in_addr)^^=3B RETURN LOOPHOLE(ua.s_addr=2C A= >ddress)=3B END GetAddress=3B >=20 >gethostbyname is failing. >=20 >Analogous C code also fails: >=20 >[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c#include #include #i= >nclude #include typedef struct hostent hostent_t=3B >=20 >int main(){ char hostname[200]=3B hostent_t* h=3B int i=3B > i =3D gethostname(hostname=2C 200)=3B assert(i =3D=3D 0)=3B printf("hostna= >me: %s\n"=2C hostname)=3B h =3D gethostbyname(hostname)=3B herror("foo")=3B= > printf("%p %d %d\n"=2C h=2C errno=2C h_errno)=3B assert(h)=3B return 0=3B} >=20 >herror says "unknown host". >Stack is: > at ../src/runtime/ex_frame/RTExFrame.m3:58#13 0x0000000801a7f2b3 in RTH= >ooks__Raise (M3_AJWxb1_ex=3DError accessing memory address 0x8000ffffd278: = >Bad address.) at ../src/runtime/common/RTHooks.m3:79#14 0x000000080169c8= >d3 in IPError__Die () at ../src/common/IPError.m3:27#15 0x0000000801698a3e = >in IP__GetHostAddr (M3_BCxjPn__result=3DError accessing memory address 0x80= >00ffffd338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x00000008012133d0= > in XSharedMem__SameHost (M3_AQuuui_trsl=3DError accessing memory address 0= >x8000ffffd4d8: Bad address.) at ../src/xvbt/XSharedMem.m3:96#17 0x000000= >0801212ab7 in XSharedMem__InitXClient (M3_AQuuui_v=3DError accessing memory= > address 0x8000ffffd648: Bad address.) at ../src/xvbt/XSharedMem.m3:29#1= >8 0x0000000801211819 in XExtensions__InitXClient (M3_AQuuui_xclient=3DError= > accessing memory address 0x8000ffffd7f8: Bad address.) at ../src/xvbt/X= >Extensions.m3:14#19 0x00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst= >=3D0x1879b=2C M3_AQuuui_trsl=3D0x6) at ../src/xvbt/XClientF.m3:583---Typ= >e to continue=2C or q to quit---(More stack frames follow= >...)(gdb) >(* return TRUE if server and client are on same host *)PROCEDURE SameHost (= >trsl: XClient.T): BOOLEAN =3D VAR display :=3D DisplayH= >ost(trsl)=3B displayAddr: IP.Address=3B BEGIN IF display =3D NIL THE= >N RETURN TRUE=3B END=3B > TRY IF NOT IP.GetHostByName(display=2C displayAddr) THEN RETURN FA= >LSE=3B END=3B RETURN displayAddr =3D IP.GetHostAddr()=3B EXCEPT = >| IP.Error =3D> RETURN FALSE=3B END=3B END SameHost=3B >=20 >Thoughts? >=20 >Perhaps my network isn't setup well=2C like I should add the local machine = >to /etc/hosts.I think this can be made to fail gracefully though.It seems l= >ike it has nothing to do with AMD64_FREEBSD=2C but could have to do with Fr= >eeBSD. >=20 >Seems like SocketPosix has nearly the exact same code but appearsmore forgi= >ving.. IOError instead of Fatal? >=20 >SocketPosix.m3: >=20 >PROCEDURE GetHostAddr (): Address RAISES {OSError.E} =3D VAR host : AR= >RAY [0..255] OF CHAR=3B info : Unetdb.struct_hostent_star=3B ua : U= >in.struct_in_addr=3B BEGIN IF Unix.gethostname (ADR (host[0])=2C BYTESI= >ZE (host)) # 0 THEN IOError (Unexpected)=3B END=3B > info :=3D Unetdb.gethostbyname (ADR (host[0]))=3B IF info =3D NIL TH= >EN IOError (Unexpected)=3B END=3B <* ASSERT info.h_length <=3D BYTESIZE = >(Address) *> > ua :=3D LOOPHOLE(info.h_addr_list=2C UNTRACED REF UNT= >RACED REF Uin.struct_in_addr)^^=3B RETURN LOOPHOLE (ua.s_addr=2C Address= >)=3B END GetHostAddr=3B >=20 >=20 >It is again disappointing to see such code duplication. >=20 >=20 >I guess SameHost can duplicate the logic to predict the error state and ret= >urn false upon error? >Duplicating the logic for a third time. :( >=20 > - Jay= > >--_9e67232c-a064-417d-879e-227a77e310f9_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Hi. Unix network programming question..
>
AMD64_FREEBSD:
>
$DISPLAY is set to point back to Cygwin host.
It works for PPC_LINUX= >.
>
[jay at fbsdamd64a /cm3/bin]$ ./Juno
>
***
*** runtime error:
*** =3B =3B =3B Exception "IPE= >rror.FatalError" not in RAISES list
*** =3B =3B =3B file "..= >/src/common/IPError.m3"=2C line 27
***
>
Abort trap: 6 (core dumped)
[jay at fbsdamd64a /cm3/bin]$
>
IP.m3:
> =3B
>PROCEDURE GetHostAddr(): Address =3D
 =3B VAR hname: ARRAY [0..255] = OF CHAR=3B
 =3B BEGIN
 =3B =3B =3B LOCK mu DO
&nbs= >p=3B =3B =3B =3B =3B IF Unix.gethostname(ADR(hname[0])=2C B= >YTESIZE(hname)) # 0 THEN
 =3B =3B =3B =3B =3B = >=3B =3B IPError.Die ()=3B
 =3B =3B =3B =3B =3B E= >ND=3B
 =3B =3B =3B =3B =3B VAR h :=3D Unetdb.gethost= >byname(ADR(hname[0]))=3B BEGIN
 =3B =3B =3B =3B =3B&= >nbsp=3B =3B IF h =3D NIL THEN IPError.Die()=3B END=3B
 =3B = >=3B =3B =3B =3B =3B =3B RETURN GetAddress(h)=3B
&nbs= >p=3B =3B =3B =3B =3B END=3B
 =3B =3B =3B END= >=3B
 =3B END GetHostAddr=3B
>
PROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Address =3D
= > =3B VAR ua: Uin.struct_in_addr=3B
 =3B BEGIN
 =3B = >=3B =3B <=3B* ASSERT ent.h_length <=3B=3D BYTESIZE(Address) *>=3B= >
 =3B =3B =3B ua :=3D LOOPHOLE(ent.h_addr_list=2C
 = >=3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= > =3B =3B =3B =3B =3B =3B =3B =3B =3B UN= >TRACED REF UNTRACED REF Uin.struct_in_addr)^^=3B
 =3B =3B = >=3B RETURN LOOPHOLE(ua.s_addr=2C Address)=3B
 =3B END GetAddress=3B<= >BR> > =3B
>gethostbyname is failing.
>
 =3B
>Analogous C code also fails:
> =3B
>
[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c
#include <=3Bassert.h>=3BR>#include <=3Bnetdb.h>=3B
#include <=3Bstdio.h>=3B
#include = ><=3Berrno.h>=3B
typedef struct hostent hostent_t=3B
> =3B
>int main()
{
 =3Bchar hostname[200]=3B
 =3Bhostent_t* h=3B= >
 =3Bint i=3B
> =3Bi =3D gethostname(hostname=2C 200)=3B
 =3Bassert(i =3D=3D 0)= >=3B
 =3Bprintf("hostname: %s\n"=2C hostname)=3B
 =3Bh =3D get= >hostbyname(hostname)=3B
 =3Bherror("foo")=3B
 =3Bprintf("%p %= >d %d\n"=2C h=2C errno=2C h_errno)=3B
 =3Bassert(h)=3B
 =3Bret= >urn 0=3B
}
> =3B
>herror says "unknown host".
>
Stack is:
> =3B =3B =3B at ../src/runtime/ex_frame/RTExFrame.m3:58
#13 = >0x0000000801a7f2b3 in RTHooks__Raise (M3_AJWxb1_ex=3DError accessing memory= > ad
dress 0x8000ffffd278: Bad address.
)
 =3B =3B =3B = >at ../src/runtime/common/RTHooks.m3:79
#14 0x000000080169c8d3 in IPError= >__Die () at ../src/common/IPError.m3:27
#15 0x0000000801698a3e in IP__Ge= >tHostAddr (M3_BCxjPn__result=3DError accessing mem
ory address 0x8000fff= >fd338: Bad address.
)
 =3B =3B =3B at ../src/POSIX/IP.m3:= >82
#16 0x00000008012133d0 in XSharedMem__SameHost (M3_AQuuui_trsl=3DErro= >r accessing m
emory address 0x8000ffffd4d8: Bad address.
)
 = >=3B =3B =3B at ../src/xvbt/XSharedMem.m3:96
#17 0x0000000801212a= >b7 in XSharedMem__InitXClient (M3_AQuuui_v=3DError accessing m
emory add= >ress 0x8000ffffd648: Bad address.
)
 =3B =3B =3B at ../sr= >c/xvbt/XSharedMem.m3:29
#18 0x0000000801211819 in XExtensions__InitXClie= >nt (M3_AQuuui_xclient=3DError acce
ssing memory address 0x8000ffffd7f8: = >Bad address.
)
 =3B =3B =3B at ../src/xvbt/XExtensions.m3= >:14
#19 0x00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst=3D0x1879= >b=2C
 =3B =3B =3B M3_AQuuui_trsl=3D0x6) at ../src/xvbt/XClie= >ntF.m3:583
---Type <=3Breturn>=3B to continue=2C or q <=3Breturn&g= >t=3B to quit---
(More stack frames follow...)
(gdb)
>
(* return TRUE if server and client are on same host *)
PROCEDURE Sa= >meHost (trsl: XClient.T): BOOLEAN =3D
 =3B VAR
 =3B =3B&n= >bsp=3B display =3B =3B =3B =3B =3B =3B =3B = >=3B =3B =3B =3B =3B =3B =3B =3B =3B :=3D Di= >splayHost(trsl)=3B
 =3B =3B =3B displayAddr: IP.Address=3BR> =3B BEGIN
 =3B =3B =3B IF display =3D NIL THEN RETURN= > TRUE=3B END=3B
> =3B =3B =3B TRY
 =3B =3B =3B =3B =3B IF= > NOT IP.GetHostByName(display=2C displayAddr) THEN RETURN FALSE=3B END=3BR> =3B =3B =3B =3B =3B RETURN displayAddr =3D IP.GetHos= >tAddr()=3B
 =3B =3B =3B EXCEPT
 =3B =3B =3B |= > IP.Error =3D>=3B RETURN FALSE=3B
 =3B =3B =3B END=3B
&= >nbsp=3B END SameHost=3B
> =3B
>Thoughts?
> =3B
>
Perhaps my network isn't setup well=2C like I should add the local mach= >ine to /etc/hosts.
I think this can be made to fail gracefully though.R>It seems like it has nothing to do with AMD64_FREEBSD=2C but could have t= >o do with FreeBSD.
>
 =3B
>Seems like SocketPosix has nearly the exact same code but appears
more f= >orgiving.. IOError instead of Fatal?
> =3B
>
SocketPosix.m3:
> =3B
>
PROCEDURE GetHostAddr (): Address
 =3B RAISES {OSError.E} =3D> =3B VAR
 =3B =3B =3B host : ARRAY [0..255] OF CHAR=3B<= >BR> =3B =3B =3B info : Unetdb.struct_hostent_star=3B
 = >=3B =3B =3B ua =3B =3B : Uin.struct_in_addr=3B
 =3B = >BEGIN
 =3B =3B =3B IF Unix.gethostname (ADR (host[0])=2C BYT= >ESIZE (host)) # 0 THEN
 =3B =3B =3B =3B =3B IOError = >(Unexpected)=3B
 =3B =3B =3B END=3B
> =3B =3B =3B info :=3D Unetdb.gethostbyname (ADR (host[0]))=3B<= >BR> =3B =3B =3B IF info =3D NIL THEN IOError (Unexpected)=3B EN= >D=3B
 =3B =3B =3B <=3B* ASSERT info.h_length <=3B=3D BYT= >ESIZE (Address) *>=3B
> =3B =3B =3B ua :=3D LOOPHOLE(info.h_addr_list=2C
 =3B&n= >bsp=3B =3B =3B =3B =3B =3B =3B =3B =3B = >=3B =3B =3B =3B =3B =3B =3B =3B UNTRACED REF UN= >TRACED REF Uin.struct_in_addr)^^=3B
 =3B =3B =3B RETURN LOOP= >HOLE (ua.s_addr=2C Address)=3B
 =3B END GetHostAddr=3B
> =3B
> =3B
>It is again disappointing to see such code duplication.
> =3B
> =3B
>I guess =3BSameHost can duplicate the logic to predict the error state = >and return false =3Bupon error?
>Duplicating the logic for a third time. :(
> =3B
>
 =3B- Jay

>= > >--_9e67232c-a064-417d-879e-227a77e310f9_-- From jay.krell at cornell.edu Sun Jan 11 23:02:18 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Jan 2009 22:02:18 +0000 Subject: [M3devel] Juno (X) networking problem on AMD64_FREEBSD In-Reply-To: <200901111602.n0BG2IUG047813@camembert.async.caltech.edu> References: Your message of "Sun, 11 Jan 2009 12:57:13 GMT." <200901111602.n0BG2IUG047813@camembert.async.caltech.edu> Message-ID: Do you know the right way? PPC_LINUX "just worked", and I can check Solaris and Darwin. I don't want to edit /etc/hosts -- I use DHCP. Though DHCP has been bothering me -- only for some of my machines do names resolve, so I end using IP addresses, which change sometimes, and I loop over them running ssh to all of them and "see what I get", not ideal. - Jay> To: jay.krell at cornell.edu> Date: Sun, 11 Jan 2009 08:02:18 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Juno (X) networking problem on AMD64_FREEBSD> > This is a screwy thing in Modula-3. A bug I would call it.> > I've noticed a lot of networking M3 programs don't work right unless> the return value of Unix's "hostname" maps to a real IP address via> gethostbyname. I accomplish it in practice by adding my hostname> to /etc/hosts.> > This is obviously not the right way to fix it... > > Mika> > Jay writes:> >--_9e67232c-a064-417d-879e-227a77e310f9_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >Hi. Unix network programming question..> >AMD64_FREEBSD:> >$DISPLAY is set to point back to Cygwin host.It works for PPC_LINUX.> >[jay at fbsdamd64a /cm3/bin]$ ./Juno> >****** runtime error:*** Exception "IPError.FatalError" not in RAISES li=> >st*** file "../src/common/IPError.m3"=2C line 27***> >Abort trap: 6 (core dumped)[jay at fbsdamd64a /cm3/bin]$> >IP.m3:> >=20> >PROCEDURE GetHostAddr(): Address =3D VAR hname: ARRAY [0..255] OF CHAR=3B => > BEGIN LOCK mu DO IF Unix.gethostname(ADR(hname[0])=2C BYTESIZE(hna=> >me)) # 0 THEN IPError.Die ()=3B END=3B VAR h :=3D Unetdb.g=> >ethostbyname(ADR(hname[0]))=3B BEGIN IF h =3D NIL THEN IPError.Die()=> >=3B END=3B RETURN GetAddress(h)=3B END=3B END=3B END GetHos=> >tAddr=3B> >PROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Address =3D VAR ua=> >: Uin.struct_in_addr=3B BEGIN <* ASSERT ent.h_length <=3D BYTESIZE(Addr=> >ess) *> ua :=3D LOOPHOLE(ent.h_addr_list=2C UNTRACED => >REF UNTRACED REF Uin.struct_in_addr)^^=3B RETURN LOOPHOLE(ua.s_addr=2C A=> >ddress)=3B END GetAddress=3B> >=20> >gethostbyname is failing.> >=20> >Analogous C code also fails:> >=20> >[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c#include #include #i=> >nclude #include typedef struct hostent hostent_t=3B> >=20> >int main(){ char hostname[200]=3B hostent_t* h=3B int i=3B> > i =3D gethostname(hostname=2C 200)=3B assert(i =3D=3D 0)=3B printf("hostna=> >me: %s\n"=2C hostname)=3B h =3D gethostbyname(hostname)=3B herror("foo")=3B=> > printf("%p %d %d\n"=2C h=2C errno=2C h_errno)=3B assert(h)=3B return 0=3B}> >=20> >herror says "unknown host".> >Stack is:> > at ../src/runtime/ex_frame/RTExFrame.m3:58#13 0x0000000801a7f2b3 in RTH=> >ooks__Raise (M3_AJWxb1_ex=3DError accessing memory address 0x8000ffffd278: => >Bad address.) at ../src/runtime/common/RTHooks.m3:79#14 0x000000080169c8=> >d3 in IPError__Die () at ../src/common/IPError.m3:27#15 0x0000000801698a3e => >in IP__GetHostAddr (M3_BCxjPn__result=3DError accessing memory address 0x80=> >00ffffd338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x00000008012133d0=> > in XSharedMem__SameHost (M3_AQuuui_trsl=3DError accessing memory address 0=> >x8000ffffd4d8: Bad address.) at ../src/xvbt/XSharedMem.m3:96#17 0x000000=> >0801212ab7 in XSharedMem__InitXClient (M3_AQuuui_v=3DError accessing memory=> > address 0x8000ffffd648: Bad address.) at ../src/xvbt/XSharedMem.m3:29#1=> >8 0x0000000801211819 in XExtensions__InitXClient (M3_AQuuui_xclient=3DError=> > accessing memory address 0x8000ffffd7f8: Bad address.) at ../src/xvbt/X=> >Extensions.m3:14#19 0x00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst=> >=3D0x1879b=2C M3_AQuuui_trsl=3D0x6) at ../src/xvbt/XClientF.m3:583---Typ=> >e to continue=2C or q to quit---(More stack frames follow=> >...)(gdb)> >(* return TRUE if server and client are on same host *)PROCEDURE SameHost (=> >trsl: XClient.T): BOOLEAN =3D VAR display :=3D DisplayH=> >ost(trsl)=3B displayAddr: IP.Address=3B BEGIN IF display =3D NIL THE=> >N RETURN TRUE=3B END=3B> > TRY IF NOT IP.GetHostByName(display=2C displayAddr) THEN RETURN FA=> >LSE=3B END=3B RETURN displayAddr =3D IP.GetHostAddr()=3B EXCEPT => >| IP.Error =3D> RETURN FALSE=3B END=3B END SameHost=3B> >=20> >Thoughts?> >=20> >Perhaps my network isn't setup well=2C like I should add the local machine => >to /etc/hosts.I think this can be made to fail gracefully though.It seems l=> >ike it has nothing to do with AMD64_FREEBSD=2C but could have to do with Fr=> >eeBSD.> >=20> >Seems like SocketPosix has nearly the exact same code but appearsmore forgi=> >ving.. IOError instead of Fatal?> >=20> >SocketPosix.m3:> >=20> >PROCEDURE GetHostAddr (): Address RAISES {OSError.E} =3D VAR host : AR=> >RAY [0..255] OF CHAR=3B info : Unetdb.struct_hostent_star=3B ua : U=> >in.struct_in_addr=3B BEGIN IF Unix.gethostname (ADR (host[0])=2C BYTESI=> >ZE (host)) # 0 THEN IOError (Unexpected)=3B END=3B> > info :=3D Unetdb.gethostbyname (ADR (host[0]))=3B IF info =3D NIL TH=> >EN IOError (Unexpected)=3B END=3B <* ASSERT info.h_length <=3D BYTESIZE => >(Address) *>> > ua :=3D LOOPHOLE(info.h_addr_list=2C UNTRACED REF UNT=> >RACED REF Uin.struct_in_addr)^^=3B RETURN LOOPHOLE (ua.s_addr=2C Address=> >)=3B END GetHostAddr=3B> >=20> >=20> >It is again disappointing to see such code duplication.> >=20> >=20> >I guess SameHost can duplicate the logic to predict the error state and ret=> >urn false upon error?> >Duplicating the logic for a third time. :(> >=20> > - Jay=> >> >--_9e67232c-a064-417d-879e-227a77e310f9_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >> >Hi. Unix network programming question..
> >
AMD64_FREEBSD:
> >
$DISPLAY is set to point back to Cygwin host.
It works for PPC_LINUX=> >.
> >
[jay at fbsdamd64a /cm3/bin]$ ./Juno
> >
***
*** runtime error:
*** =3B =3B =3B Exception "IPE=> >rror.FatalError" not in RAISES list
*** =3B =3B =3B file "..=> >/src/common/IPError.m3"=2C line 27
***
> >
Abort trap: 6 (core dumped)
[jay at fbsdamd64a /cm3/bin]$
> >
IP.m3:
> > =3B
> >PROCEDURE GetHostAddr(): Address =3D
 =3B VAR hname: ARRAY [0..255] => OF CHAR=3B
 =3B BEGIN
 =3B =3B =3B LOCK mu DO
&nbs=> >p=3B =3B =3B =3B =3B IF Unix.gethostname(ADR(hname[0])=2C B=> >YTESIZE(hname)) # 0 THEN
 =3B =3B =3B =3B =3B => >=3B =3B IPError.Die ()=3B
 =3B =3B =3B =3B =3B E=> >ND=3B
 =3B =3B =3B =3B =3B VAR h :=3D Unetdb.gethost=> >byname(ADR(hname[0]))=3B BEGIN
 =3B =3B =3B =3B =3B&=> >nbsp=3B =3B IF h =3D NIL THEN IPError.Die()=3B END=3B
 =3B => >=3B =3B =3B =3B =3B =3B RETURN GetAddress(h)=3B
&nbs=> >p=3B =3B =3B =3B =3B END=3B
 =3B =3B =3B END=> >=3B
 =3B END GetHostAddr=3B
> >
PROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Address =3D
=> > =3B VAR ua: Uin.struct_in_addr=3B
 =3B BEGIN
 =3B => >=3B =3B <=3B* ASSERT ent.h_length <=3B=3D BYTESIZE(Address) *>=3B=> >
 =3B =3B =3B ua :=3D LOOPHOLE(ent.h_addr_list=2C
 => >=3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=> > =3B =3B =3B =3B =3B =3B =3B =3B =3B UN=> >TRACED REF UNTRACED REF Uin.struct_in_addr)^^=3B
 =3B =3B => >=3B RETURN LOOPHOLE(ua.s_addr=2C Address)=3B
 =3B END GetAddress=3B<=> >BR>> > =3B
> >gethostbyname is failing.
> >
 =3B
> >Analogous C code also fails:
> > =3B
> >
[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c
#include <=3Bassert.h>=3B >R>#include <=3Bnetdb.h>=3B
#include <=3Bstdio.h>=3B
#include => ><=3Berrno.h>=3B
typedef struct hostent hostent_t=3B
> > =3B
> >int main()
{
 =3Bchar hostname[200]=3B
 =3Bhostent_t* h=3B=> >
 =3Bint i=3B
> > =3Bi =3D gethostname(hostname=2C 200)=3B
 =3Bassert(i =3D=3D 0)=> >=3B
 =3Bprintf("hostname: %s\n"=2C hostname)=3B
 =3Bh =3D get=> >hostbyname(hostname)=3B
 =3Bherror("foo")=3B
 =3Bprintf("%p %=> >d %d\n"=2C h=2C errno=2C h_errno)=3B
 =3Bassert(h)=3B
 =3Bret=> >urn 0=3B
}
> > =3B
> >herror says "unknown host".
> >
Stack is:
> > =3B =3B =3B at ../src/runtime/ex_frame/RTExFrame.m3:58
#13 => >0x0000000801a7f2b3 in RTHooks__Raise (M3_AJWxb1_ex=3DError accessing memory=> > ad
dress 0x8000ffffd278: Bad address.
)
 =3B =3B =3B => >at ../src/runtime/common/RTHooks.m3:79
#14 0x000000080169c8d3 in IPError=> >__Die () at ../src/common/IPError.m3:27
#15 0x0000000801698a3e in IP__Ge=> >tHostAddr (M3_BCxjPn__result=3DError accessing mem
ory address 0x8000fff=> >fd338: Bad address.
)
 =3B =3B =3B at ../src/POSIX/IP.m3:=> >82
#16 0x00000008012133d0 in XSharedMem__SameHost (M3_AQuuui_trsl=3DErro=> >r accessing m
emory address 0x8000ffffd4d8: Bad address.
)
 => >=3B =3B =3B at ../src/xvbt/XSharedMem.m3:96
#17 0x0000000801212a=> >b7 in XSharedMem__InitXClient (M3_AQuuui_v=3DError accessing m
emory add=> >ress 0x8000ffffd648: Bad address.
)
 =3B =3B =3B at ../sr=> >c/xvbt/XSharedMem.m3:29
#18 0x0000000801211819 in XExtensions__InitXClie=> >nt (M3_AQuuui_xclient=3DError acce
ssing memory address 0x8000ffffd7f8: => >Bad address.
)
 =3B =3B =3B at ../src/xvbt/XExtensions.m3=> >:14
#19 0x00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst=3D0x1879=> >b=2C
 =3B =3B =3B M3_AQuuui_trsl=3D0x6) at ../src/xvbt/XClie=> >ntF.m3:583
---Type <=3Breturn>=3B to continue=2C or q <=3Breturn&g=> >t=3B to quit---
(More stack frames follow...)
(gdb)
> >
(* return TRUE if server and client are on same host *)
PROCEDURE Sa=> >meHost (trsl: XClient.T): BOOLEAN =3D
 =3B VAR
 =3B =3B&n=> >bsp=3B display =3B =3B =3B =3B =3B =3B =3B => >=3B =3B =3B =3B =3B =3B =3B =3B =3B :=3D Di=> >splayHost(trsl)=3B
 =3B =3B =3B displayAddr: IP.Address=3B >R> =3B BEGIN
 =3B =3B =3B IF display =3D NIL THEN RETURN=> > TRUE=3B END=3B
> > =3B =3B =3B TRY
 =3B =3B =3B =3B =3B IF=> > NOT IP.GetHostByName(display=2C displayAddr) THEN RETURN FALSE=3B END=3B >R> =3B =3B =3B =3B =3B RETURN displayAddr =3D IP.GetHos=> >tAddr()=3B
 =3B =3B =3B EXCEPT
 =3B =3B =3B |=> > IP.Error =3D>=3B RETURN FALSE=3B
 =3B =3B =3B END=3B
&=> >nbsp=3B END SameHost=3B
> > =3B
> >Thoughts?
> > =3B
> >
Perhaps my network isn't setup well=2C like I should add the local mach=> >ine to /etc/hosts.
I think this can be made to fail gracefully though. >R>It seems like it has nothing to do with AMD64_FREEBSD=2C but could have t=> >o do with FreeBSD.
> >
 =3B
> >Seems like SocketPosix has nearly the exact same code but appears
more f=> >orgiving.. IOError instead of Fatal?
> > =3B
> >
SocketPosix.m3:
> > =3B
> >
PROCEDURE GetHostAddr (): Address
 =3B RAISES {OSError.E} =3D >> =3B VAR
 =3B =3B =3B host : ARRAY [0..255] OF CHAR=3B<=> >BR> =3B =3B =3B info : Unetdb.struct_hostent_star=3B
 => >=3B =3B =3B ua =3B =3B : Uin.struct_in_addr=3B
 =3B => >BEGIN
 =3B =3B =3B IF Unix.gethostname (ADR (host[0])=2C BYT=> >ESIZE (host)) # 0 THEN
 =3B =3B =3B =3B =3B IOError => >(Unexpected)=3B
 =3B =3B =3B END=3B
> > =3B =3B =3B info :=3D Unetdb.gethostbyname (ADR (host[0]))=3B<=> >BR> =3B =3B =3B IF info =3D NIL THEN IOError (Unexpected)=3B EN=> >D=3B
 =3B =3B =3B <=3B* ASSERT info.h_length <=3B=3D BYT=> >ESIZE (Address) *>=3B
> > =3B =3B =3B ua :=3D LOOPHOLE(info.h_addr_list=2C
 =3B&n=> >bsp=3B =3B =3B =3B =3B =3B =3B =3B =3B => >=3B =3B =3B =3B =3B =3B =3B =3B UNTRACED REF UN=> >TRACED REF Uin.struct_in_addr)^^=3B
 =3B =3B =3B RETURN LOOP=> >HOLE (ua.s_addr=2C Address)=3B
 =3B END GetHostAddr=3B
> > =3B
> > =3B
> >It is again disappointing to see such code duplication.
> > =3B
> > =3B
> >I guess =3BSameHost can duplicate the logic to predict the error state => >and return false =3Bupon error?
> >Duplicating the logic for a third time. :(
> > =3B
> >
 =3B- Jay

> >=> >> >--_9e67232c-a064-417d-879e-227a77e310f9_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 11 23:28:08 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Jan 2009 22:28:08 +0000 Subject: [M3devel] registers and garbage collector? Message-ID: Is this a safe assumption? PROCEDURE ProcessOther (act: Activation; p: PROCEDURE (start, stop: ADDRESS)) =... IF RTMachine.GetState # NIL THEN (* process explicit state *) sp := RTMachine.GetState(act.handle, state); ELSE (* assume registers are saved in suspended thread's stack *) sp := act.sp; END; As I understand..insert question marks a bunch here: The threads are all sitting waiting in their signal handler, with a ucontext pointer...which could be in a register and not on the stack..which contains a pointer to the registers...which could be to a thread local..and not on the stack..and not in the Modula-3 heap..would be a simple matter to strengthen this..be sure to store the ucontext in a thread local (no, actually)..or somehow be sure to get it on the stack (might as well skip the ucontext and use the gregs or whatever is in it)? Storing the ucontext in a thread local doesn't work, because you can't access thread locals that aren't yours. Instead a global array would likely be needed, that the signal handlers would all store into. I'd suggest, like, storing the ucontext/gregs into a local, or maybe a volatile local in C, maybe a struct/record, but I don't think there's any guaranteeing these aren't registers, I think a global array would be the way. I guess the assumption is fairly safe, but I'm not 100% sure. No, I'm not suspecting any problem here. I was just remembering that I'd seen platform specific stuff for some platforms (Darwin) that I'd managed to avoid, somehow, and went and looked closer, see if I was legitimately avoiding it. Most platforms do avoid it. ?? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 00:22:39 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Jan 2009 23:22:39 +0000 Subject: [M3devel] AMD64_FREEBSD available Message-ID: AMD64_FREEBSD is available now at: http://modula3.elegosoft.com/cm3/uploaded-archives built native, from a clean source checkout, on the recently released 7.1 (which might not be compatible with 6.x). You'll want to maybe update cm3cfg.common from current source to remove the use of the "ROOT" variable, which isn't always defined. The system builds itself and Juno comes up (remoted to Cygwin/X). Also new LINUXLIBC6 there (they are also built regularly by the Tinderbox). SPARC32_LINUX maybe later today (the "boot" archive that is there I think is broken, but current source tree is much better, related to struct dirent). - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 00:27:34 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 11 Jan 2009 23:27:34 +0000 Subject: [M3devel] AMD64_FREEBSD available Message-ID: (oops, I think that was on a beta or RC, I need to reinstall..should be ok though) From: jay.krell at cornell.eduTo: m3devel at elegosoft.comSubject: AMD64_FREEBSD availableDate: Sun, 11 Jan 2009 23:22:39 +0000 AMD64_FREEBSD is available now at: http://modula3.elegosoft.com/cm3/uploaded-archives built native, from a clean source checkout, on the recently released 7.1 (which might not be compatible with 6.x). You'll want to maybe update cm3cfg.common from current source to remove the use of the "ROOT" variable, which isn't always defined. The system builds itself and Juno comes up (remoted to Cygwin/X). Also new LINUXLIBC6 there (they are also built regularly by the Tinderbox).SPARC32_LINUX maybe later today (the "boot" archive that is there I think is broken, but current source tree is much better, related to struct dirent). - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 01:01:16 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 11:01:16 +1100 Subject: [M3devel] making Uerror "portable"? In-Reply-To: References: Message-ID: <3D81B7DE-436C-4893-9129-EAA4E0551534@cs.purdue.edu> CONST is faster than VAR since the compiler can optimize them. Why would you want VAR? On 11 Jan 2009, at 19:58, Jay wrote: > I still find pushing the system dependencies and cloned headers out > of the system very tempting. > To reduce what it takes to port to other systems, to raise the > confidence of the correctness of any port, to keep ports correct in > the face of possible underlying change. > > I think I'll change the case statements to if/else ladders and the > consts to vars, that are actually statically initialized in C. This > treatment is reasonable for other constants that remain in the > cloned headers, system dependent or otherwise. > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: making Uerror "portable"? > Date: Thu, 8 Jan 2009 06:36:44 +0000 > > I've been thinking about "fixing" Uerror > to remove the system-dependentness of it. > > > I have about given up. > > > There are multiple easy options, but they > all have downsides that make me think it > might not be worth it. > > > today it looks like: > > > INTERFACE Uerror; > CONST > ENOFILE = 1; > ENOMEM = 2; > END Uerror; > > > The values are intended the correct native values. > There are a fair number of users. > Fewer than 10 probably. > They include switch/case statements, which require > constants. > > > The following are some of the possible changes, > that make porting to basically any future system > be a no-op in this area, except for the occasional missing or possibly > equal errnos (if there is a switch in the C code; I ran into this > case). > > > - Change to VAR and initialize them in portable C code. > disadvantages: > more startup code > possibly startup code runs too late > more writable/written data (readonly data is best) > slower to access > not constant, not switchable, not source quite compatible > You have to change the switch statements to "if ladders" (if/ > elseif/elseif/elseif). > Compatible with most source, and incompatible source easily > fixed. > possible issues around "dynamic linking data" (not explained > here, ask?) > However not really a problem. More of a problem only on NT, and > easily worked > around just like is done for hand.obj. > > > - change to VAR and const static initialize them in portable C "data" > no additional startup code -- guaranteed initialized early enough > no writable/written data > slower to access > not constant, not switchable, not source compatible (same as > previous) > same non-issue around dynamic linking of data > > > - change to functions GetENOFILE(), GetENOMEM(), etc. > slower to access > definitely no problem dynamic linking > easier to write the C code/data, no matter, the above > are easy enough > not constant, not switchable, not source compatible (similar to > previous) > > > - "translation"; introduce our own arbitrary values for > any errno the system uses; change Cerrno.GetErrno to have > a switch and translate from the native values to ours. > > > This is fully source compatible, dynamic link compatible, > in-between perf wise (slower to GetErrnor, but then constant > and just as comparable/switchable), no initialization cost. > > > Question then though what does any raised exception look like? > Do the values get translated back? Or translated to strings? > SetErrno translates back? > > > Translation is at first simple and is unique among portable > solutions > in its source compatibility, but I am leary of it. I would > rather a solution that traffics in unmodified native errnos > values, but > I don't that is viable with both constness and portability. > > > To a large extent, translation is ok. If you look at > SocketPosix.i3, it > uses the errno very briefly to determine the next step to take. > I don't think > it ever returns or RAISEs it (or an exception containing it). > > But other parts of the system Fmt.Int(errno) and raise that, thus > these become values that move through more of the system and > therefore > disagreement with the underlying system might show through. > > > There is also question of how to chose "Max". Set it large, like > 200? > Set it "correctly"? Probably a better option is to make the cache > that is currently Max-sized be instead small and fixed-size (e.g. > 64), > and "search" it quickly instead of "indexing" it very quickly, and > always > kick out the least recently used. I also have to check what the > contents actually are, perhaps they are constant-initializable. > > > Thoughts? > > > I was somewhat keen to do something here, but have pretty much > given up and > will just generate Uerror.i3 for Solaris, NetBSD, FreeBSD, AIX, > Irix, HP-UX, etc.. > I might still be able to remove the Usignal and Ustat system- > dependentness > in m3core/src/unix, but Uerror will probably stand asis (in linux- > common, > openbsd-common, cygwin). > > > In particular, I was putting off any more ports till I got the > amount of work needed > to port reduced to my satisfaction. I think I'm nearly there. > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 01:03:33 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 11:03:33 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> Message-ID: <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> Jay, Can you remind me again why Cygwin was unable to use pthreads? It seems you have introduced a bunch of hair into the PTHREADS implementation to deal with broken Cygwin pthreads. As many of us have already pointed out, Cygwin should be a port that tries as much as possible to be like a standard POSIX platform (pthread-based) as opposed to a weird Windows/POSIX hybrid. I have a bunch of code that will be going into the PTHREADS base that I am now at a loss to integrate with the changes you have made. Help! -- Tony From hosking at cs.purdue.edu Mon Jan 12 01:12:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 11:12:36 +1100 Subject: [M3devel] ThreadPThread (PTHREAD) In-Reply-To: <20090111233442.57DE510D5FB1@birch.elegosoft.com> References: <20090111233442.57DE510D5FB1@birch.elegosoft.com> Message-ID: <23468C51-9108-4131-9B12-6BDA68AA648E@cs.purdue.edu> Jay, can you give me a sense of what the purpose of your recent changes to the pthread-based threading code are intended to achieve? I haven't been able to follow too closely all the changes you are making, and I would like some sort of high-level rationale to help me understand. Also, if sysutils has thread-dependent stuff in it then I suggest sysutils should be rewritten to call the thread code rather than re-implement. m3core is a library that is always linked, so sysutils could easily depend on it. What's the problem? From hosking at cs.purdue.edu Mon Jan 12 01:13:00 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 11:13:00 +1100 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: References: Message-ID: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> What's wrong with using ADDRESS for references to opaque values? If sigset_t is never instantiated in Modula-3, then why do you need it declared there? 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 01:44, Jay wrote: > Is there a way in Modula-3 to declare that a type exists, and there > are <*external*> instances of it, without "fully" declaring it, so > that no Modula-3 can instantiate it? > > I have done this for sigset_t and sem_t, but they could erroneously > be instantiated by Modula-3 and I'd like to remove that ability to > mess up so easily. > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sigset_t = RECORD END; > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sem_t = RECORD END; > > In C I believe you can do this, like: > typedef struct foo foo_t; > extern foo_t foo; > > void UseFoo(foo_t*); > foo_t* GetFoo(void); > > Thanks, > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 01:55:16 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 00:55:16 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> Message-ID: I considered ADDRESS. However I think it still doesn't satisfy. I want to be able to do this: TYPE Foo_t = something; <* EXTERNAL *> VAR Foo1, Foo2:Foo_t; <* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); (* Modula-3, not external *) PROCEDURE x()= BEGIN UseFoo(Foo1); UseFoo(Foo2); END x; AND I want any use of: VAR Foo3:Foo3_t; (* Modula-3, not external *) to error. This is sem_t and sigset_t in particular. Possibly renaming is the thing. They used to be declared in Modula-3, system-dependently, but I moved them to portable C. I could remove the types entirely and change UseFoo to take an address, and declare mask and ackSem to be integers or I guess. <*EXTERNAL> VAR ackSem : RECORD END; That would satisfy but I thought it might be nicer to still provide the named types to refer to the external variables. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?What's wrong with using ADDRESS for references to opaque values? If sigset_t is never instantiated in Modula-3, then why do you need it declared there? 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 01:44, Jay wrote: Is there a way in Modula-3 to declare that a type exists, and there are <*external*> instances of it, without "fully" declaring it, so that no Modula-3 can instantiate it? I have done this for sigset_t and sem_t, but they could erroneously be instantiated by Modula-3 and I'd like to remove that ability to mess up so easily. (* This type is not declared correctly. It is only instantiated in C code. *) sigset_t = RECORD END;(* This type is not declared correctly. It is only instantiated in C code. *) sem_t = RECORD END;In C I believe you can do this, like: typedef struct foo foo_t; extern foo_t foo; void UseFoo(foo_t*); foo_t* GetFoo(void); Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 01:13:10 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 11:13:10 +1100 Subject: [M3devel] registers and garbage collector? In-Reply-To: References: Message-ID: <60C81864-8A4F-4A5F-B4FC-434FAB9F8919@cs.purdue.edu> Yes, this is safe. Some platforms require that we account for the red- zone, but generally the registers have been saved on the stack in the signal handler frame. I do not want to go the global array route that you suggest -- no need and very slow! On 12 Jan 2009, at 09:28, Jay wrote: > Is this a safe assumption? > > > PROCEDURE ProcessOther (act: Activation; p: PROCEDURE (start, stop: > ADDRESS)) = > ... > IF RTMachine.GetState # NIL THEN > (* process explicit state *) > sp := RTMachine.GetState(act.handle, state); > ELSE > (* assume registers are saved in suspended thread's stack *) > sp := act.sp; > END; > > > As I understand..insert question marks a bunch here: > > > The threads are all sitting waiting in their signal handler, with a > ucontext pointer...which could be in a register and not on the > stack..which contains a pointer to the registers...which could be to > a thread local..and not on the stack..and not in the Modula-3 > heap..would be a simple matter to strengthen this..be sure to store > the ucontext in a thread local (no, actually)..or somehow be sure to > get it on the stack (might as well skip the ucontext and use the > gregs or whatever is in it)? > Storing the ucontext in a thread local doesn't work, because you > can't access thread locals that aren't yours. Instead a global array > would likely be needed, that the signal handlers would all store > into. I'd suggest, like, storing the ucontext/gregs into a local, or > maybe a volatile local in C, maybe a struct/record, but I don't > think there's any guaranteeing these aren't registers, I think a > global array would be the way. > I guess the assumption is fairly safe, but I'm not 100% sure. > No, I'm not suspecting any problem here. I was just remembering that > I'd seen platform specific stuff for some platforms (Darwin) that > I'd managed to avoid, somehow, and went and looked closer, see if I > was legitimately avoiding it. Most platforms do avoid it. > > ?? > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 02:04:12 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 01:04:12 +0000 Subject: [M3devel] ThreadPThread (PTHREAD) In-Reply-To: <23468C51-9108-4131-9B12-6BDA68AA648E@cs.purdue.edu> References: <20090111233442.57DE510D5FB1@birch.elegosoft.com> <23468C51-9108-4131-9B12-6BDA68AA648E@cs.purdue.edu> Message-ID: Yes I can explain mostly. I was not able to get Cygwin/pthreads to work. I don't know why. I could try another round of debugging. It was a while ago, like a year ago. I did debug it on some depth, rebuilding cygwin1.dll, and such. I was inclined to give up. Consensus at the time was people didn't really care. As long as they had forward slashes (which are abstracted from code, but not from the user..and slow fork..), and Modula-3 abstracted threads, no matter how the Modula-3 threads were impelented. So Cygwin uses Win32 threads. More recently..well, it bothered me slightly that the "wait" code was duplicated, but that's very little code. In looking at it though, I realized that Cygwin didn't have a proper SchedulerPosix, which I think is an abstraction of select(). What I did is move the SchedulerPosix code out of ThreadPThread. This way it can be reused against ThreadPThread or ThreadWin32. It is a fairly mechanical change, with no real semantic change. I realize that movement of code from one file to another is hard to track though using simple text methods. The stuff around "WaitPidYields" is what got me looking here and has some value, but I think giving Cygwin a proper SchedulerPosix is more valuable. WaitPidYields is contorted because sysutils bootstraps against old m3core, and I strongly suspect that sysutils exposes essentially a different variant of m3core's abstractions, and cannot be implemented on top of it. That m3core hides too much for sysutils. If we bump up the minimum m3core that we build from, the contortions can go away. "contortions" == "quake generating Modula-3 code, with different names per client". Make sense? - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:12:36 +1100> CC: m3devel at elegosoft.com> Subject: [M3devel] ThreadPThread (PTHREAD)> > Jay, can you give me a sense of what the purpose of your recent > changes to the pthread-based threading code are intended to achieve? > I haven't been able to follow too closely all the changes you are > making, and I would like some sort of high-level rationale to help me > understand. Also, if sysutils has thread-dependent stuff in it then I > suggest sysutils should be rewritten to call the thread code rather > than re-implement. m3core is a library that is always linked, so > sysutils could easily depend on it. What's the problem?> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 02:09:52 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 01:09:52 +0000 Subject: [M3devel] making Uerror "portable"? In-Reply-To: <118F7713-A9E8-441C-90EF-8D255C386078@cs.purdue.edu> References: <118F7713-A9E8-441C-90EF-8D255C386078@cs.purdue.edu> Message-ID: Understood. So I can remove Uerror's system-dependentness. in place of CONST EFOO =1, EBAR = 2; I want: <*EXTERNAL*> (*const*) VAR EFOO, EBAR:int; UerrorC.c: #include enum { eEFOO = EFOO, eEBAR = EBAR }; const Max = sizeof(union { char a[EFOO]; char b[EBAR]; }); #undef EFOO #undef EBAR const EFOO = eEFOO; const EBAR = eEBAR; Very much like that. ok? I was probably going to do this tonight for cygwin/openbsd/amd64. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] making Uerror "portable"?Date: Mon, 12 Jan 2009 11:13:16 +1100 CONST is faster than VAR since the compiler can optimize them. Why would you want VAR? On 11 Jan 2009, at 19:58, Jay wrote: I still find pushing the system dependencies and cloned headers out of the system very tempting. To reduce what it takes to port to other systems, to raise the confidence of the correctness of any port, to keep ports correct in the face of possible underlying change. I think I'll change the case statements to if/else ladders and the consts to vars, that are actually statically initialized in C. This treatment is reasonable for other constants that remain in the cloned headers, system dependent or otherwise. - Jay From: jay.krell at cornell.eduTo: m3devel at elegosoft.comSubject: making Uerror "portable"?Date: Thu, 8 Jan 2009 06:36:44 +0000I've been thinking about "fixing" Uerrorto remove the system-dependentness of it. I have about given up. There are multiple easy options, but theyall have downsides that make me think itmight not be worth it. today it looks like: INTERFACE Uerror;CONST ENOFILE = 1; ENOMEM = 2;END Uerror; The values are intended the correct native values.There are a fair number of users.Fewer than 10 probably.They include switch/case statements, which requireconstants. The following are some of the possible changes,that make porting to basically any future systembe a no-op in this area, except for the occasional missing or possiblyequal errnos (if there is a switch in the C code; I ran into this case). - Change to VAR and initialize them in portable C code. disadvantages: more startup code possibly startup code runs too late more writable/written data (readonly data is best) slower to access not constant, not switchable, not source quite compatible You have to change the switch statements to "if ladders" (if/elseif/elseif/elseif). Compatible with most source, and incompatible source easily fixed. possible issues around "dynamic linking data" (not explained here, ask?) However not really a problem. More of a problem only on NT, and easily worked around just like is done for hand.obj. - change to VAR and const static initialize them in portable C "data" no additional startup code -- guaranteed initialized early enough no writable/written data slower to access not constant, not switchable, not source compatible (same as previous) same non-issue around dynamic linking of data - change to functions GetENOFILE(), GetENOMEM(), etc. slower to access definitely no problem dynamic linking easier to write the C code/data, no matter, the above are easy enough not constant, not switchable, not source compatible (similar to previous) - "translation"; introduce our own arbitrary values for any errno the system uses; change Cerrno.GetErrno to have a switch and translate from the native values to ours. This is fully source compatible, dynamic link compatible, in-between perf wise (slower to GetErrnor, but then constant and just as comparable/switchable), no initialization cost. Question then though what does any raised exception look like? Do the values get translated back? Or translated to strings? SetErrno translates back? Translation is at first simple and is unique among portable solutions in its source compatibility, but I am leary of it. I would rather a solution that traffics in unmodified native errnos values, but I don't that is viable with both constness and portability. To a large extent, translation is ok. If you look at SocketPosix.i3, it uses the errno very briefly to determine the next step to take. I don't think it ever returns or RAISEs it (or an exception containing it). But other parts of the system Fmt.Int(errno) and raise that, thus these become values that move through more of the system and therefore disagreement with the underlying system might show through. There is also question of how to chose "Max". Set it large, like 200? Set it "correctly"? Probably a better option is to make the cache that is currently Max-sized be instead small and fixed-size (e.g. 64), and "search" it quickly instead of "indexing" it very quickly, and always kick out the least recently used. I also have to check what the contents actually are, perhaps they are constant-initializable. Thoughts? I was somewhat keen to do something here, but have pretty much given up and will just generate Uerror.i3 for Solaris, NetBSD, FreeBSD, AIX, Irix, HP-UX, etc.. I might still be able to remove the Usignal and Ustat system-dependentness in m3core/src/unix, but Uerror will probably stand asis (in linux-common, openbsd-common, cygwin). In particular, I was putting off any more ports till I got the amount of work neededto port reduced to my satisfaction. I think I'm nearly there. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 02:19:35 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 01:19:35 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> Message-ID: btw, I don't think it's that hairy, I merely split it into two or three files, and added interfaces so they can reuse code with each other. Movement between files is hard to track though (depending on version control, but with all I've used). The SchedulerPosix implementation moved to ThreadPScheduler.m3. What is shared between it and ThreadPThread/Win32.m3 is ThreadInternal.i3, which maybe should be in ThreadF.i3, though that's exposed outside m3core, and ThreadInternal.i3 includes a variable. I can try again to debug Cygwin pthreads though. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:03:33 +1100> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Jay,> > Can you remind me again why Cygwin was unable to use pthreads? It > seems you have introduced a bunch of hair into the PTHREADS > implementation to deal with broken Cygwin pthreads. As many of us > have already pointed out, Cygwin should be a port that tries as much > as possible to be like a standard POSIX platform (pthread-based) as > opposed to a weird Windows/POSIX hybrid.> > I have a bunch of code that will be going into the PTHREADS base that > I am now at a loss to integrate with the changes you have made.> > Help!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 02:35:32 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 12:35:32 +1100 Subject: [M3devel] making Uerror "portable"? In-Reply-To: References: <118F7713-A9E8-441C-90EF-8D255C386078@cs.purdue.edu> Message-ID: On 12 Jan 2009, at 12:09, Jay wrote: > Understood. > So I can remove Uerror's system-dependentness. > > > in place of > CONST EFOO =1, EBAR = 2; > > I want: > > <*EXTERNAL*> (*const*) VAR EFOO, EBAR:int; This is gross. Again, if they are constants in C they should be constants in Modula-3. To reiterate: I think your contortions to eliminate C-header-file cloning are distorting the Modula-3 code in ways that make it much less transparent. Can we please revert some of these bad design decisions? > UerrorC.c: > #include > enum { eEFOO = EFOO, eEBAR = EBAR }; > const Max = sizeof(union { char a[EFOO]; char b[EBAR]; }); > #undef EFOO > #undef EBAR > const EFOO = eEFOO; > const EBAR = eEBAR; > > Very much like that. > ok? I was probably going to do this tonight for cygwin/openbsd/amd64. > > - Jay > > > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] making Uerror "portable"? > Date: Mon, 12 Jan 2009 11:13:16 +1100 > > > CONST is faster than VAR since the compiler can optimize them. Why > would you want VAR? > > On 11 Jan 2009, at 19:58, Jay wrote: > > I still find pushing the system dependencies and cloned headers out > of the system very tempting. > To reduce what it takes to port to other systems, to raise the > confidence of the correctness of any port, to keep ports correct in > the face of possible underlying change. > > I think I'll change the case statements to if/else ladders and the > consts to vars, that are actually statically initialized in C. This > treatment is reasonable for other constants that remain in the > cloned headers, system dependent or otherwise. > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: making Uerror "portable"? > Date: Thu, 8 Jan 2009 06:36:44 +0000 > > I've been thinking about "fixing" Uerror > to remove the system-dependentness of it. > > > I have about given up. > > > There are multiple easy options, but they > all have downsides that make me think it > might not be worth it. > > > today it looks like: > > > INTERFACE Uerror; > CONST > ENOFILE = 1; > ENOMEM = 2; > END Uerror; > > > The values are intended the correct native values. > There are a fair number of users. > Fewer than 10 probably. > They include switch/case statements, which require > constants. > > > The following are some of the possible changes, > that make porting to basically any future system > be a no-op in this area, except for the occasional missing or possibly > equal errnos (if there is a switch in the C code; I ran into this > case). > > > - Change to VAR and initialize them in portable C code. > disadvantages: > more startup code > possibly startup code runs too late > more writable/written data (readonly data is best) > slower to access > not constant, not switchable, not source quite compatible > You have to change the switch statements to "if ladders" (if/ > elseif/elseif/elseif). > Compatible with most source, and incompatible source easily > fixed. > possible issues around "dynamic linking data" (not explained > here, ask?) > However not really a problem. More of a problem only on NT, and > easily worked > around just like is done for hand.obj. > > > - change to VAR and const static initialize them in portable C "data" > no additional startup code -- guaranteed initialized early enough > no writable/written data > slower to access > not constant, not switchable, not source compatible (same as > previous) > same non-issue around dynamic linking of data > > > - change to functions GetENOFILE(), GetENOMEM(), etc. > slower to access > definitely no problem dynamic linking > easier to write the C code/data, no matter, the above > are easy enough > not constant, not switchable, not source compatible (similar to > previous) > > > - "translation"; introduce our own arbitrary values for > any errno the system uses; change Cerrno.GetErrno to have > a switch and translate from the native values to ours. > > > This is fully source compatible, dynamic link compatible, > in-between perf wise (slower to GetErrnor, but then constant > and just as comparable/switchable), no initialization cost. > > > Question then though what does any raised exception look like? > Do the values get translated back? Or translated to strings? > SetErrno translates back? > > > Translation is at first simple and is unique among portable > solutions > in its source compatibility, but I am leary of it. I would > rather a solution that traffics in unmodified native errnos > values, but > I don't that is viable with both constness and portability. > > > To a large extent, translation is ok. If you look at > SocketPosix.i3, it > uses the errno very briefly to determine the next step to take. > I don't think > it ever returns or RAISEs it (or an exception containing it). > > But other parts of the system Fmt.Int(errno) and raise that, thus > these become values that move through more of the system and > therefore > disagreement with the underlying system might show through. > > > There is also question of how to chose "Max". Set it large, like > 200? > Set it "correctly"? Probably a better option is to make the cache > that is currently Max-sized be instead small and fixed-size (e.g. > 64), > and "search" it quickly instead of "indexing" it very quickly, and > always > kick out the least recently used. I also have to check what the > contents actually are, perhaps they are constant-initializable. > > > Thoughts? > > > I was somewhat keen to do something here, but have pretty much > given up and > will just generate Uerror.i3 for Solaris, NetBSD, FreeBSD, AIX, > Irix, HP-UX, etc.. > I might still be able to remove the Usignal and Ustat system- > dependentness > in m3core/src/unix, but Uerror will probably stand asis (in linux- > common, > openbsd-common, cygwin). > > > In particular, I was putting off any more ports till I got the > amount of work needed > to port reduced to my satisfaction. I think I'm nearly there. > > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 02:32:15 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 12:32:15 +1100 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> Message-ID: <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> Jay, I really think you are bending over backwards too far just to be able to shoe-horn things into C. I *like* having the transpar of C header files expressed in Modula-3, *particularly* for system calls, where you might even be trying to build on a system that does not have the C header files installed, even though the libraries exist and can be linked to. Fundamentally, I think anytime the Modula-3 code is made less transparent you should think hard about what you are doing. The same with the change of constants to variables. I am getting very nervous that the changes you are making are destroying the clarity of the Modula-3 run-time code. In this particular case, you are wanting to use a Modula-3 parameter passing mechanism on something that is not declared in Modula-3. Seems kind of dubious to me. Also, I really don't like the idea of accessing external variables in C. -- Tony On 12 Jan 2009, at 11:55, Jay wrote: > I considered ADDRESS. > However I think it still doesn't satisfy. > > I want to be able to do this: > > TYPE Foo_t = something; > <* EXTERNAL *> VAR Foo1, Foo2:Foo_t; > <* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); > > (* Modula-3, not external *) > PROCEDURE x()= > BEGIN > UseFoo(Foo1); > UseFoo(Foo2); > END x; > > AND I want any use of: > VAR Foo3:Foo3_t; (* Modula-3, not external *) > > to error. This is sem_t and sigset_t in particular. > > Possibly renaming is the thing. > They used to be declared in Modula-3, system-dependently, but > I moved them to portable C. > > I could remove the types entirely and change UseFoo to take an > address, > and declare mask and ackSem to be integers or I guess. > <*EXTERNAL> VAR ackSem : RECORD END; > > That would satisfy but I thought it might be nicer to still provide > the named > types to refer to the external variables. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 11:13:00 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > > What's wrong with using ADDRESS for references to opaque values? If > sigset_t is never instantiated in Modula-3, then why do you need it > declared there? > > 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 01:44, Jay wrote: > > Is there a way in Modula-3 to declare that a type exists, and there > are <*external*> instances of it, without "fully" declaring it, so > that no Modula-3 can instantiate it? > > I have done this for sigset_t and sem_t, but they could erroneously > be instantiated by Modula-3 and I'd like to remove that ability to > mess up so easily. > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sigset_t = RECORD END; > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sem_t = RECORD END; > > In C I believe you can do this, like: > typedef struct foo foo_t; > extern foo_t foo; > > void UseFoo(foo_t*); > foo_t* GetFoo(void); > > Thanks, > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 02:42:39 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 12:42:39 +1100 Subject: [M3devel] ThreadPThread (PTHREAD) In-Reply-To: References: <20090111233442.57DE510D5FB1@birch.elegosoft.com> <23468C51-9108-4131-9B12-6BDA68AA648E@cs.purdue.edu> Message-ID: <45DAF3DE-F1E6-47C5-A113-BD94776197F9@cs.purdue.edu> On 12 Jan 2009, at 12:04, Jay wrote: > Yes I can explain mostly. > > > I was not able to get Cygwin/pthreads to work. > I don't know why. I could try another round of debugging. > It was a while ago, like a year ago. > I did debug it on some depth, rebuilding cygwin1.dll, and such. > I was inclined to give up. But now you are distorting the whole threads subsystem to work around a bug. Sounds screwy to me. > Consensus at the time was people didn't really care. > As long as they had forward slashes (which are abstracted > from code, but not from the user..and slow fork..), > and Modula-3 abstracted threads, > no matter how the Modula-3 threads were impelented. I care if the threads system becomes a tangled mess. > So Cygwin uses Win32 threads. Fine insofar as the implementation is hidden. But then you go on and try to impose POSIX thread semantics (for waitpid and friends) [as far as I understand things] onto a Win32 threads implementation. Weird. > More recently..well, it bothered me slightly that the "wait" code was > duplicated, but that's very little code. In looking at it though, I > realized > that Cygwin didn't have a proper SchedulerPosix, which I think is > an abstraction of select(). > > > What I did is move the SchedulerPosix code out of ThreadPThread. > This way it can be reused against ThreadPThread or ThreadWin32. Does this even make sense? > It is a fairly mechanical change, with no real semantic change. > I realize that movement of code from one file to another is hard to > track though > using simple text methods. > > > The stuff around "WaitPidYields" is what got me looking here and > has some value, but I think giving Cygwin a proper SchedulerPosix > is more valuable. I don't know what this comment refers to. Can you give a high-level overview? > WaitPidYields is contorted because sysutils bootstraps against old > m3core, > and I strongly suspect that sysutils exposes essentially a different > variant of m3core's abstractions, and cannot be implemented on top > of it. > That m3core hides too much for sysutils. sysutils is a *hack* that needs to be fixed so as not to expose m3core abstractions. It is only used in a very few places, and we would be much better situated if we figured out what functionality is needed by clients of sysutils rather than breaking m3core to let sysutils in on things. > If we bump up the minimum m3core that we build from, the contortions > can go away. "contortions" == "quake generating Modula-3 code, > with different names per client". What do you propose? What is the "minimum m3core"? What do we need to add to it? > > > > Make sense? > > - Jay > > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:12:36 +1100 > > CC: m3devel at elegosoft.com > > Subject: [M3devel] ThreadPThread (PTHREAD) > > > > Jay, can you give me a sense of what the purpose of your recent > > changes to the pthread-based threading code are intended to achieve? > > I haven't been able to follow too closely all the changes you are > > making, and I would like some sort of high-level rationale to help > me > > understand. Also, if sysutils has thread-dependent stuff in it > then I > > suggest sysutils should be rewritten to call the thread code rather > > than re-implement. m3core is a library that is always linked, so > > sysutils could easily depend on it. What's the problem? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 02:46:54 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 12:46:54 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> Message-ID: <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> You are smearing implementation details across multiple files and directories. Up until now, ThreadPThread has been nicely self- contained, and captured all the basic pieces of the thread implementation. Also, how does all of this fit with the ThreadPosix implementation? On 12 Jan 2009, at 12:19, Jay wrote: > btw, I don't think it's that hairy, I merely split it into two or > three files, and added interfaces so they can reuse code with each > other. Movement between files is hard to track though (depending on > version control, but with all I've used). > > The SchedulerPosix implementation moved to ThreadPScheduler.m3. > What is shared between it and ThreadPThread/Win32.m3 is > ThreadInternal.i3, which maybe should be in ThreadF.i3, though > that's exposed outside m3core, and ThreadInternal.i3 includes a > variable. > > I can try again to debug Cygwin pthreads though. > > - Jay > > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:03:33 +1100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay, > > > > Can you remind me again why Cygwin was unable to use pthreads? It > > seems you have introduced a bunch of hair into the PTHREADS > > implementation to deal with broken Cygwin pthreads. As many of us > > have already pointed out, Cygwin should be a port that tries as much > > as possible to be like a standard POSIX platform (pthread-based) as > > opposed to a weird Windows/POSIX hybrid. > > > > I have a bunch of code that will be going into the PTHREADS base > that > > I am now at a loss to integrate with the changes you have made. > > > > Help! > > > > -- Tony > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 01:13:16 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 11:13:16 +1100 Subject: [M3devel] making Uerror "portable"? In-Reply-To: References: Message-ID: <118F7713-A9E8-441C-90EF-8D255C386078@cs.purdue.edu> CONST is faster than VAR since the compiler can optimize them. Why would you want VAR? On 11 Jan 2009, at 19:58, Jay wrote: > I still find pushing the system dependencies and cloned headers out > of the system very tempting. > To reduce what it takes to port to other systems, to raise the > confidence of the correctness of any port, to keep ports correct in > the face of possible underlying change. > > I think I'll change the case statements to if/else ladders and the > consts to vars, that are actually statically initialized in C. This > treatment is reasonable for other constants that remain in the > cloned headers, system dependent or otherwise. > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: making Uerror "portable"? > Date: Thu, 8 Jan 2009 06:36:44 +0000 > > I've been thinking about "fixing" Uerror > to remove the system-dependentness of it. > > > I have about given up. > > > There are multiple easy options, but they > all have downsides that make me think it > might not be worth it. > > > today it looks like: > > > INTERFACE Uerror; > CONST > ENOFILE = 1; > ENOMEM = 2; > END Uerror; > > > The values are intended the correct native values. > There are a fair number of users. > Fewer than 10 probably. > They include switch/case statements, which require > constants. > > > The following are some of the possible changes, > that make porting to basically any future system > be a no-op in this area, except for the occasional missing or possibly > equal errnos (if there is a switch in the C code; I ran into this > case). > > > - Change to VAR and initialize them in portable C code. > disadvantages: > more startup code > possibly startup code runs too late > more writable/written data (readonly data is best) > slower to access > not constant, not switchable, not source quite compatible > You have to change the switch statements to "if ladders" (if/ > elseif/elseif/elseif). > Compatible with most source, and incompatible source easily > fixed. > possible issues around "dynamic linking data" (not explained > here, ask?) > However not really a problem. More of a problem only on NT, and > easily worked > around just like is done for hand.obj. > > > - change to VAR and const static initialize them in portable C "data" > no additional startup code -- guaranteed initialized early enough > no writable/written data > slower to access > not constant, not switchable, not source compatible (same as > previous) > same non-issue around dynamic linking of data > > > - change to functions GetENOFILE(), GetENOMEM(), etc. > slower to access > definitely no problem dynamic linking > easier to write the C code/data, no matter, the above > are easy enough > not constant, not switchable, not source compatible (similar to > previous) > > > - "translation"; introduce our own arbitrary values for > any errno the system uses; change Cerrno.GetErrno to have > a switch and translate from the native values to ours. > > > This is fully source compatible, dynamic link compatible, > in-between perf wise (slower to GetErrnor, but then constant > and just as comparable/switchable), no initialization cost. > > > Question then though what does any raised exception look like? > Do the values get translated back? Or translated to strings? > SetErrno translates back? > > > Translation is at first simple and is unique among portable > solutions > in its source compatibility, but I am leary of it. I would > rather a solution that traffics in unmodified native errnos > values, but > I don't that is viable with both constness and portability. > > > To a large extent, translation is ok. If you look at > SocketPosix.i3, it > uses the errno very briefly to determine the next step to take. > I don't think > it ever returns or RAISEs it (or an exception containing it). > > But other parts of the system Fmt.Int(errno) and raise that, thus > these become values that move through more of the system and > therefore > disagreement with the underlying system might show through. > > > There is also question of how to chose "Max". Set it large, like > 200? > Set it "correctly"? Probably a better option is to make the cache > that is currently Max-sized be instead small and fixed-size (e.g. > 64), > and "search" it quickly instead of "indexing" it very quickly, and > always > kick out the least recently used. I also have to check what the > contents actually are, perhaps they are constant-initializable. > > > Thoughts? > > > I was somewhat keen to do something here, but have pretty much > given up and > will just generate Uerror.i3 for Solaris, NetBSD, FreeBSD, AIX, > Irix, HP-UX, etc.. > I might still be able to remove the Usignal and Ustat system- > dependentness > in m3core/src/unix, but Uerror will probably stand asis (in linux- > common, > openbsd-common, cygwin). > > > In particular, I was putting off any more ports till I got the > amount of work needed > to port reduced to my satisfaction. I think I'm nearly there. > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: [M3devel] [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 hosking at cs.purdue.edu Mon Jan 12 05:27:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 15:27:07 +1100 Subject: [M3devel] waitpid contortions Message-ID: <055997B8-7083-4DF6-A373-D2BF3E4351BC@cs.purdue.edu> Jay, To avoid your contortions surrounding usage of waitpid in sysutils, I propose the following. Implement ThreadPosix.WaitProcess as a thing wrapper over waitpid: PROCEDURE WaitProcess (pid: int; VAR status: int): int = (* ThreadPThread.m3 and ThreadPosix.m3 are very similar. *) BEGIN LOOP WITH r = Uexec.waitpid(pid, ADR(status), 0) DO <*ASSERT r # 0*> IF r > 0 THEN RETURN r END; IF Cerrno.GetErrno() # Uerror.EINTR THEN RETURN r END; END; END; END WaitProcess; Implement Process.Wait as it used to be originally, calling SchedulerPosix.WaitProcess instead of waitpid. Implement SystemPosix.Wait using SchedulerPosix.Wait to throw exceptions as defined in the original code. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 05:46:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 15:46:34 +1100 Subject: [M3devel] waitpid Message-ID: Does anyone know why the SchedulerPosix.Wait code (which originally came from ProcessPosix.m3 and is similar in SystemPosix.m3) was doing strange unpacking of the status word returned from waitpid? It seems to be unnecessary when waitpid is typed as: int waitpid (pid_t pid, int *status, int options) From jay.krell at cornell.edu Mon Jan 12 07:39:26 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 06:39:26 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: ThreadPosix is basically unaffected -- I never provided user threads on Cygwin. I guess it got a slight reduction regarding DoesWaitPidYield, but its SchedulerPosix implementation was unchanged. The code in ThreadPosix is similar to but different than ThreadPThread. It is possible they could be merged but it wasn't trivial so I left ThreadPosix alone. > You are smearing implementation details across multiple files and directories You really think it is bad to have SchedulerPosix implemented in a small separate file? On top of what happens to be common implementation details of ThreadPThread.m3 and ThreadWin32.m3? ThreadPScheduler.m3 is just basically three functions: IOWait, IOAlertWait, XIOWait Plus the little internal utility, UTimeFromTime, the one liner DoesWaitPidYield, and non-trivial functions nested in XIOWait: TestFDS, CallSelect. I mean, you know, an alternative is to copy out very large chunks of ThreadWin32.m3 and ThreadPThread.m3 and merge them into ThreadCygwin.m3. That would be worse imho. "Directories" hardly. Or I can try debugging cygwin pthreads again. - Jay CC: jkrell at elego.de; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 12:46:54 +1100You are smearing implementation details across multiple files and directories. Up until now, ThreadPThread has been nicely self-contained, and captured all the basic pieces of the thread implementation. Also, how does all of this fit with the ThreadPosix implementation? On 12 Jan 2009, at 12:19, Jay wrote: btw, I don't think it's that hairy, I merely split it into two or three files, and added interfaces so they can reuse code with each other. Movement between files is hard to track though (depending on version control, but with all I've used). The SchedulerPosix implementation moved to ThreadPScheduler.m3.What is shared between it and ThreadPThread/Win32.m3 is ThreadInternal.i3, which maybe should be in ThreadF.i3, though that's exposed outside m3core, and ThreadInternal.i3 includes a variable. I can try again to debug Cygwin pthreads though. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:03:33 +1100> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Jay,> > Can you remind me again why Cygwin was unable to use pthreads? It > seems you have introduced a bunch of hair into the PTHREADS > implementation to deal with broken Cygwin pthreads. As many of us > have already pointed out, Cygwin should be a port that tries as much > as possible to be like a standard POSIX platform (pthread-based) as > opposed to a weird Windows/POSIX hybrid.> > I have a bunch of code that will be going into the PTHREADS base that > I am now at a loss to integrate with the changes you have made.> > Help!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: [M3devel] [M3commit] 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: [M3devel] [M3commit] 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 hosking at cs.purdue.edu Mon Jan 12 07:53:02 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 17:53:02 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: Why does sysutils need to be compatible with both old and new versions of m3core? On 12 Jan 2009, at 17:39, Jay wrote: > ThreadPosix is basically unaffected -- I never provided user threads > on Cygwin. > I guess it got a slight reduction regarding DoesWaitPidYield, but > its SchedulerPosix implementation was unchanged. > > The code in ThreadPosix is similar to but different than > ThreadPThread. > It is possible they could be merged but it wasn't trivial so I left > ThreadPosix alone. > > > You are smearing implementation details across multiple files and > directories > > You really think it is bad to have SchedulerPosix implemented in a > small separate file? > On top of what happens to be common implementation details of > ThreadPThread.m3 and ThreadWin32.m3? > > ThreadPScheduler.m3 is just basically three functions: IOWait, > IOAlertWait, XIOWait > Plus the little internal utility, UTimeFromTime, the one liner > DoesWaitPidYield, and non-trivial functions nested in XIOWait: > TestFDS, CallSelect. > > I mean, you know, an alternative is to copy out very large chunks of > ThreadWin32.m3 and ThreadPThread.m3 and merge them into > ThreadCygwin.m3. That would be worse imho. > > "Directories" hardly. > > Or I can try debugging cygwin pthreads again. > > - Jay > > > CC: jkrell at elego.de; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Mon, 12 Jan 2009 12:46:54 +1100 > > You are smearing implementation details across multiple files and > directories. Up until now, ThreadPThread has been nicely self- > contained, and captured all the basic pieces of the thread > implementation. Also, how does all of this fit with the ThreadPosix > implementation? > > On 12 Jan 2009, at 12:19, Jay wrote: > > btw, I don't think it's that hairy, I merely split it into two or > three files, and added interfaces so they can reuse code with each > other. Movement between files is hard to track though (depending on > version control, but with all I've used). > > The SchedulerPosix implementation moved to ThreadPScheduler.m3. > What is shared between it and ThreadPThread/Win32.m3 is > ThreadInternal.i3, which maybe should be in ThreadF.i3, though > that's exposed outside m3core, and ThreadInternal.i3 includes a > variable. > > I can try again to debug Cygwin pthreads though. > > - Jay > > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:03:33 +1100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay, > > > > Can you remind me again why Cygwin was unable to use pthreads? It > > seems you have introduced a bunch of hair into the PTHREADS > > implementation to deal with broken Cygwin pthreads. As many of us > > have already pointed out, Cygwin should be a port that tries as much > > as possible to be like a standard POSIX platform (pthread-based) as > > opposed to a weird Windows/POSIX hybrid. > > > > I have a bunch of code that will be going into the PTHREADS base > that > > I am now at a loss to integrate with the changes you have made. > > > > Help! > > > > -- Tony > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 07:58:00 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 06:58:00 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> Message-ID: We have conflicting goals. Keeping things as fast as possible and with as little C as possible, vs. keeping things more portable, more easily ported, more obviously correct. I want to drastically reduce the header cloning, or, the work of porting. It is already reduced, but I want to keep going. I think having to make any changes at all in m3-libs/m3core/src/unix can be removed, other than adding the platform to the list of platforms that uses the "portable" stuff. Porting would devolve to: update the lists of platforms -- including some in m3makefiles update Target.m3 clone/edit Csetjmp.i3 add the GNU platform to m3cc/src/makefile and maybe nothing else. It is likely even that the IR is now portable, for "Posix" systems. Pick word size, pick endian, generate 4 versions of IR, pick the right one for your platform. Except for the OSConfigPosix that sometimes returns the platform name and cm3's defining "HOST". A variable isn't great, but it is faster and more source compatible than a function call, at least. And the C variable really will generally be read only. Writes to it should fault. > In this particular case, you are wanting to use a Modula-3 parameter > passing mechanism on something that is not declared in Modula-3. Isn't this just a variation on what is done all the time? -- having Modula-3 call C and sometimes vice versa? C code calls Modula-3 signal handlers, with data created in the C code. The Modula-3 code can then pass them on. I don't see the line really. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 12:32:15 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it? Jay, I really think you are bending over backwards too far just to be able to shoe-horn things into C. I *like* having the transpar of C header files expressed in Modula-3, *particularly* for system calls, where you might even be trying to build on a system that does not have the C header files installed, even though the libraries exist and can be linked to. Fundamentally, I think anytime the Modula-3 code is made less transparent you should think hard about what you are doing. The same with the change of constants to variables. I am getting very nervous that the changes you are making are destroying the clarity of the Modula-3 run-time code. In this particular case, you are wanting to use a Modula-3 parameter passing mechanism on something that is not declared in Modula-3. Seems kind of dubious to me. Also, I really don't like the idea of accessing external variables in C. -- Tony On 12 Jan 2009, at 11:55, Jay wrote: I considered ADDRESS.However I think it still doesn't satisfy. I want to be able to do this: TYPE Foo_t = something;<* EXTERNAL *> VAR Foo1, Foo2:Foo_t;<* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); (* Modula-3, not external *)PROCEDURE x()=BEGIN UseFoo(Foo1); UseFoo(Foo2);END x; AND I want any use of:VAR Foo3:Foo3_t; (* Modula-3, not external *)to error. This is sem_t and sigset_t in particular. Possibly renaming is the thing.They used to be declared in Modula-3, system-dependently, butI moved them to portable C. I could remove the types entirely and change UseFoo to take an address,and declare mask and ackSem to be integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END; That would satisfy but I thought it might be nicer to still provide the namedtypes to refer to the external variables. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?What's wrong with using ADDRESS for references to opaque values? If sigset_t is never instantiated in Modula-3, then why do you need it declared there? 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 01:44, Jay wrote: Is there a way in Modula-3 to declare that a type exists, and there are <*external*> instances of it, without "fully" declaring it, so that no Modula-3 can instantiate it? I have done this for sigset_t and sem_t, but they could erroneously be instantiated by Modula-3 and I'd like to remove that ability to mess up so easily. (* This type is not declared correctly. It is only instantiated in C code. *) sigset_t = RECORD END;(* This type is not declared correctly. It is only instantiated in C code. *) sem_t = RECORD END;In C I believe you can do this, like: typedef struct foo foo_t; extern foo_t foo; void UseFoo(foo_t*); foo_t* GetFoo(void); Thanks, - Jay -------------- 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: [M3devel] [M3commit] 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 jay.krell at cornell.edu Mon Jan 12 07:58:44 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 06:58:44 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: To bootstrap I believe. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 17:53:02 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3Why does sysutils need to be compatible with both old and new versions of m3core? On 12 Jan 2009, at 17:39, Jay wrote: ThreadPosix is basically unaffected -- I never provided user threads on Cygwin. I guess it got a slight reduction regarding DoesWaitPidYield, but its SchedulerPosix implementation was unchanged. The code in ThreadPosix is similar to but different than ThreadPThread.It is possible they could be merged but it wasn't trivial so I left ThreadPosix alone. > You are smearing implementation details across multiple files and directories You really think it is bad to have SchedulerPosix implemented in a small separate file?On top of what happens to be common implementation details of ThreadPThread.m3 and ThreadWin32.m3? ThreadPScheduler.m3 is just basically three functions: IOWait, IOAlertWait, XIOWaitPlus the little internal utility, UTimeFromTime, the one liner DoesWaitPidYield, and non-trivial functions nested in XIOWait: TestFDS, CallSelect. I mean, you know, an alternative is to copy out very large chunks of ThreadWin32.m3 and ThreadPThread.m3 and merge them into ThreadCygwin.m3. That would be worse imho. "Directories" hardly. Or I can try debugging cygwin pthreads again. - Jay CC: jkrell at elego.de; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 12:46:54 +1100You are smearing implementation details across multiple files and directories. Up until now, ThreadPThread has been nicely self-contained, and captured all the basic pieces of the thread implementation. Also, how does all of this fit with the ThreadPosix implementation? On 12 Jan 2009, at 12:19, Jay wrote: btw, I don't think it's that hairy, I merely split it into two or three files, and added interfaces so they can reuse code with each other. Movement between files is hard to track though (depending on version control, but with all I've used). The SchedulerPosix implementation moved to ThreadPScheduler.m3.What is shared between it and ThreadPThread/Win32.m3 is ThreadInternal.i3, which maybe should be in ThreadF.i3, though that's exposed outside m3core, and ThreadInternal.i3 includes a variable. I can try again to debug Cygwin pthreads though. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:03:33 +1100> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Jay,> > Can you remind me again why Cygwin was unable to use pthreads? It > seems you have introduced a bunch of hair into the PTHREADS > implementation to deal with broken Cygwin pthreads. As many of us > have already pointed out, Cygwin should be a port that tries as much > as possible to be like a standard POSIX platform (pthread-based) as > opposed to a weird Windows/POSIX hybrid.> > I have a bunch of code that will be going into the PTHREADS base that > I am now at a loss to integrate with the changes you have made.> > Help!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 08:04:46 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 18:04:46 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: Jay, Your changes are occurring way too fast for us to keep up with you, and some of them are distorting the code base unnecessarily. When you make these sorts of drastic reorgs it is important that the primary developers are in consensus. Right now I am most distressed by the damage that seems to have been done to m3core/src/thread -- I haven't had time to look over the other things you've been doing closely enough to know. For now, I am going to go in and change the source code head to reflect what I believe the solution for waitpid should look like. On 12 Jan 2009, at 17:53, Tony Hosking wrote: > Why does sysutils need to be compatible with both old and new > versions of m3core? > > On 12 Jan 2009, at 17:39, Jay wrote: > >> ThreadPosix is basically unaffected -- I never provided user >> threads on Cygwin. >> I guess it got a slight reduction regarding DoesWaitPidYield, but >> its SchedulerPosix implementation was unchanged. >> >> The code in ThreadPosix is similar to but different than >> ThreadPThread. >> It is possible they could be merged but it wasn't trivial so I left >> ThreadPosix alone. >> >> > You are smearing implementation details across multiple files >> and directories >> >> You really think it is bad to have SchedulerPosix implemented in a >> small separate file? >> On top of what happens to be common implementation details of >> ThreadPThread.m3 and ThreadWin32.m3? >> >> ThreadPScheduler.m3 is just basically three functions: IOWait, >> IOAlertWait, XIOWait >> Plus the little internal utility, UTimeFromTime, the one liner >> DoesWaitPidYield, and non-trivial functions nested in XIOWait: >> TestFDS, CallSelect. >> >> I mean, you know, an alternative is to copy out very large chunks >> of ThreadWin32.m3 and ThreadPThread.m3 and merge them into >> ThreadCygwin.m3. That would be worse imho. >> >> "Directories" hardly. >> >> Or I can try debugging cygwin pthreads again. >> >> - Jay >> >> >> CC: jkrell at elego.de; m3devel at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Subject: Re: [M3devel] [M3commit] CVS Update: cm3 >> Date: Mon, 12 Jan 2009 12:46:54 +1100 >> >> You are smearing implementation details across multiple files and >> directories. Up until now, ThreadPThread has been nicely self- >> contained, and captured all the basic pieces of the thread >> implementation. Also, how does all of this fit with the >> ThreadPosix implementation? >> >> On 12 Jan 2009, at 12:19, Jay wrote: >> >> btw, I don't think it's that hairy, I merely split it into two or >> three files, and added interfaces so they can reuse code with each >> other. Movement between files is hard to track though (depending on >> version control, but with all I've used). >> >> The SchedulerPosix implementation moved to ThreadPScheduler.m3. >> What is shared between it and ThreadPThread/Win32.m3 is >> ThreadInternal.i3, which maybe should be in ThreadF.i3, though >> that's exposed outside m3core, and ThreadInternal.i3 includes a >> variable. >> >> I can try again to debug Cygwin pthreads though. >> >> - Jay >> >> >> > From: hosking at cs.purdue.edu >> > To: jkrell at elego.de >> > Date: Mon, 12 Jan 2009 11:03:33 +1100 >> > CC: m3devel at elegosoft.com >> > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 >> > >> > Jay, >> > >> > Can you remind me again why Cygwin was unable to use pthreads? It >> > seems you have introduced a bunch of hair into the PTHREADS >> > implementation to deal with broken Cygwin pthreads. As many of us >> > have already pointed out, Cygwin should be a port that tries as >> much >> > as possible to be like a standard POSIX platform (pthread-based) as >> > opposed to a weird Windows/POSIX hybrid. >> > >> > I have a bunch of code that will be going into the PTHREADS base >> that >> > I am now at a loss to integrate with the changes you have made. >> > >> > Help! >> > >> > -- 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: [M3devel] [M3commit] 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: [M3devel] [M3commit] 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: [M3devel] [M3commit] 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: [M3devel] [M3commit] 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 hosking at cs.purdue.edu Mon Jan 12 08:19:55 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 18:19:55 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: Not true. sysutils should be built against the m3core with which it will be linked. I don't think this is correct. On 12 Jan 2009, at 17:58, Jay wrote: > To bootstrap I believe. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 17:53:02 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Why does sysutils need to be compatible with both old and new > versions of m3core? > > On 12 Jan 2009, at 17:39, Jay wrote: > > ThreadPosix is basically unaffected -- I never provided user threads > on Cygwin. > I guess it got a slight reduction regarding DoesWaitPidYield, but > its SchedulerPosix implementation was unchanged. > > The code in ThreadPosix is similar to but different than > ThreadPThread. > It is possible they could be merged but it wasn't trivial so I left > ThreadPosix alone. > > > You are smearing implementation details across multiple files and > directories > > You really think it is bad to have SchedulerPosix implemented in a > small separate file? > On top of what happens to be common implementation details of > ThreadPThread.m3 and ThreadWin32.m3? > > ThreadPScheduler.m3 is just basically three functions: IOWait, > IOAlertWait, XIOWait > Plus the little internal utility, UTimeFromTime, the one liner > DoesWaitPidYield, and non-trivial functions nested in XIOWait: > TestFDS, CallSelect. > > I mean, you know, an alternative is to copy out very large chunks of > ThreadWin32.m3 and ThreadPThread.m3 and merge them into > ThreadCygwin.m3. That would be worse imho. > > "Directories" hardly. > > Or I can try debugging cygwin pthreads again. > > - Jay > > > CC: jkrell at elego.de; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Mon, 12 Jan 2009 12:46:54 +1100 > > You are smearing implementation details across multiple files and > directories. Up until now, ThreadPThread has been nicely self- > contained, and captured all the basic pieces of the thread > implementation. Also, how does all of this fit with the ThreadPosix > implementation? > > On 12 Jan 2009, at 12:19, Jay wrote: > > btw, I don't think it's that hairy, I merely split it into two or > three files, and added interfaces so they can reuse code with each > other. Movement between files is hard to track though (depending on > version control, but with all I've used). > > The SchedulerPosix implementation moved to ThreadPScheduler.m3. > What is shared between it and ThreadPThread/Win32.m3 is > ThreadInternal.i3, which maybe should be in ThreadF.i3, though > that's exposed outside m3core, and ThreadInternal.i3 includes a > variable. > > I can try again to debug Cygwin pthreads though. > > - Jay > > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:03:33 +1100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay, > > > > Can you remind me again why Cygwin was unable to use pthreads? It > > seems you have introduced a bunch of hair into the PTHREADS > > implementation to deal with broken Cygwin pthreads. As many of us > > have already pointed out, Cygwin should be a port that tries as much > > as possible to be like a standard POSIX platform (pthread-based) as > > opposed to a weird Windows/POSIX hybrid. > > > > I have a bunch of code that will be going into the PTHREADS base > that > > I am now at a loss to integrate with the changes you have made. > > > > Help! > > > > -- 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: [M3devel] [M3commit] 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 hosking at cs.purdue.edu Mon Jan 12 08:24:43 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 18:24:43 +1100 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> Message-ID: Jay, What the hell is the ROOT variable supposed to do now. I can't build m3core with a compiler that doesn't define ROOT. And why does the m3makefile that includes Uwaitpid.quake expect a hardwired cm3 directory hierarchy. Surely, I should be able to build m3core as a separate package, regardless of the structure in which it appears. You are doing damage to the package structures here too, by hardwiring these paths into the m3makefile. -- Tony On 12 Jan 2009, at 17:58, Jay wrote: > We have conflicting goals. > > Keeping things as fast as possible and with as little C as possible, > vs. keeping things more portable, more easily ported, more obviously > correct. > > I want to drastically reduce the header cloning, or, the work of > porting. > It is already reduced, but I want to keep going. > I think having to make any changes at all in m3-libs/m3core/src/ > unix can be removed, other than adding the platform to the list of > platforms that uses the "portable" stuff. > Porting would devolve to: > update the lists of platforms -- including some in m3makefiles > update Target.m3 > clone/edit Csetjmp.i3 > add the GNU platform to m3cc/src/makefile > > and maybe nothing else. > > It is likely even that the IR is now portable, for "Posix" systems. > Pick word size, pick endian, generate 4 versions of IR, pick the > right one for your platform. > Except for the OSConfigPosix that sometimes returns the platform > name and cm3's defining "HOST". > > A variable isn't great, but it is faster and more source compatible > than a function call, at least. > And the C variable really will generally be read only. Writes to it > should fault. > > > In this particular case, you are wanting to use a Modula-3 > parameter > > passing mechanism on something that is not declared in Modula-3. > > Isn't this just a variation on what is done all the time? -- having > Modula-3 call C and sometimes vice versa? > C code calls Modula-3 signal handlers, with data created in the C > code. The Modula-3 code can then pass them on. I don't see the line > really. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 12:32:15 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > > > Jay, I really think you are bending over backwards too far just to > be able to shoe-horn things into C. I *like* having the transpar of > C header files expressed in Modula-3, *particularly* for system > calls, where you might even be trying to build on a system that does > not have the C header files installed, even though the libraries > exist and can be linked to. Fundamentally, I think anytime the > Modula-3 code is made less transparent you should think hard about > what you are doing. The same with the change of constants to > variables. > > I am getting very nervous that the changes you are making are > destroying the clarity of the Modula-3 run-time code. > > In this particular case, you are wanting to use a Modula-3 parameter > passing mechanism on something that is not declared in Modula-3. > Seems kind of dubious to me. Also, I really don't like the idea of > accessing external variables in C. > > -- Tony > > On 12 Jan 2009, at 11:55, Jay wrote: > > I considered ADDRESS. > However I think it still doesn't satisfy. > > I want to be able to do this: > > TYPE Foo_t = something; > <* EXTERNAL *> VAR Foo1, Foo2:Foo_t; > <* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); > > (* Modula-3, not external *) > PROCEDURE x()= > BEGIN > UseFoo(Foo1); > UseFoo(Foo2); > END x; > > AND I want any use of: > VAR Foo3:Foo3_t; (* Modula-3, not external *) > > to error. This is sem_t and sigset_t in particular. > > Possibly renaming is the thing. > They used to be declared in Modula-3, system-dependently, but > I moved them to portable C. > > I could remove the types entirely and change UseFoo to take an > address, > and declare mask and ackSem to be integers or I guess. > <*EXTERNAL> VAR ackSem : RECORD END; > > That would satisfy but I thought it might be nicer to still provide > the named > types to refer to the external variables. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 11:13:00 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > > What's wrong with using ADDRESS for references to opaque values? If > sigset_t is never instantiated in Modula-3, then why do you need it > declared there? > > 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 01:44, Jay wrote: > > Is there a way in Modula-3 to declare that a type exists, and there > are <*external*> instances of it, without "fully" declaring it, so > that no Modula-3 can instantiate it? > > I have done this for sigset_t and sem_t, but they could erroneously > be instantiated by Modula-3 and I'd like to remove that ability to > mess up so easily. > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sigset_t = RECORD END; > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sem_t = RECORD END; > > In C I believe you can do this, like: > typedef struct foo foo_t; > extern foo_t foo; > > void UseFoo(foo_t*); > foo_t* GetFoo(void); > > Thanks, > - Jay > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 08:25:03 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 07:25:03 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: The compiler uses sysutils. The first pass builds against an old package store, which might not have sysutils at all, if it is that old. Again, once new m3core is around, no problem. I could/should have put in the m3core change and just waited on the sysutils change, rather than go ahead and do the quake stuff, and we can do that now (or your change that moots it, which I haven't looked into yet). I was browsing the docs and it appears there is an "import_pkg" directive for like, copying in a package contents, instead of linking. That might also solve this. I found that relatively late and never looked into it. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:19:55 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3Not true. sysutils should be built against the m3core with which it will be linked. I don't think this is correct. On 12 Jan 2009, at 17:58, Jay wrote: To bootstrap I believe. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 17:53:02 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3Why does sysutils need to be compatible with both old and new versions of m3core? On 12 Jan 2009, at 17:39, Jay wrote: ThreadPosix is basically unaffected -- I never provided user threads on Cygwin. I guess it got a slight reduction regarding DoesWaitPidYield, but its SchedulerPosix implementation was unchanged. The code in ThreadPosix is similar to but different than ThreadPThread.It is possible they could be merged but it wasn't trivial so I left ThreadPosix alone. > You are smearing implementation details across multiple files and directories You really think it is bad to have SchedulerPosix implemented in a small separate file?On top of what happens to be common implementation details of ThreadPThread.m3 and ThreadWin32.m3? ThreadPScheduler.m3 is just basically three functions: IOWait, IOAlertWait, XIOWaitPlus the little internal utility, UTimeFromTime, the one liner DoesWaitPidYield, and non-trivial functions nested in XIOWait: TestFDS, CallSelect. I mean, you know, an alternative is to copy out very large chunks of ThreadWin32.m3 and ThreadPThread.m3 and merge them into ThreadCygwin.m3. That would be worse imho. "Directories" hardly. Or I can try debugging cygwin pthreads again. - Jay CC: jkrell at elego.de; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 12:46:54 +1100You are smearing implementation details across multiple files and directories. Up until now, ThreadPThread has been nicely self-contained, and captured all the basic pieces of the thread implementation. Also, how does all of this fit with the ThreadPosix implementation? On 12 Jan 2009, at 12:19, Jay wrote: btw, I don't think it's that hairy, I merely split it into two or three files, and added interfaces so they can reuse code with each other. Movement between files is hard to track though (depending on version control, but with all I've used). The SchedulerPosix implementation moved to ThreadPScheduler.m3.What is shared between it and ThreadPThread/Win32.m3 is ThreadInternal.i3, which maybe should be in ThreadF.i3, though that's exposed outside m3core, and ThreadInternal.i3 includes a variable. I can try again to debug Cygwin pthreads though. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:03:33 +1100> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Jay,> > Can you remind me again why Cygwin was unable to use pthreads? It > seems you have introduced a bunch of hair into the PTHREADS > implementation to deal with broken Cygwin pthreads. As many of us > have already pointed out, Cygwin should be a port that tries as much > as possible to be like a standard POSIX platform (pthread-based) as > opposed to a weird Windows/POSIX hybrid.> > I have a bunch of code that will be going into the PTHREADS base that > I am now at a loss to integrate with the changes you have made.> > Help!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 08:27:09 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 07:27:09 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> Message-ID: Huh..that's what I was saying about the way m3overrides work -- the directory structure IS duplicated /everywhere/.. I don't know what choice there is, if quake code is to be shared across packages. m3tests does the same sort of thing, also to me. Ok, hold, I'll slow sysutils back down. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:24:43 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?Jay, What the hell is the ROOT variable supposed to do now. I can't build m3core with a compiler that doesn't define ROOT. And why does the m3makefile that includes Uwaitpid.quake expect a hardwired cm3 directory hierarchy. Surely, I should be able to build m3core as a separate package, regardless of the structure in which it appears. You are doing damage to the package structures here too, by hardwiring these paths into the m3makefile. -- Tony On 12 Jan 2009, at 17:58, Jay wrote: We have conflicting goals. Keeping things as fast as possible and with as little C as possible, vs. keeping things more portable, more easily ported, more obviously correct. I want to drastically reduce the header cloning, or, the work of porting. It is already reduced, but I want to keep going. I think having to make any changes at all in m3-libs/m3core/src/unix can be removed, other than adding the platform to the list of platforms that uses the "portable" stuff.Porting would devolve to: update the lists of platforms -- including some in m3makefiles update Target.m3 clone/edit Csetjmp.i3 add the GNU platform to m3cc/src/makefile and maybe nothing else. It is likely even that the IR is now portable, for "Posix" systems.Pick word size, pick endian, generate 4 versions of IR, pick the right one for your platform.Except for the OSConfigPosix that sometimes returns the platform name and cm3's defining "HOST". A variable isn't great, but it is faster and more source compatible than a function call, at least.And the C variable really will generally be read only. Writes to it should fault. > In this particular case, you are wanting to use a Modula-3 parameter > passing mechanism on something that is not declared in Modula-3. Isn't this just a variation on what is done all the time? -- having Modula-3 call C and sometimes vice versa?C code calls Modula-3 signal handlers, with data created in the C code. The Modula-3 code can then pass them on. I don't see the line really. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 12:32:15 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it? Jay, I really think you are bending over backwards too far just to be able to shoe-horn things into C. I *like* having the transpar of C header files expressed in Modula-3, *particularly* for system calls, where you might even be trying to build on a system that does not have the C header files installed, even though the libraries exist and can be linked to. Fundamentally, I think anytime the Modula-3 code is made less transparent you should think hard about what you are doing. The same with the change of constants to variables. I am getting very nervous that the changes you are making are destroying the clarity of the Modula-3 run-time code. In this particular case, you are wanting to use a Modula-3 parameter passing mechanism on something that is not declared in Modula-3. Seems kind of dubious to me. Also, I really don't like the idea of accessing external variables in C. -- Tony On 12 Jan 2009, at 11:55, Jay wrote: I considered ADDRESS.However I think it still doesn't satisfy. I want to be able to do this: TYPE Foo_t = something;<* EXTERNAL *> VAR Foo1, Foo2:Foo_t;<* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); (* Modula-3, not external *)PROCEDURE x()=BEGIN UseFoo(Foo1); UseFoo(Foo2);END x; AND I want any use of:VAR Foo3:Foo3_t; (* Modula-3, not external *)to error. This is sem_t and sigset_t in particular. Possibly renaming is the thing.They used to be declared in Modula-3, system-dependently, butI moved them to portable C. I could remove the types entirely and change UseFoo to take an address,and declare mask and ackSem to be integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END; That would satisfy but I thought it might be nicer to still provide the namedtypes to refer to the external variables. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?What's wrong with using ADDRESS for references to opaque values? If sigset_t is never instantiated in Modula-3, then why do you need it declared there? 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 01:44, Jay wrote: Is there a way in Modula-3 to declare that a type exists, and there are <*external*> instances of it, without "fully" declaring it, so that no Modula-3 can instantiate it? I have done this for sigset_t and sem_t, but they could erroneously be instantiated by Modula-3 and I'd like to remove that ability to mess up so easily. (* This type is not declared correctly. It is only instantiated in C code. *) sigset_t = RECORD END;(* This type is not declared correctly. It is only instantiated in C code. *) sem_t = RECORD END;In C I believe you can do this, like: typedef struct foo foo_t; extern foo_t foo; void UseFoo(foo_t*); foo_t* GetFoo(void); Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 08:31:40 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 18:31:40 +1100 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> Message-ID: <079DF9EE-C4DE-4563-B21E-53EA34F364AD@cs.purdue.edu> Don't mess with sysutils. I am about to check in my code. You could help by reverting from the current quake generated copies of waitpid to a single copy. On 12 Jan 2009, at 18:27, Jay wrote: > Huh..that's what I was saying about the way m3overrides work -- the > directory structure IS duplicated /everywhere/.. I don't know what > choice there is, if quake code is to be shared across packages. > > m3tests does the same sort of thing, also to me. > > Ok, hold, I'll slow sysutils back down. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 18:24:43 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > > Jay, > > What the hell is the ROOT variable supposed to do now. I can't > build m3core with a compiler that doesn't define ROOT. And why does > the m3makefile that includes Uwaitpid.quake expect a hardwired cm3 > directory hierarchy. Surely, I should be able to build m3core as a > separate package, regardless of the structure in which it appears. > You are doing damage to the package structures here too, by > hardwiring these paths into the m3makefile. > > -- Tony > > On 12 Jan 2009, at 17:58, Jay wrote: > > We have conflicting goals. > > Keeping things as fast as possible and with as little C as possible, > vs. keeping things more portable, more easily ported, more obviously > correct. > > I want to drastically reduce the header cloning, or, the work of > porting. > It is already reduced, but I want to keep going. > I think having to make any changes at all in m3-libs/m3core/src/ > unix can be removed, other than adding the platform to the list of > platforms that uses the "portable" stuff. > Porting would devolve to: > update the lists of platforms -- including some in m3makefiles > update Target.m3 > clone/edit Csetjmp.i3 > add the GNU platform to m3cc/src/makefile > > and maybe nothing else. > > It is likely even that the IR is now portable, for "Posix" systems. > Pick word size, pick endian, generate 4 versions of IR, pick the > right one for your platform. > Except for the OSConfigPosix that sometimes returns the platform > name and cm3's defining "HOST". > > A variable isn't great, but it is faster and more source compatible > than a function call, at least. > And the C variable really will generally be read only. Writes to it > should fault. > > > In this particular case, you are wanting to use a Modula-3 > parameter > > passing mechanism on something that is not declared in Modula-3. > > Isn't this just a variation on what is done all the time? -- having > Modula-3 call C and sometimes vice versa? > C code calls Modula-3 signal handlers, with data created in the C > code. The Modula-3 code can then pass them on. I don't see the line > really. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 12:32:15 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > > > Jay, I really think you are bending over backwards too far just to > be able to shoe-horn things into C. I *like* having the transpar of > C header files expressed in Modula-3, *particularly* for system > calls, where you might even be trying to build on a system that does > not have the C header files installed, even though the libraries > exist and can be linked to. Fundamentally, I think anytime the > Modula-3 code is made less transparent you should think hard about > what you are doing. The same with the change of constants to > variables. > > I am getting very nervous that the changes you are making are > destroying the clarity of the Modula-3 run-time code. > > In this particular case, you are wanting to use a Modula-3 parameter > passing mechanism on something that is not declared in Modula-3. > Seems kind of dubious to me. Also, I really don't like the idea of > accessing external variables in C. > > -- Tony > > On 12 Jan 2009, at 11:55, Jay wrote: > > I considered ADDRESS. > However I think it still doesn't satisfy. > > I want to be able to do this: > > TYPE Foo_t = something; > <* EXTERNAL *> VAR Foo1, Foo2:Foo_t; > <* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); > > (* Modula-3, not external *) > PROCEDURE x()= > BEGIN > UseFoo(Foo1); > UseFoo(Foo2); > END x; > > AND I want any use of: > VAR Foo3:Foo3_t; (* Modula-3, not external *) > > to error. This is sem_t and sigset_t in particular. > > Possibly renaming is the thing. > They used to be declared in Modula-3, system-dependently, but > I moved them to portable C. > > I could remove the types entirely and change UseFoo to take an > address, > and declare mask and ackSem to be integers or I guess. > <*EXTERNAL> VAR ackSem : RECORD END; > > That would satisfy but I thought it might be nicer to still provide > the named > types to refer to the external variables. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 11:13:00 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > > What's wrong with using ADDRESS for references to opaque values? If > sigset_t is never instantiated in Modula-3, then why do you need it > declared there? > > 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 01:44, Jay wrote: > > Is there a way in Modula-3 to declare that a type exists, and there > are <*external*> instances of it, without "fully" declaring it, so > that no Modula-3 can instantiate it? > > I have done this for sigset_t and sem_t, but they could erroneously > be instantiated by Modula-3 and I'd like to remove that ability to > mess up so easily. > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sigset_t = RECORD END; > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sem_t = RECORD END; > > In C I believe you can do this, like: > typedef struct foo foo_t; > extern foo_t foo; > > void UseFoo(foo_t*); > foo_t* GetFoo(void); > > Thanks, > - Jay > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 08:32:13 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 07:32:13 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> Message-ID: I didn't slow it back down yet, but I changed to a relative path instead of ROOT. All the scripts define ROOT and my config files ferry environment variable CM3_ROOT to ROOT. (ROOT is too generic for an environment variable.) oh -- m3core or sysytils? sysutils needed it. I don't see what m3core does. - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] declaring a type's existance but not enough to instantiate it?Date: Mon, 12 Jan 2009 07:27:09 +0000 Huh..that's what I was saying about the way m3overrides work -- the directory structure IS duplicated /everywhere/.. I don't know what choice there is, if quake code is to be shared across packages. m3tests does the same sort of thing, also to me. Ok, hold, I'll slow sysutils back down. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:24:43 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?Jay, What the hell is the ROOT variable supposed to do now. I can't build m3core with a compiler that doesn't define ROOT. And why does the m3makefile that includes Uwaitpid.quake expect a hardwired cm3 directory hierarchy. Surely, I should be able to build m3core as a separate package, regardless of the structure in which it appears. You are doing damage to the package structures here too, by hardwiring these paths into the m3makefile. -- Tony On 12 Jan 2009, at 17:58, Jay wrote: We have conflicting goals. Keeping things as fast as possible and with as little C as possible, vs. keeping things more portable, more easily ported, more obviously correct. I want to drastically reduce the header cloning, or, the work of porting. It is already reduced, but I want to keep going. I think having to make any changes at all in m3-libs/m3core/src/unix can be removed, other than adding the platform to the list of platforms that uses the "portable" stuff.Porting would devolve to: update the lists of platforms -- including some in m3makefiles update Target.m3 clone/edit Csetjmp.i3 add the GNU platform to m3cc/src/makefile and maybe nothing else. It is likely even that the IR is now portable, for "Posix" systems.Pick word size, pick endian, generate 4 versions of IR, pick the right one for your platform.Except for the OSConfigPosix that sometimes returns the platform name and cm3's defining "HOST". A variable isn't great, but it is faster and more source compatible than a function call, at least.And the C variable really will generally be read only. Writes to it should fault. > In this particular case, you are wanting to use a Modula-3 parameter > passing mechanism on something that is not declared in Modula-3. Isn't this just a variation on what is done all the time? -- having Modula-3 call C and sometimes vice versa?C code calls Modula-3 signal handlers, with data created in the C code. The Modula-3 code can then pass them on. I don't see the line really. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 12:32:15 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it? Jay, I really think you are bending over backwards too far just to be able to shoe-horn things into C. I *like* having the transpar of C header files expressed in Modula-3, *particularly* for system calls, where you might even be trying to build on a system that does not have the C header files installed, even though the libraries exist and can be linked to. Fundamentally, I think anytime the Modula-3 code is made less transparent you should think hard about what you are doing. The same with the change of constants to variables. I am getting very nervous that the changes you are making are destroying the clarity of the Modula-3 run-time code. In this particular case, you are wanting to use a Modula-3 parameter passing mechanism on something that is not declared in Modula-3. Seems kind of dubious to me. Also, I really don't like the idea of accessing external variables in C. -- Tony On 12 Jan 2009, at 11:55, Jay wrote: I considered ADDRESS.However I think it still doesn't satisfy. I want to be able to do this: TYPE Foo_t = something;<* EXTERNAL *> VAR Foo1, Foo2:Foo_t;<* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); (* Modula-3, not external *)PROCEDURE x()=BEGIN UseFoo(Foo1); UseFoo(Foo2);END x; AND I want any use of:VAR Foo3:Foo3_t; (* Modula-3, not external *)to error. This is sem_t and sigset_t in particular. Possibly renaming is the thing.They used to be declared in Modula-3, system-dependently, butI moved them to portable C. I could remove the types entirely and change UseFoo to take an address,and declare mask and ackSem to be integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END; That would satisfy but I thought it might be nicer to still provide the namedtypes to refer to the external variables. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?What's wrong with using ADDRESS for references to opaque values? If sigset_t is never instantiated in Modula-3, then why do you need it declared there? 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 01:44, Jay wrote: Is there a way in Modula-3 to declare that a type exists, and there are <*external*> instances of it, without "fully" declaring it, so that no Modula-3 can instantiate it? I have done this for sigset_t and sem_t, but they could erroneously be instantiated by Modula-3 and I'd like to remove that ability to mess up so easily. (* This type is not declared correctly. It is only instantiated in C code. *) sigset_t = RECORD END;(* This type is not declared correctly. It is only instantiated in C code. *) sem_t = RECORD END;In C I believe you can do this, like: typedef struct foo foo_t; extern foo_t foo; void UseFoo(foo_t*); foo_t* GetFoo(void); Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 08:38:59 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 07:38:59 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> Message-ID: > sysutils needed it. I don't see what m3core does. I see. "fixing". - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] declaring a type's existance but not enough to instantiate it?Date: Mon, 12 Jan 2009 07:32:13 +0000 I didn't slow it back down yet, but I changed to a relative path instead of ROOT.All the scripts define ROOT and my config files ferry environment variable CM3_ROOT to ROOT.(ROOT is too generic for an environment variable.)oh -- m3core or sysytils?sysutils needed it. I don't see what m3core does. - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] declaring a type's existance but not enough to instantiate it?Date: Mon, 12 Jan 2009 07:27:09 +0000 Huh..that's what I was saying about the way m3overrides work -- the directory structure IS duplicated /everywhere/.. I don't know what choice there is, if quake code is to be shared across packages. m3tests does the same sort of thing, also to me. Ok, hold, I'll slow sysutils back down. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:24:43 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?Jay, What the hell is the ROOT variable supposed to do now. I can't build m3core with a compiler that doesn't define ROOT. And why does the m3makefile that includes Uwaitpid.quake expect a hardwired cm3 directory hierarchy. Surely, I should be able to build m3core as a separate package, regardless of the structure in which it appears. You are doing damage to the package structures here too, by hardwiring these paths into the m3makefile. -- Tony On 12 Jan 2009, at 17:58, Jay wrote: We have conflicting goals. Keeping things as fast as possible and with as little C as possible, vs. keeping things more portable, more easily ported, more obviously correct. I want to drastically reduce the header cloning, or, the work of porting. It is already reduced, but I want to keep going. I think having to make any changes at all in m3-libs/m3core/src/unix can be removed, other than adding the platform to the list of platforms that uses the "portable" stuff.Porting would devolve to: update the lists of platforms -- including some in m3makefiles update Target.m3 clone/edit Csetjmp.i3 add the GNU platform to m3cc/src/makefile and maybe nothing else. It is likely even that the IR is now portable, for "Posix" systems.Pick word size, pick endian, generate 4 versions of IR, pick the right one for your platform.Except for the OSConfigPosix that sometimes returns the platform name and cm3's defining "HOST". A variable isn't great, but it is faster and more source compatible than a function call, at least.And the C variable really will generally be read only. Writes to it should fault. > In this particular case, you are wanting to use a Modula-3 parameter > passing mechanism on something that is not declared in Modula-3. Isn't this just a variation on what is done all the time? -- having Modula-3 call C and sometimes vice versa?C code calls Modula-3 signal handlers, with data created in the C code. The Modula-3 code can then pass them on. I don't see the line really. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 12:32:15 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it? Jay, I really think you are bending over backwards too far just to be able to shoe-horn things into C. I *like* having the transpar of C header files expressed in Modula-3, *particularly* for system calls, where you might even be trying to build on a system that does not have the C header files installed, even though the libraries exist and can be linked to. Fundamentally, I think anytime the Modula-3 code is made less transparent you should think hard about what you are doing. The same with the change of constants to variables. I am getting very nervous that the changes you are making are destroying the clarity of the Modula-3 run-time code. In this particular case, you are wanting to use a Modula-3 parameter passing mechanism on something that is not declared in Modula-3. Seems kind of dubious to me. Also, I really don't like the idea of accessing external variables in C. -- Tony On 12 Jan 2009, at 11:55, Jay wrote: I considered ADDRESS.However I think it still doesn't satisfy. I want to be able to do this: TYPE Foo_t = something;<* EXTERNAL *> VAR Foo1, Foo2:Foo_t;<* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); (* Modula-3, not external *)PROCEDURE x()=BEGIN UseFoo(Foo1); UseFoo(Foo2);END x; AND I want any use of:VAR Foo3:Foo3_t; (* Modula-3, not external *)to error. This is sem_t and sigset_t in particular. Possibly renaming is the thing.They used to be declared in Modula-3, system-dependently, butI moved them to portable C. I could remove the types entirely and change UseFoo to take an address,and declare mask and ackSem to be integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END; That would satisfy but I thought it might be nicer to still provide the namedtypes to refer to the external variables. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?What's wrong with using ADDRESS for references to opaque values? If sigset_t is never instantiated in Modula-3, then why do you need it declared there? 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 01:44, Jay wrote: Is there a way in Modula-3 to declare that a type exists, and there are <*external*> instances of it, without "fully" declaring it, so that no Modula-3 can instantiate it? I have done this for sigset_t and sem_t, but they could erroneously be instantiated by Modula-3 and I'd like to remove that ability to mess up so easily. (* This type is not declared correctly. It is only instantiated in C code. *) sigset_t = RECORD END;(* This type is not declared correctly. It is only instantiated in C code. *) sem_t = RECORD END;In C I believe you can do this, like: typedef struct foo foo_t; extern foo_t foo; void UseFoo(foo_t*); foo_t* GetFoo(void); Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 08:51:08 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 18:51:08 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: Why do you not build in the following order to get a new compiler? (You may need to downgrade Compiler.tmpl for use with an old compiler so that you don't get a mismatch between m3core and libm3, but otherwise the following sequence should work). m3core libm3 sysutils m3middle m3objfile m3linker m3back m3front m3quake cm3 On 12 Jan 2009, at 18:25, Jay wrote: > The compiler uses sysutils. The first pass builds against an old > package store, which might not have sysutils at all, if it is that > old. > > Again, once new m3core is around, no problem. > I could/should have put in the m3core change and just waited on the > sysutils change, rather than go ahead and do the quake stuff, and we > can do that now (or your change that moots it, which I haven't > looked into yet). > > I was browsing the docs and it appears there is an "import_pkg" > directive for like, copying in a package contents, instead of > linking. That might also solve this. I found that relatively late > and never looked into it. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 18:19:55 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Not true. sysutils should be built against the m3core with which it > will be linked. I don't think this is correct. > > On 12 Jan 2009, at 17:58, Jay wrote: > > To bootstrap I believe. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 17:53:02 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Why does sysutils need to be compatible with both old and new > versions of m3core? > > On 12 Jan 2009, at 17:39, Jay wrote: > > ThreadPosix is basically unaffected -- I never provided user threads > on Cygwin. > I guess it got a slight reduction regarding DoesWaitPidYield, but > its SchedulerPosix implementation was unchanged. > > The code in ThreadPosix is similar to but different than > ThreadPThread. > It is possible they could be merged but it wasn't trivial so I left > ThreadPosix alone. > > > You are smearing implementation details across multiple files and > directories > > You really think it is bad to have SchedulerPosix implemented in a > small separate file? > On top of what happens to be common implementation details of > ThreadPThread.m3 and ThreadWin32.m3? > > ThreadPScheduler.m3 is just basically three functions: IOWait, > IOAlertWait, XIOWait > Plus the little internal utility, UTimeFromTime, the one liner > DoesWaitPidYield, and non-trivial functions nested in XIOWait: > TestFDS, CallSelect. > > I mean, you know, an alternative is to copy out very large chunks of > ThreadWin32.m3 and ThreadPThread.m3 and merge them into > ThreadCygwin.m3. That would be worse imho. > > "Directories" hardly. > > Or I can try debugging cygwin pthreads again. > > - Jay > > > CC: jkrell at elego.de; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Mon, 12 Jan 2009 12:46:54 +1100 > > You are smearing implementation details across multiple files and > directories. Up until now, ThreadPThread has been nicely self- > contained, and captured all the basic pieces of the thread > implementation. Also, how does all of this fit with the ThreadPosix > implementation? > > On 12 Jan 2009, at 12:19, Jay wrote: > > btw, I don't think it's that hairy, I merely split it into two or > three files, and added interfaces so they can reuse code with each > other. Movement between files is hard to track though (depending on > version control, but with all I've used). > > The SchedulerPosix implementation moved to ThreadPScheduler.m3. > What is shared between it and ThreadPThread/Win32.m3 is > ThreadInternal.i3, which maybe should be in ThreadF.i3, though > that's exposed outside m3core, and ThreadInternal.i3 includes a > variable. > > I can try again to debug Cygwin pthreads though. > > - Jay > > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:03:33 +1100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay, > > > > Can you remind me again why Cygwin was unable to use pthreads? It > > seems you have introduced a bunch of hair into the PTHREADS > > implementation to deal with broken Cygwin pthreads. As many of us > > have already pointed out, Cygwin should be a port that tries as much > > as possible to be like a standard POSIX platform (pthread-based) as > > opposed to a weird Windows/POSIX hybrid. > > > > I have a bunch of code that will be going into the PTHREADS base > that > > I am now at a loss to integrate with the changes you have made. > > > > Help! > > > > -- Tony > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 08:52:34 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 18:52:34 +1100 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> Message-ID: <5406617A-EFAC-4506-B6F7-F1EFCE4A230E@cs.purdue.edu> There are some of us around who don't use your scripts and expect to be able to build any package using cm3 out of the box. I don't use scripts for my bootstrapping -- I just compile and ship the packages in the right order. On 12 Jan 2009, at 18:32, Jay wrote: > I didn't slow it back down yet, but I changed to a relative path > instead of ROOT. > All the scripts define ROOT and my config files ferry environment > variable CM3_ROOT to ROOT. > (ROOT is too generic for an environment variable.) > > oh -- m3core or sysytils? > sysutils needed it. I don't see what m3core does. > > - Jay > > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] declaring a type's existance but not enough > to instantiate it? > Date: Mon, 12 Jan 2009 07:27:09 +0000 > > Huh..that's what I was saying about the way m3overrides work -- the > directory structure IS duplicated /everywhere/.. I don't know what > choice there is, if quake code is to be shared across packages. > > m3tests does the same sort of thing, also to me. > > Ok, hold, I'll slow sysutils back down. > > - Jay > > > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 18:24:43 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > > Jay, > > > What the hell is the ROOT variable supposed to do now. I can't > build m3core with a compiler that doesn't define ROOT. And why does > the m3makefile that includes Uwaitpid.quake expect a hardwired cm3 > directory hierarchy. Surely, I should be able to build m3core as a > separate package, regardless of the structure in which it appears. > You are doing damage to the package structures here too, by > hardwiring these paths into the m3makefile. > > -- Tony > > On 12 Jan 2009, at 17:58, Jay wrote: > > We have conflicting goals. > > Keeping things as fast as possible and with as little C as possible, > vs. keeping things more portable, more easily ported, more obviously > correct. > > I want to drastically reduce the header cloning, or, the work of > porting. > It is already reduced, but I want to keep going. > I think having to make any changes at all in m3-libs/m3core/src/ > unix can be removed, other than adding the platform to the list of > platforms that uses the "portable" stuff. > Porting would devolve to: > update the lists of platforms -- including some in m3makefiles > update Target.m3 > clone/edit Csetjmp.i3 > add the GNU platform to m3cc/src/makefile > > and maybe nothing else. > > It is likely even that the IR is now portable, for "Posix" systems. > Pick word size, pick endian, generate 4 versions of IR, pick the > right one for your platform. > Except for the OSConfigPosix that sometimes returns the platform > name and cm3's defining "HOST". > > A variable isn't great, but it is faster and more source compatible > than a function call, at least. > And the C variable really will generally be read only. Writes to it > should fault. > > > In this particular case, you are wanting to use a Modula-3 > parameter > > passing mechanism on something that is not declared in Modula-3. > > Isn't this just a variation on what is done all the time? -- having > Modula-3 call C and sometimes vice versa? > C code calls Modula-3 signal handlers, with data created in the C > code. The Modula-3 code can then pass them on. I don't see the line > really. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 12:32:15 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > > > Jay, I really think you are bending over backwards too far just to > be able to shoe-horn things into C. I *like* having the transpar of > C header files expressed in Modula-3, *particularly* for system > calls, where you might even be trying to build on a system that does > not have the C header files installed, even though the libraries > exist and can be linked to. Fundamentally, I think anytime the > Modula-3 code is made less transparent you should think hard about > what you are doing. The same with the change of constants to > variables. > > I am getting very nervous that the changes you are making are > destroying the clarity of the Modula-3 run-time code. > > In this particular case, you are wanting to use a Modula-3 parameter > passing mechanism on something that is not declared in Modula-3. > Seems kind of dubious to me. Also, I really don't like the idea of > accessing external variables in C. > > -- Tony > > On 12 Jan 2009, at 11:55, Jay wrote: > > I considered ADDRESS. > However I think it still doesn't satisfy. > > I want to be able to do this: > > TYPE Foo_t = something; > <* EXTERNAL *> VAR Foo1, Foo2:Foo_t; > <* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); > > (* Modula-3, not external *) > PROCEDURE x()= > BEGIN > UseFoo(Foo1); > UseFoo(Foo2); > END x; > > AND I want any use of: > VAR Foo3:Foo3_t; (* Modula-3, not external *) > > to error. This is sem_t and sigset_t in particular. > > Possibly renaming is the thing. > They used to be declared in Modula-3, system-dependently, but > I moved them to portable C. > > I could remove the types entirely and change UseFoo to take an > address, > and declare mask and ackSem to be integers or I guess. > <*EXTERNAL> VAR ackSem : RECORD END; > > That would satisfy but I thought it might be nicer to still provide > the named > types to refer to the external variables. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 11:13:00 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > > What's wrong with using ADDRESS for references to opaque values? If > sigset_t is never instantiated in Modula-3, then why do you need it > declared there? > > 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 01:44, Jay wrote: > > Is there a way in Modula-3 to declare that a type exists, and there > are <*external*> instances of it, without "fully" declaring it, so > that no Modula-3 can instantiate it? > > I have done this for sigset_t and sem_t, but they could erroneously > be instantiated by Modula-3 and I'd like to remove that ability to > mess up so easily. > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sigset_t = RECORD END; > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sem_t = RECORD END; > > In C I believe you can do this, like: > typedef struct foo foo_t; > extern foo_t foo; > > void UseFoo(foo_t*); > foo_t* GetFoo(void); > > Thanks, > - Jay > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 08:59:09 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 07:59:09 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: <5406617A-EFAC-4506-B6F7-F1EFCE4A230E@cs.purdue.edu> References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> <5406617A-EFAC-4506-B6F7-F1EFCE4A230E@cs.purdue.edu> Message-ID: Understood. It should be ok now (well, "better" at least). > I just compile and ship the packages in the right order. Most folks claim an inability to do that actually. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:52:34 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it? There are some of us around who don't use your scripts and expect to be able to build any package using cm3 out of the box. I don't use scripts for my bootstrapping -- I just compile and ship the packages in the right order. On 12 Jan 2009, at 18:32, Jay wrote: I didn't slow it back down yet, but I changed to a relative path instead of ROOT.All the scripts define ROOT and my config files ferry environment variable CM3_ROOT to ROOT.(ROOT is too generic for an environment variable.)oh -- m3core or sysytils?sysutils needed it. I don't see what m3core does. - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] declaring a type's existance but not enough to instantiate it?Date: Mon, 12 Jan 2009 07:27:09 +0000Huh..that's what I was saying about the way m3overrides work -- the directory structure IS duplicated /everywhere/.. I don't know what choice there is, if quake code is to be shared across packages. m3tests does the same sort of thing, also to me. Ok, hold, I'll slow sysutils back down. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:24:43 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?Jay, What the hell is the ROOT variable supposed to do now. I can't build m3core with a compiler that doesn't define ROOT. And why does the m3makefile that includes Uwaitpid.quake expect a hardwired cm3 directory hierarchy. Surely, I should be able to build m3core as a separate package, regardless of the structure in which it appears. You are doing damage to the package structures here too, by hardwiring these paths into the m3makefile. -- Tony On 12 Jan 2009, at 17:58, Jay wrote: We have conflicting goals. Keeping things as fast as possible and with as little C as possible, vs. keeping things more portable, more easily ported, more obviously correct. I want to drastically reduce the header cloning, or, the work of porting. It is already reduced, but I want to keep going. I think having to make any changes at all in m3-libs/m3core/src/unix can be removed, other than adding the platform to the list of platforms that uses the "portable" stuff.Porting would devolve to: update the lists of platforms -- including some in m3makefiles update Target.m3 clone/edit Csetjmp.i3 add the GNU platform to m3cc/src/makefile and maybe nothing else. It is likely even that the IR is now portable, for "Posix" systems.Pick word size, pick endian, generate 4 versions of IR, pick the right one for your platform.Except for the OSConfigPosix that sometimes returns the platform name and cm3's defining "HOST". A variable isn't great, but it is faster and more source compatible than a function call, at least.And the C variable really will generally be read only. Writes to it should fault. > In this particular case, you are wanting to use a Modula-3 parameter > passing mechanism on something that is not declared in Modula-3. Isn't this just a variation on what is done all the time? -- having Modula-3 call C and sometimes vice versa?C code calls Modula-3 signal handlers, with data created in the C code. The Modula-3 code can then pass them on. I don't see the line really. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 12:32:15 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it? Jay, I really think you are bending over backwards too far just to be able to shoe-horn things into C. I *like* having the transpar of C header files expressed in Modula-3, *particularly* for system calls, where you might even be trying to build on a system that does not have the C header files installed, even though the libraries exist and can be linked to. Fundamentally, I think anytime the Modula-3 code is made less transparent you should think hard about what you are doing. The same with the change of constants to variables. I am getting very nervous that the changes you are making are destroying the clarity of the Modula-3 run-time code. In this particular case, you are wanting to use a Modula-3 parameter passing mechanism on something that is not declared in Modula-3. Seems kind of dubious to me. Also, I really don't like the idea of accessing external variables in C. -- Tony On 12 Jan 2009, at 11:55, Jay wrote: I considered ADDRESS.However I think it still doesn't satisfy. I want to be able to do this: TYPE Foo_t = something;<* EXTERNAL *> VAR Foo1, Foo2:Foo_t;<* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); (* Modula-3, not external *)PROCEDURE x()=BEGIN UseFoo(Foo1); UseFoo(Foo2);END x; AND I want any use of:VAR Foo3:Foo3_t; (* Modula-3, not external *)to error. This is sem_t and sigset_t in particular. Possibly renaming is the thing.They used to be declared in Modula-3, system-dependently, butI moved them to portable C. I could remove the types entirely and change UseFoo to take an address,and declare mask and ackSem to be integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END; That would satisfy but I thought it might be nicer to still provide the namedtypes to refer to the external variables. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?What's wrong with using ADDRESS for references to opaque values? If sigset_t is never instantiated in Modula-3, then why do you need it declared there? 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 01:44, Jay wrote: Is there a way in Modula-3 to declare that a type exists, and there are <*external*> instances of it, without "fully" declaring it, so that no Modula-3 can instantiate it? I have done this for sigset_t and sem_t, but they could erroneously be instantiated by Modula-3 and I'd like to remove that ability to mess up so easily. (* This type is not declared correctly. It is only instantiated in C code. *) sigset_t = RECORD END;(* This type is not declared correctly. It is only instantiated in C code. *) sem_t = RECORD END;In C I believe you can do this, like: typedef struct foo foo_t; extern foo_t foo; void UseFoo(foo_t*); foo_t* GetFoo(void); Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 09:02:37 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 08:02:37 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: If old compiler can't build m3core, such as if old compiler predates LONGINT. You already know this. Are we "past" such compilers? - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:51:08 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3 Why do you not build in the following order to get a new compiler? (You may need to downgrade Compiler.tmpl for use with an old compiler so that you don't get a mismatch between m3core and libm3, but otherwise the following sequence should work). m3core libm3 sysutils m3middle m3objfile m3linker m3back m3front m3quake cm3 On 12 Jan 2009, at 18:25, Jay wrote: The compiler uses sysutils. The first pass builds against an old package store, which might not have sysutils at all, if it is that old. Again, once new m3core is around, no problem.I could/should have put in the m3core change and just waited on the sysutils change, rather than go ahead and do the quake stuff, and we can do that now (or your change that moots it, which I haven't looked into yet). I was browsing the docs and it appears there is an "import_pkg" directive for like, copying in a package contents, instead of linking. That might also solve this. I found that relatively late and never looked into it. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:19:55 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3Not true. sysutils should be built against the m3core with which it will be linked. I don't think this is correct. On 12 Jan 2009, at 17:58, Jay wrote: To bootstrap I believe. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 17:53:02 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3Why does sysutils need to be compatible with both old and new versions of m3core? On 12 Jan 2009, at 17:39, Jay wrote: ThreadPosix is basically unaffected -- I never provided user threads on Cygwin. I guess it got a slight reduction regarding DoesWaitPidYield, but its SchedulerPosix implementation was unchanged. The code in ThreadPosix is similar to but different than ThreadPThread.It is possible they could be merged but it wasn't trivial so I left ThreadPosix alone. > You are smearing implementation details across multiple files and directories You really think it is bad to have SchedulerPosix implemented in a small separate file?On top of what happens to be common implementation details of ThreadPThread.m3 and ThreadWin32.m3? ThreadPScheduler.m3 is just basically three functions: IOWait, IOAlertWait, XIOWaitPlus the little internal utility, UTimeFromTime, the one liner DoesWaitPidYield, and non-trivial functions nested in XIOWait: TestFDS, CallSelect. I mean, you know, an alternative is to copy out very large chunks of ThreadWin32.m3 and ThreadPThread.m3 and merge them into ThreadCygwin.m3. That would be worse imho. "Directories" hardly. Or I can try debugging cygwin pthreads again. - Jay CC: jkrell at elego.de; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 12:46:54 +1100You are smearing implementation details across multiple files and directories. Up until now, ThreadPThread has been nicely self-contained, and captured all the basic pieces of the thread implementation. Also, how does all of this fit with the ThreadPosix implementation? On 12 Jan 2009, at 12:19, Jay wrote: btw, I don't think it's that hairy, I merely split it into two or three files, and added interfaces so they can reuse code with each other. Movement between files is hard to track though (depending on version control, but with all I've used). The SchedulerPosix implementation moved to ThreadPScheduler.m3.What is shared between it and ThreadPThread/Win32.m3 is ThreadInternal.i3, which maybe should be in ThreadF.i3, though that's exposed outside m3core, and ThreadInternal.i3 includes a variable. I can try again to debug Cygwin pthreads though. - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:03:33 +1100> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Jay,> > Can you remind me again why Cygwin was unable to use pthreads? It > seems you have introduced a bunch of hair into the PTHREADS > implementation to deal with broken Cygwin pthreads. As many of us > have already pointed out, Cygwin should be a port that tries as much > as possible to be like a standard POSIX platform (pthread-based) as > opposed to a weird Windows/POSIX hybrid.> > I have a bunch of code that will be going into the PTHREADS base that > I am now at a loss to integrate with the changes you have made.> > Help!> > -- Tony> -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: [M3devel] [M3commit] 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:18:29 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 08:18:29 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> Message-ID: I don't think a development system without C headers is interesting.. Is it really? The transform I apply at times is wherever there is interaction with C code that is described by system-dependent headers, or perhaps even fairly system-independent headers outside the Modula-3 tree, either write wrapper functions for the functionality in the headers (e.g. stat, waitpid), which can be done in a system-independent way, or move the Modula-3<->C transition higher, which is also usually system-independent, e.g. ThreadPThreadC_SetupHandlers. It is either that or clone the headers, which seems like the worse evil. There is always going to be a Modula-3<->C transition, it is just a matter of where it occurs. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?Date: Mon, 12 Jan 2009 12:32:15 +1100 Jay, I really think you are bending over backwards too far just to be able to shoe-horn things into C. I *like* having the transpar of C header files expressed in Modula-3, *particularly* for system calls, where you might even be trying to build on a system that does not have the C header files installed, even though the libraries exist and can be linked to. Fundamentally, I think anytime the Modula-3 code is made less transparent you should think hard about what you are doing. The same with the change of constants to variables. I am getting very nervous that the changes you are making are destroying the clarity of the Modula-3 run-time code. In this particular case, you are wanting to use a Modula-3 parameter passing mechanism on something that is not declared in Modula-3. Seems kind of dubious to me. Also, I really don't like the idea of accessing external variables in C. -- Tony On 12 Jan 2009, at 11:55, Jay wrote: I considered ADDRESS.However I think it still doesn't satisfy. I want to be able to do this: TYPE Foo_t = something;<* EXTERNAL *> VAR Foo1, Foo2:Foo_t;<* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); (* Modula-3, not external *)PROCEDURE x()=BEGIN UseFoo(Foo1); UseFoo(Foo2);END x; AND I want any use of:VAR Foo3:Foo3_t; (* Modula-3, not external *)to error. This is sem_t and sigset_t in particular. Possibly renaming is the thing.They used to be declared in Modula-3, system-dependently, butI moved them to portable C. I could remove the types entirely and change UseFoo to take an address,and declare mask and ackSem to be integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END; That would satisfy but I thought it might be nicer to still provide the namedtypes to refer to the external variables. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?What's wrong with using ADDRESS for references to opaque values? If sigset_t is never instantiated in Modula-3, then why do you need it declared there? 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 01:44, Jay wrote: Is there a way in Modula-3 to declare that a type exists, and there are <*external*> instances of it, without "fully" declaring it, so that no Modula-3 can instantiate it? I have done this for sigset_t and sem_t, but they could erroneously be instantiated by Modula-3 and I'd like to remove that ability to mess up so easily. (* This type is not declared correctly. It is only instantiated in C code. *) sigset_t = RECORD END;(* This type is not declared correctly. It is only instantiated in C code. *) sem_t = RECORD END;In C I believe you can do this, like: typedef struct foo foo_t; extern foo_t foo; void UseFoo(foo_t*); foo_t* GetFoo(void); Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 09:22:13 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 19:22:13 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: I think there is a straightforward fix for old compilers that can't compile LONGINT: define LongRep.T = INTEGER. Most everything should compile from there. That's what I recall doing to upgrade my compiler to handle LONGINT. LONGINT is not used anywhere else in m3core, so nothing depends on it working. On 12 Jan 2009, at 19:02, Jay wrote: > If old compiler can't build m3core, such as if old compiler predates > LONGINT. > You already know this. > Are we "past" such compilers? > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 18:51:08 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > Why do you not build in the following order to get a new compiler? > (You may need to downgrade Compiler.tmpl for use with an old > compiler so that you don't get a mismatch between m3core and libm3, > but otherwise the following sequence should work). > > m3core > libm3 > sysutils > m3middle > m3objfile > m3linker > m3back > m3front > m3quake > cm3 > > On 12 Jan 2009, at 18:25, Jay wrote: > > The compiler uses sysutils. The first pass builds against an old > package store, which might not have sysutils at all, if it is that > old. > > Again, once new m3core is around, no problem. > I could/should have put in the m3core change and just waited on the > sysutils change, rather than go ahead and do the quake stuff, and we > can do that now (or your change that moots it, which I haven't > looked into yet). > > I was browsing the docs and it appears there is an "import_pkg" > directive for like, copying in a package contents, instead of > linking. That might also solve this. I found that relatively late > and never looked into it. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 18:19:55 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Not true. sysutils should be built against the m3core with which it > will be linked. I don't think this is correct. > > On 12 Jan 2009, at 17:58, Jay wrote: > > To bootstrap I believe. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 17:53:02 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Why does sysutils need to be compatible with both old and new > versions of m3core? > > On 12 Jan 2009, at 17:39, Jay wrote: > > ThreadPosix is basically unaffected -- I never provided user threads > on Cygwin. > I guess it got a slight reduction regarding DoesWaitPidYield, but > its SchedulerPosix implementation was unchanged. > > The code in ThreadPosix is similar to but different than > ThreadPThread. > It is possible they could be merged but it wasn't trivial so I left > ThreadPosix alone. > > > You are smearing implementation details across multiple files and > directories > > You really think it is bad to have SchedulerPosix implemented in a > small separate file? > On top of what happens to be common implementation details of > ThreadPThread.m3 and ThreadWin32.m3? > > ThreadPScheduler.m3 is just basically three functions: IOWait, > IOAlertWait, XIOWait > Plus the little internal utility, UTimeFromTime, the one liner > DoesWaitPidYield, and non-trivial functions nested in XIOWait: > TestFDS, CallSelect. > > I mean, you know, an alternative is to copy out very large chunks of > ThreadWin32.m3 and ThreadPThread.m3 and merge them into > ThreadCygwin.m3. That would be worse imho. > > "Directories" hardly. > > Or I can try debugging cygwin pthreads again. > > - Jay > > > CC: jkrell at elego.de; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Mon, 12 Jan 2009 12:46:54 +1100 > > You are smearing implementation details across multiple files and > directories. Up until now, ThreadPThread has been nicely self- > contained, and captured all the basic pieces of the thread > implementation. Also, how does all of this fit with the ThreadPosix > implementation? > > On 12 Jan 2009, at 12:19, Jay wrote: > > btw, I don't think it's that hairy, I merely split it into two or > three files, and added interfaces so they can reuse code with each > other. Movement between files is hard to track though (depending on > version control, but with all I've used). > > The SchedulerPosix implementation moved to ThreadPScheduler.m3. > What is shared between it and ThreadPThread/Win32.m3 is > ThreadInternal.i3, which maybe should be in ThreadF.i3, though > that's exposed outside m3core, and ThreadInternal.i3 includes a > variable. > > I can try again to debug Cygwin pthreads though. > > - Jay > > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:03:33 +1100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay, > > > > Can you remind me again why Cygwin was unable to use pthreads? It > > seems you have introduced a bunch of hair into the PTHREADS > > implementation to deal with broken Cygwin pthreads. As many of us > > have already pointed out, Cygwin should be a port that tries as much > > as possible to be like a standard POSIX platform (pthread-based) as > > opposed to a weird Windows/POSIX hybrid. > > > > I have a bunch of code that will be going into the PTHREADS base > that > > I am now at a loss to integrate with the changes you have made. > > > > Help! > > > > -- Tony > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 09:24:50 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 19:24:50 +1100 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> Message-ID: <54BC9DFC-09FC-4082-9E10-694EAAF6E5EC@cs.purdue.edu> Point taken. We live in a C universe and so need to interact. I do think your work with the headers is useful, and I want it to continue. Especially in simplifying ports. On 12 Jan 2009, at 19:18, Jay wrote: > I don't think a development system without C headers is > interesting.. Is it really? > > The transform I apply at times is wherever there is interaction with > C code that is described by system-dependent headers, or perhaps > even fairly system-independent headers outside the Modula-3 tree, > either write wrapper functions for the functionality in the headers > (e.g. stat, waitpid), which can be done in a system-independent way, > or move the Modula-3<->C transition higher, which is also usually > system-independent, e.g. ThreadPThreadC_SetupHandlers. > > It is either that or clone the headers, which seems like the worse > evil. > > There is always going to be a Modula-3<->C transition, it is just a > matter of where it occurs. > > - Jay > > > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > Date: Mon, 12 Jan 2009 12:32:15 +1100 > > > Jay, I really think you are bending over backwards too far just to > be able to shoe-horn things into C. I *like* having the transpar of > C header files expressed in Modula-3, *particularly* for system > calls, where you might even be trying to build on a system that does > not have the C header files installed, even though the libraries > exist and can be linked to. Fundamentally, I think anytime the > Modula-3 code is made less transparent you should think hard about > what you are doing. The same with the change of constants to > variables. > > I am getting very nervous that the changes you are making are > destroying the clarity of the Modula-3 run-time code. > > In this particular case, you are wanting to use a Modula-3 parameter > passing mechanism on something that is not declared in Modula-3. > Seems kind of dubious to me. Also, I really don't like the idea of > accessing external variables in C. > > -- Tony > > On 12 Jan 2009, at 11:55, Jay wrote: > > I considered ADDRESS. > However I think it still doesn't satisfy. > > I want to be able to do this: > > TYPE Foo_t = something; > <* EXTERNAL *> VAR Foo1, Foo2:Foo_t; > <* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); > > (* Modula-3, not external *) > PROCEDURE x()= > BEGIN > UseFoo(Foo1); > UseFoo(Foo2); > END x; > > AND I want any use of: > VAR Foo3:Foo3_t; (* Modula-3, not external *) > > to error. This is sem_t and sigset_t in particular. > > Possibly renaming is the thing. > They used to be declared in Modula-3, system-dependently, but > I moved them to portable C. > > I could remove the types entirely and change UseFoo to take an > address, > and declare mask and ackSem to be integers or I guess. > <*EXTERNAL> VAR ackSem : RECORD END; > > That would satisfy but I thought it might be nicer to still provide > the named > types to refer to the external variables. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 11:13:00 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] declaring a type's existance but not enough > to instantiate it? > > What's wrong with using ADDRESS for references to opaque values? If > sigset_t is never instantiated in Modula-3, then why do you need it > declared there? > > 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 01:44, Jay wrote: > > Is there a way in Modula-3 to declare that a type exists, and there > are <*external*> instances of it, without "fully" declaring it, so > that no Modula-3 can instantiate it? > > I have done this for sigset_t and sem_t, but they could erroneously > be instantiated by Modula-3 and I'd like to remove that ability to > mess up so easily. > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sigset_t = RECORD END; > > (* This type is not declared correctly. It is only instantiated in C > code. *) > sem_t = RECORD END; > > In C I believe you can do this, like: > typedef struct foo foo_t; > extern foo_t foo; > > void UseFoo(foo_t*); > foo_t* GetFoo(void); > > Thanks, > - Jay > > > > > > > -------------- 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: [M3devel] [M3commit] 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 jay.krell at cornell.edu Mon Jan 12 09:47:17 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 08:47:17 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: <54BC9DFC-09FC-4082-9E10-694EAAF6E5EC@cs.purdue.edu> References: <5502020C-EDF4-41E0-8AC1-9E8BFB1245DA@cs.purdue.edu> <2623CEFB-459F-4AFB-814C-A2941A06F349@cs.purdue.edu> <54BC9DFC-09FC-4082-9E10-694EAAF6E5EC@cs.purdue.edu> Message-ID: This is what you "have to" chose between. Header cloning or C code (and C headers). CONST or VAR (or functions?) I'm going to likely make the Uerror change tonight. You can still veto it (er, vote against it :) ) Possibly some convuluted C (enum/#undef), or splitting the Modula-3 at boundaries that weren't previously believed "natural". (See how SetupHandlers is ~two lines in Modula-3 and the rest in C; this is partly out of ignorance. I don't know how to write those two lines in C; and laziness, I didn't look into how). Remember I'm still staying away from mainstream platforms, so the value isn't what it might appear to be, but it is "stage setting", and the show might go on. :) Also, the dilemna does get more difficult now, with the little C header cloning that remains. For example, look at Upthreads.i3. Mainly, look at function prototypes. Constants and types are "known problems". Prototypes are gray. They actually tend to be portable. For example: TYPE pid_t = INTEGER; <*EXTERNAL "m3_getpid*> PROCEDURE getpid():pid_t; or leave it alone? getpid is probably the worst example. It is so very portable declared in Modula-3. But still, imagine pid_t might be 16bits or 32 or 64. Writing a wrapper is more portable -- as long as the pid isn't stuff into some record that the system defines. Again, Upthreads.i3. Would you like to see it reduced, or left alone? Only deal with the types and initializers, or also the prototypes? You know, I could write a little portable layer, where all the types are pointers, always null initialized. It would buy /some/ portability, and cost some. Do you like the sem_t change? Partly? Not at all? There is one sem_t in the system. So I moved it to be in C code. Or, as I had it before, declared as the max size/align of all the platforms -- getting that right is the same work as getting it right "the old way", except if you make a mistake, odds are still good of it being ok. Should the line be drawn at generating the remaining headers, rather than eliminating them? Uerror.i3 is easily generated. Good enough? Upthread.i3's types can be generated generally as records with opaque arrays with the right size and alignment. Other stuff can be generated or at least checked. e.g. to check that getpid is declared correctly, you can assign it to a function pointer and see if that compiles. Perf on Uerror arguably doesn't matter. Is it only error handling code?Or do sockets often go down "error" paths, because they are slow and you are waiting for more data? Anyway, point is, I agree for sure this is valuable, but I might be hitting the "tail" of the approach and should switch, I'm not sure. I keep saying that though, and then press further. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 19:24:50 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it? Point taken. We live in a C universe and so need to interact. I do think your work with the headers is useful, and I want it to continue. Especially in simplifying ports. On 12 Jan 2009, at 19:18, Jay wrote: I don't think a development system without C headers is interesting.. Is it really? The transform I apply at times is wherever there is interaction with C code that is described by system-dependent headers, or perhaps even fairly system-independent headers outside the Modula-3 tree, either write wrapper functions for the functionality in the headers (e.g. stat, waitpid), which can be done in a system-independent way, or move the Modula-3<->C transition higher, which is also usually system-independent, e.g. ThreadPThreadC_SetupHandlers. It is either that or clone the headers, which seems like the worse evil. There is always going to be a Modula-3<->C transition, it is just a matter of where it occurs. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?Date: Mon, 12 Jan 2009 12:32:15 +1100 Jay, I really think you are bending over backwards too far just to be able to shoe-horn things into C. I *like* having the transpar of C header files expressed in Modula-3, *particularly* for system calls, where you might even be trying to build on a system that does not have the C header files installed, even though the libraries exist and can be linked to. Fundamentally, I think anytime the Modula-3 code is made less transparent you should think hard about what you are doing. The same with the change of constants to variables. I am getting very nervous that the changes you are making are destroying the clarity of the Modula-3 run-time code. In this particular case, you are wanting to use a Modula-3 parameter passing mechanism on something that is not declared in Modula-3. Seems kind of dubious to me. Also, I really don't like the idea of accessing external variables in C. -- Tony On 12 Jan 2009, at 11:55, Jay wrote: I considered ADDRESS.However I think it still doesn't satisfy. I want to be able to do this: TYPE Foo_t = something;<* EXTERNAL *> VAR Foo1, Foo2:Foo_t;<* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); (* Modula-3, not external *)PROCEDURE x()=BEGIN UseFoo(Foo1); UseFoo(Foo2);END x; AND I want any use of:VAR Foo3:Foo3_t; (* Modula-3, not external *)to error. This is sem_t and sigset_t in particular. Possibly renaming is the thing.They used to be declared in Modula-3, system-dependently, butI moved them to portable C. I could remove the types entirely and change UseFoo to take an address,and declare mask and ackSem to be integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END; That would satisfy but I thought it might be nicer to still provide the namedtypes to refer to the external variables. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?What's wrong with using ADDRESS for references to opaque values? If sigset_t is never instantiated in Modula-3, then why do you need it declared there? 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 01:44, Jay wrote: Is there a way in Modula-3 to declare that a type exists, and there are <*external*> instances of it, without "fully" declaring it, so that no Modula-3 can instantiate it? I have done this for sigset_t and sem_t, but they could erroneously be instantiated by Modula-3 and I'd like to remove that ability to mess up so easily. (* This type is not declared correctly. It is only instantiated in C code. *) sigset_t = RECORD END;(* This type is not declared correctly. It is only instantiated in C code. *) sem_t = RECORD END;In C I believe you can do this, like: typedef struct foo foo_t; extern foo_t foo; void UseFoo(foo_t*); foo_t* GetFoo(void); Thanks, - Jay -------------- 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: [M3devel] [M3commit] 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: [M3devel] [M3commit] 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 mika at async.caltech.edu Mon Jan 12 10:06:30 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 12 Jan 2009 01:06:30 -0800 Subject: [M3devel] Juno (X) networking problem on AMD64_FREEBSD In-Reply-To: Your message of "Sun, 11 Jan 2009 22:02:18 GMT." Message-ID: <200901120906.n0C96Uwn074046@camembert.async.caltech.edu> Jay, I think the problem here is actually in the caller. Why does a caller need "GetHostAddr()"? It is probably doing this for the purpose of calling listen() or some such thing. What the caller probably *really* wants is INADDR_ANY, and not the IP address of some arbitrarily chosen interface on the host. I'm guessing it works on the Mac because the Mac libraries do something complicated when you ask for the host's name (i.e., they somehow generate a hostname that always maps to the IP address of an interface on the computer). Mika Jay writes: >--_b00371fe-730b-4981-9051-a874361296d7_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Do you know the right way? >=20 >PPC_LINUX "just worked"=2C and I can check Solaris and Darwin. >=20 >I don't want to edit /etc/hosts -- I use DHCP. >Though DHCP has been bothering me -- only for some of my machines do names = >resolve=2C so I end using IP addresses=2C which change sometimes=2C and I l= >oop over them running ssh to all of them and "see what I get"=2C not ideal. >=20 > - Jay> To: jay.krell at cornell.edu> Date: Sun=2C 11 Jan 2009 08:02:18 -0800>= > From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3d= >evel] Juno (X) networking problem on AMD64_FREEBSD> > This is a screwy thin= >g in Modula-3. A bug I would call it.> > I've noticed a lot of networking M= >3 programs don't work right unless> the return value of Unix's "hostname" m= >aps to a real IP address via> gethostbyname. I accomplish it in practice by= > adding my hostname> to /etc/hosts.> > This is obviously not the right way = >to fix it... > > Mika> > Jay writes:> >--_9e67232c-a064-417d-879e-227a77e31= >0f9_> >Content-Type: text/plain=3B charset=3D"iso-8859-1"> >Content-Transfe= >r-Encoding: quoted-printable> >> >> >Hi. Unix network programming question.= >.> >AMD64_FREEBSD:> >$DISPLAY is set to point back to Cygwin host.It works = >for PPC_LINUX.> >[jay at fbsdamd64a /cm3/bin]$ ./Juno> >****** runtime error:*= >** Exception "IPError.FatalError" not in RAISES li=3D> >st*** file "../src/= >common/IPError.m3"=3D2C line 27***> >Abort trap: 6 (core dumped)[jay at fbsdam= >d64a /cm3/bin]$> >IP.m3:> >=3D20> >PROCEDURE GetHostAddr(): Address =3D3D V= >AR hname: ARRAY [0..255] OF CHAR=3D3B =3D> > BEGIN LOCK mu DO IF Unix.getho= >stname(ADR(hname[0])=3D2C BYTESIZE(hna=3D> >me)) # 0 THEN IPError.Die ()=3D= >3B END=3D3B VAR h :=3D3D Unetdb.g=3D> >ethostbyname(ADR(hname[0]))=3D3B BEG= >IN IF h =3D3D NIL THEN IPError.Die()=3D> >=3D3B END=3D3B RETURN GetAddress(= >h)=3D3B END=3D3B END=3D3B END GetHos=3D> >tAddr=3D3B> >PROCEDURE GetAddress= > (ent: Unetdb.struct_hostent_star): Address =3D3D VAR ua=3D> >: Uin.struct_= >in_addr=3D3B BEGIN <* ASSERT ent.h_length <=3D3D BYTESIZE(Addr=3D> >ess) *>= > ua :=3D3D LOOPHOLE(ent.h_addr_list=3D2C UNTRACED =3D> >REF UNTRACED REF Ui= >n.struct_in_addr)^^=3D3B RETURN LOOPHOLE(ua.s_addr=3D2C A=3D> >ddress)=3D3B= > END GetAddress=3D3B> >=3D20> >gethostbyname is failing.> >=3D20> >Analogou= >s C code also fails:> >=3D20> >[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c#include= > #include #i=3D> >nclude #include type= >def struct hostent hostent_t=3D3B> >=3D20> >int main(){ char hostname[200]= >=3D3B hostent_t* h=3D3B int i=3D3B> > i =3D3D gethostname(hostname=3D2C 200= >)=3D3B assert(i =3D3D=3D3D 0)=3D3B printf("hostna=3D> >me: %s\n"=3D2C hostn= >ame)=3D3B h =3D3D gethostbyname(hostname)=3D3B herror("foo")=3D3B=3D> > pri= >ntf("%p %d %d\n"=3D2C h=3D2C errno=3D2C h_errno)=3D3B assert(h)=3D3B return= > 0=3D3B}> >=3D20> >herror says "unknown host".> >Stack is:> > at ../src/run= >time/ex_frame/RTExFrame.m3:58#13 0x0000000801a7f2b3 in RTH=3D> >ooks__Raise= > (M3_AJWxb1_ex=3D3DError accessing memory address 0x8000ffffd278: =3D> >Bad= > address.) at ../src/runtime/common/RTHooks.m3:79#14 0x000000080169c8=3D> >= >d3 in IPError__Die () at ../src/common/IPError.m3:27#15 0x0000000801698a3e = >=3D> >in IP__GetHostAddr (M3_BCxjPn__result=3D3DError accessing memory addr= >ess 0x80=3D> >00ffffd338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x00000= >008012133d0=3D> > in XSharedMem__SameHost (M3_AQuuui_trsl=3D3DError accessi= >ng memory address 0=3D> >x8000ffffd4d8: Bad address.) at ../src/xvbt/XShare= >dMem.m3:96#17 0x000000=3D> >0801212ab7 in XSharedMem__InitXClient (M3_AQuuu= >i_v=3D3DError accessing memory=3D> > address 0x8000ffffd648: Bad address.) = >at ../src/xvbt/XSharedMem.m3:29#1=3D> >8 0x0000000801211819 in XExtensions_= >_InitXClient (M3_AQuuui_xclient=3D3DError=3D> > accessing memory address 0x= >8000ffffd7f8: Bad address.) at ../src/xvbt/X=3D> >Extensions.m3:14#19 0x000= >00008012467a4 in XClientF__Connect (M3_Bd56fi_inst=3D> >=3D3D0x1879b=3D2C M= >3_AQuuui_trsl=3D3D0x6) at ../src/xvbt/XClientF.m3:583---Typ=3D> >e = > to continue=3D2C or q to quit---(More stack frames follow=3D> >..= >.)(gdb)> >(* return TRUE if server and client are on same host *)PROCEDURE = >SameHost (=3D> >trsl: XClient.T): BOOLEAN =3D3D VAR display :=3D3D DisplayH= >=3D> >ost(trsl)=3D3B displayAddr: IP.Address=3D3B BEGIN IF display =3D3D NI= >L THE=3D> >N RETURN TRUE=3D3B END=3D3B> > TRY IF NOT IP.GetHostByName(displ= >ay=3D2C displayAddr) THEN RETURN FA=3D> >LSE=3D3B END=3D3B RETURN displayAd= >dr =3D3D IP.GetHostAddr()=3D3B EXCEPT =3D> >| IP.Error =3D3D> RETURN FALSE= >=3D3B END=3D3B END SameHost=3D3B> >=3D20> >Thoughts?> >=3D20> >Perhaps my n= >etwork isn't setup well=3D2C like I should add the local machine =3D> >to /= >etc/hosts.I think this can be made to fail gracefully though.It seems l=3D>= > >ike it has nothing to do with AMD64_FREEBSD=3D2C but could have to do wit= >h Fr=3D> >eeBSD.> >=3D20> >Seems like SocketPosix has nearly the exact same= > code but appearsmore forgi=3D> >ving.. IOError instead of Fatal?> >=3D20> = >>SocketPosix.m3:> >=3D20> >PROCEDURE GetHostAddr (): Address RAISES {OSErro= >r.E} =3D3D VAR host : AR=3D> >RAY [0..255] OF CHAR=3D3B info : Unetdb.struc= >t_hostent_star=3D3B ua : U=3D> >in.struct_in_addr=3D3B BEGIN IF Unix.gethos= >tname (ADR (host[0])=3D2C BYTESI=3D> >ZE (host)) # 0 THEN IOError (Unexpect= >ed)=3D3B END=3D3B> > info :=3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3B = >IF info =3D3D NIL TH=3D> >EN IOError (Unexpected)=3D3B END=3D3B <* ASSERT i= >nfo.h_length <=3D3D BYTESIZE =3D> >(Address) *>> > ua :=3D3D LOOPHOLE(info.= >h_addr_list=3D2C UNTRACED REF UNT=3D> >RACED REF Uin.struct_in_addr)^^=3D3B= > RETURN LOOPHOLE (ua.s_addr=3D2C Address=3D> >)=3D3B END GetHostAddr=3D3B> = >>=3D20> >=3D20> >It is again disappointing to see such code duplication.> >= >=3D20> >=3D20> >I guess SameHost can duplicate the logic to predict the err= >or state and ret=3D> >urn false upon error?> >Duplicating the logic for a t= >hird time. :(> >=3D20> > - Jay=3D> >> >--_9e67232c-a064-417d-879e-227a77e31= >0f9_> >Content-Type: text/html=3B charset=3D"iso-8859-1"> >Content-Transfer= >-Encoding: quoted-printable> >> >> >> >> >> >mmessage'>> >Hi. Unix network programming question..
> >
AMD64_FREEBS= >D:
> >
$DISPLAY is set to point back to Cygwin host.
It works for = >PPC_LINUX=3D> >.
> >
[jay at fbsdamd64a /cm3/bin]$ ./Juno
> >
***<= >BR>*** runtime error:
*** =3D3B =3D3B =3D3B Exception "IPE= >=3D> >rror.FatalError" not in RAISES list
*** =3D3B =3D3B = >=3D3B file "..=3D> >/src/common/IPError.m3"=3D2C line 27
***
> >
A= >bort trap: 6 (core dumped)
[jay at fbsdamd64a /cm3/bin]$
> >
IP.m3:R>> > =3D3B
> >PROCEDURE GetHostAddr(): Address =3D3D
 =3D3B = >VAR hname: ARRAY [0..255] =3D> OF CHAR=3D3B
 =3D3B BEGIN
 =3D= >3B =3D3B =3D3B LOCK mu DO
&nbs=3D> >p=3D3B =3D3B =3D3B&n= >bsp=3D3B =3D3B IF Unix.gethostname(ADR(hname[0])=3D2C B=3D> >YTESIZE(hn= >ame)) # 0 THEN
 =3D3B =3D3B =3D3B =3D3B =3D3B = >=3D> >=3D3B =3D3B IPError.Die ()=3D3B
 =3D3B =3D3B =3D3B= > =3D3B =3D3B E=3D> >ND=3D3B
 =3D3B =3D3B =3D3B = >=3D3B =3D3B VAR h :=3D3D Unetdb.gethost=3D> >byname(ADR(hname[0]))=3D3B= > BEGIN
 =3D3B =3D3B =3D3B =3D3B =3D3B&=3D> >nbsp=3D3= >B =3D3B IF h =3D3D NIL THEN IPError.Die()=3D3B END=3D3B
 =3D3B&n= >bsp=3D> >=3D3B =3D3B =3D3B =3D3B =3D3B =3D3B RETURN Get= >Address(h)=3D3B
&nbs=3D> >p=3D3B =3D3B =3D3B =3D3B =3D3B= > END=3D3B
 =3D3B =3D3B =3D3B END=3D> >=3D3B
 =3D3B EN= >D GetHostAddr=3D3B
> >
PROCEDURE GetAddress (ent: Unetdb.struct_hoste= >nt_star): Address =3D3D
=3D> > =3D3B VAR ua: Uin.struct_in_addr=3D3B= >
 =3D3B BEGIN
 =3D3B =3D> >=3D3B =3D3B <=3D3B* ASSE= >RT ent.h_length <=3D3B=3D3D BYTESIZE(Address) *>=3D3B=3D> >
 =3D= >3B =3D3B =3D3B ua :=3D3D LOOPHOLE(ent.h_addr_list=3D2C
 =3D>= > >=3D3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D= >3B =3D3B =3D3B=3D> > =3D3B =3D3B =3D3B =3D3B = >=3D3B =3D3B =3D3B =3D3B =3D3B UN=3D> >TRACED REF UNTRACED R= >EF Uin.struct_in_addr)^^=3D3B
 =3D3B =3D3B =3D> >=3D3B RETUR= >N LOOPHOLE(ua.s_addr=3D2C Address)=3D3B
 =3D3B END GetAddress=3D3B<= >=3D> >BR>> > =3D3B
> >gethostbyname is failing.
> >
 =3D3B= >
> >Analogous C code also fails:
> > =3D3B
> >
[jay at fbsdamd= >64a /cm3/bin]$ cat ~/5.c
#include <=3D3Bassert.h>=3D3B >R>#inc= >lude <=3D3Bnetdb.h>=3D3B
#include <=3D3Bstdio.h>=3D3B
#includ= >e =3D> ><=3D3Berrno.h>=3D3B
typedef struct hostent hostent_t=3D3B>> > =3D3B
> >int main()
{
 =3D3Bchar hostname[200]=3D3BR> =3D3Bhostent_t* h=3D3B=3D> >
 =3D3Bint i=3D3B
> > =3D3= >Bi =3D3D gethostname(hostname=3D2C 200)=3D3B
 =3D3Bassert(i =3D3D=3D= >3D 0)=3D> >=3D3B
 =3D3Bprintf("hostname: %s\n"=3D2C hostname)=3D3BR> =3D3Bh =3D3D get=3D> >hostbyname(hostname)=3D3B
 =3D3Bherror(= >"foo")=3D3B
 =3D3Bprintf("%p %=3D> >d %d\n"=3D2C h=3D2C errno=3D2C h= >_errno)=3D3B
 =3D3Bassert(h)=3D3B
 =3D3Bret=3D> >urn 0=3D3BR>}
> > =3D3B
> >herror says "unknown host".
> >
Stack is:<= >BR>> > =3D3B =3D3B =3D3B at ../src/runtime/ex_frame/RTExFrame.m= >3:58
#13 =3D> >0x0000000801a7f2b3 in RTHooks__Raise (M3_AJWxb1_ex=3D3DEr= >ror accessing memory=3D> > ad
dress 0x8000ffffd278: Bad address.
)> =3D3B =3D3B =3D3B =3D> >at ../src/runtime/common/RTHooks.m3:7= >9
#14 0x000000080169c8d3 in IPError=3D> >__Die () at ../src/common/IPErr= >or.m3:27
#15 0x0000000801698a3e in IP__Ge=3D> >tHostAddr (M3_BCxjPn__res= ult=3D3DError accessing mem
ory address 0x8000fff=3D> >fd338: Bad addres= >s.
)
 =3D3B =3D3B =3D3B at ../src/POSIX/IP.m3:=3D> >82>#16 0x00000008012133d0 in XSharedMem__SameHost (M3_AQuuui_trsl=3D3DErro=3D= >> >r accessing m
emory address 0x8000ffffd4d8: Bad address.
)
&nbs= >p=3D> >=3D3B =3D3B =3D3B at ../src/xvbt/XSharedMem.m3:96
#17 0x0= >000000801212a=3D> >b7 in XSharedMem__InitXClient (M3_AQuuui_v=3D3DError acc= >essing m
emory add=3D> >ress 0x8000ffffd648: Bad address.
)
 = >=3D3B =3D3B =3D3B at ../sr=3D> >c/xvbt/XSharedMem.m3:29
#18 0x00= >00000801211819 in XExtensions__InitXClie=3D> >nt (M3_AQuuui_xclient=3D3DErr= >or acce
ssing memory address 0x8000ffffd7f8: =3D> >Bad address.
)
= > =3D3B =3D3B =3D3B at ../src/xvbt/XExtensions.m3=3D> >:14
#1= >9 0x00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst=3D3D0x1879=3D> >b= >=3D2C
 =3D3B =3D3B =3D3B M3_AQuuui_trsl=3D3D0x6) at ../src/x= >vbt/XClie=3D> >ntF.m3:583
---Type <=3D3Breturn>=3D3B to continue=3D2= >C or q <=3D3Breturn&g=3D> >t=3D3B to quit---
(More stack frames follow= >...)
(gdb)
> >
(* return TRUE if server and client are on same hos= >t *)
PROCEDURE Sa=3D> >meHost (trsl: XClient.T): BOOLEAN =3D3D
 = >=3D3B VAR
 =3D3B =3D3B&n=3D> >bsp=3D3B display =3D3B =3D= >3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D> >=3D3B = >=3D3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D3B= :=3D3D Di=3D> >splayHost(trsl)=3D3B
 =3D3B =3D3B =3D3B disp= >layAddr: IP.Address=3D3B >R> =3D3B BEGIN
 =3D3B =3D3B&= >nbsp=3D3B IF display =3D3D NIL THEN RETURN=3D> > TRUE=3D3B END=3D3B
> >&= >nbsp=3D3B =3D3B =3D3B TRY
 =3D3B =3D3B =3D3B =3D= >3B =3D3B IF=3D> > NOT IP.GetHostByName(display=3D2C displayAddr) THEN R= >ETURN FALSE=3D3B END=3D3B >R> =3D3B =3D3B =3D3B =3D3B= > =3D3B RETURN displayAddr =3D3D IP.GetHos=3D> >tAddr()=3D3B
 =3D= >3B =3D3B =3D3B EXCEPT
 =3D3B =3D3B =3D3B |=3D> > IP.= >Error =3D3D>=3D3B RETURN FALSE=3D3B
 =3D3B =3D3B =3D3B END= >=3D3B
&=3D> >nbsp=3D3B END SameHost=3D3B
> > =3D3B
> >Thoughts= >?
> > =3D3B
> >
Perhaps my network isn't setup well=3D2C like = >I should add the local mach=3D> >ine to /etc/hosts.
I think this can be = >made to fail gracefully though. >R>It seems like it has nothing to do= > with AMD64_FREEBSD=3D2C but could have t=3D> >o do with FreeBSD.
> >> =3D3B
> >Seems like SocketPosix has nearly the exact same code but= > appears
more f=3D> >orgiving.. IOError instead of Fatal?
> > =3D= >3B
> >
SocketPosix.m3:
> > =3D3B
> >
PROCEDURE GetHostAd= >dr (): Address
 =3D3B RAISES {OSError.E} =3D3D >> =3D3B V= >AR
 =3D3B =3D3B =3D3B host : ARRAY [0..255] OF CHAR=3D3B<=3D= >> >BR> =3D3B =3D3B =3D3B info : Unetdb.struct_hostent_star=3D3B= >
 =3D> >=3D3B =3D3B =3D3B ua =3D3B =3D3B : Uin.struc= >t_in_addr=3D3B
 =3D3B =3D> >BEGIN
 =3D3B =3D3B =3D3B = >IF Unix.gethostname (ADR (host[0])=3D2C BYT=3D> >ESIZE (host)) # 0 THEN
= > =3D3B =3D3B =3D3B =3D3B =3D3B IOError =3D> >(Unexpecte= >d)=3D3B
 =3D3B =3D3B =3D3B END=3D3B
> > =3D3B =3D= >3B =3D3B info :=3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3B<=3D> >BR= >> =3D3B =3D3B =3D3B IF info =3D3D NIL THEN IOError (Unexpected)= >=3D3B EN=3D> >D=3D3B
 =3D3B =3D3B =3D3B <=3D3B* ASSERT inf= >o.h_length <=3D3B=3D3D BYT=3D> >ESIZE (Address) *>=3D3B
> > =3D3= >B =3D3B =3D3B ua :=3D3D LOOPHOLE(info.h_addr_list=3D2C
 =3D3= >B&n=3D> >bsp=3D3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D= >3B =3D3B =3D3B =3D> >=3D3B =3D3B =3D3B =3D3B = >=3D3B =3D3B =3D3B =3D3B UNTRACED REF UN=3D> >TRACED REF Uin.str= >uct_in_addr)^^=3D3B
 =3D3B =3D3B =3D3B RETURN LOOP=3D> >HOLE= > (ua.s_addr=3D2C Address)=3D3B
 =3D3B END GetHostAddr=3D3B
> >&nb= >sp=3D3B
> > =3D3B
> >It is again disappointing to see such code d= >uplication.
> > =3D3B
> > =3D3B
> >I guess =3D3BSameHo= >st can duplicate the logic to predict the error state =3D> >and return fals= >e =3D3Bupon error?
> >Duplicating the logic for a third time. :(
= >> > =3D3B
> >
 =3D3B- Jay

> >=3D> >> >--= >_9e67232c-a064-417d-879e-227a77e310f9_--= > >--_b00371fe-730b-4981-9051-a874361296d7_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Do you know the right way?
> =3B
>PPC_LINUX "just worked"=2C and I can check Solaris and Darwin.
> =3B
>I don't want to edit /etc/hosts -- I use DHCP.
>Though DHCP has been bothering me -- only for some of my machines do names = >resolve=2C so I end using IP addresses=2C which change sometimes=2C and I l= >oop over them running ssh to all of them and "see what I get"=2C not ideal.= >
> =3B
> =3B- Jay


>=3B To: jay.krell at cornell.edu
>=3B Date: S= >un=2C 11 Jan 2009 08:02:18 -0800
>=3B From: mika at async.caltech.edu
= >>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] Juno (X) = >networking problem on AMD64_FREEBSD
>=3B
>=3B This is a screwy t= >hing in Modula-3. A bug I would call it.
>=3B
>=3B I've noticed = >a lot of networking M3 programs don't work right unless
>=3B the retur= >n value of Unix's "hostname" maps to a real IP address via
>=3B gethos= >tbyname. I accomplish it in practice by adding my hostname
>=3B to /et= >c/hosts.
>=3B
>=3B This is obviously not the right way to fix it= >...
>=3B
>=3B Mika
>=3B
>=3B Jay writes:
>=3B &= >gt=3B--_9e67232c-a064-417d-879e-227a77e310f9_
>=3B >=3BContent-Type:= > text/plain=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Enco= >ding: quoted-printable
>=3B >=3B
>=3B >=3B
>=3B >=3BHi= >. Unix network programming question..
>=3B >=3BAMD64_FREEBSD:
>= >=3B >=3B$DISPLAY is set to point back to Cygwin host.It works for PPC_LIN= >UX.
>=3B >=3B[jay at fbsdamd64a /cm3/bin]$ ./Juno
>=3B >=3B*****= >* runtime error:*** Exception "IPError.FatalError" not in RAISES li=3D
&= >gt=3B >=3Bst*** file "../src/common/IPError.m3"=3D2C line 27***
>=3B= > >=3BAbort trap: 6 (core dumped)[jay at fbsdamd64a /cm3/bin]$
>=3B >= >=3BIP.m3:
>=3B >=3B=3D20
>=3B >=3BPROCEDURE GetHostAddr(): Ad= >dress =3D3D VAR hname: ARRAY [0..255] OF CHAR=3D3B =3D
>=3B >=3B BEG= >IN LOCK mu DO IF Unix.gethostname(ADR(hname[0])=3D2C BYTESIZE(hna=3D
>= >=3B >=3Bme)) # 0 THEN IPError.Die ()=3D3B END=3D3B VAR h :=3D3D Unetdb.g= >=3D
>=3B >=3Bethostbyname(ADR(hname[0]))=3D3B BEGIN IF h =3D3D NIL T= >HEN IPError.Die()=3D
>=3B >=3B=3D3B END=3D3B RETURN GetAddress(h)=3D= >3B END=3D3B END=3D3B END GetHos=3D
>=3B >=3BtAddr=3D3B
>=3B >= >=3BPROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Address =3D3D VA= >R ua=3D
>=3B >=3B: Uin.struct_in_addr=3D3B BEGIN <=3B* ASSERT ent.= >h_length <=3B=3D3D BYTESIZE(Addr=3D
>=3B >=3Bess) *>=3B ua :=3D3= >D LOOPHOLE(ent.h_addr_list=3D2C UNTRACED =3D
>=3B >=3BREF UNTRACED R= >EF Uin.struct_in_addr)^^=3D3B RETURN LOOPHOLE(ua.s_addr=3D2C A=3D
>=3B= > >=3Bddress)=3D3B END GetAddress=3D3B
>=3B >=3B=3D20
>=3B >= >=3Bgethostbyname is failing.
>=3B >=3B=3D20
>=3B >=3BAnalogou= >s C code also fails:
>=3B >=3B=3D20
>=3B >=3B[jay at fbsdamd64a = >/cm3/bin]$ cat ~/5.c#include <=3Bassert.h>=3B#include <=3Bnetdb.h>= >=3B#i=3D
>=3B >=3Bnclude <=3Bstdio.h>=3B#include <=3Berrno.h&g= >t=3Btypedef struct hostent hostent_t=3D3B
>=3B >=3B=3D20
>=3B &= >gt=3Bint main(){ char hostname[200]=3D3B hostent_t* h=3D3B int i=3D3B
&g= >t=3B >=3B i =3D3D gethostname(hostname=3D2C 200)=3D3B assert(i =3D3D=3D3D= > 0)=3D3B printf("hostna=3D
>=3B >=3Bme: %s\n"=3D2C hostname)=3D3B h = >=3D3D gethostbyname(hostname)=3D3B herror("foo")=3D3B=3D
>=3B >=3B p= >rintf("%p %d %d\n"=3D2C h=3D2C errno=3D2C h_errno)=3D3B assert(h)=3D3B retu= >rn 0=3D3B}
>=3B >=3B=3D20
>=3B >=3Bherror says "unknown host"= >.
>=3B >=3BStack is:
>=3B >=3B at ../src/runtime/ex_frame/RTE= >xFrame.m3:58#13 0x0000000801a7f2b3 in RTH=3D
>=3B >=3Books__Raise (M= >3_AJWxb1_ex=3D3DError accessing memory address 0x8000ffffd278: =3D
>= >=3B >=3BBad address.) at ../src/runtime/common/RTHooks.m3:79#14 0x0000000= >80169c8=3D
>=3B >=3Bd3 in IPError__Die () at ../src/common/IPError.m= >3:27#15 0x0000000801698a3e =3D
>=3B >=3Bin IP__GetHostAddr (M3_BCxjP= >n__result=3D3DError accessing memory address 0x80=3D
>=3B >=3B00ffff= >d338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x00000008012133d0=3D
&g= >t=3B >=3B in XSharedMem__SameHost (M3_AQuuui_trsl=3D3DError accessing mem= >ory address 0=3D
>=3B >=3Bx8000ffffd4d8: Bad address.) at ../src/xvb= >t/XSharedMem.m3:96#17 0x000000=3D
>=3B >=3B0801212ab7 in XSharedMem_= >_InitXClient (M3_AQuuui_v=3D3DError accessing memory=3D
>=3B >=3B ad= >dress 0x8000ffffd648: Bad address.) at ../src/xvbt/XSharedMem.m3:29#1=3D>>=3B >=3B8 0x0000000801211819 in XExtensions__InitXClient (M3_AQuuui_x= >client=3D3DError=3D
>=3B >=3B accessing memory address 0x8000ffffd7f= >8: Bad address.) at ../src/xvbt/X=3D
>=3B >=3BExtensions.m3:14#19 0x= >00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst=3D
>=3B >=3B= >=3D3D0x1879b=3D2C M3_AQuuui_trsl=3D3D0x6) at ../src/xvbt/XClientF.m3:583---= >Typ=3D
>=3B >=3Be <=3Breturn>=3B to continue=3D2C or q <=3Bret= >urn>=3B to quit---(More stack frames follow=3D
>=3B >=3B...)(gdb)<= >BR>>=3B >=3B(* return TRUE if server and client are on same host *)PROC= >EDURE SameHost (=3D
>=3B >=3Btrsl: XClient.T): BOOLEAN =3D3D VAR dis= >play :=3D3D DisplayH=3D
>=3B >=3Bost(trsl)=3D3B displayAddr: IP.Addr= >ess=3D3B BEGIN IF display =3D3D NIL THE=3D
>=3B >=3BN RETURN TRUE=3D= >3B END=3D3B
>=3B >=3B TRY IF NOT IP.GetHostByName(display=3D2C displ= >ayAddr) THEN RETURN FA=3D
>=3B >=3BLSE=3D3B END=3D3B RETURN displayA= >ddr =3D3D IP.GetHostAddr()=3D3B EXCEPT =3D
>=3B >=3B| IP.Error =3D3D= >>=3B RETURN FALSE=3D3B END=3D3B END SameHost=3D3B
>=3B >=3B=3D20R>>=3B >=3BThoughts?
>=3B >=3B=3D20
>=3B >=3BPerhaps my n= >etwork isn't setup well=3D2C like I should add the local machine =3D
>= >=3B >=3Bto /etc/hosts.I think this can be made to fail gracefully though.= >It seems l=3D
>=3B >=3Bike it has nothing to do with AMD64_FREEBSD= >=3D2C but could have to do with Fr=3D
>=3B >=3BeeBSD.
>=3B >= >=3B=3D20
>=3B >=3BSeems like SocketPosix has nearly the exact same c= >ode but appearsmore forgi=3D
>=3B >=3Bving.. IOError instead of Fata= >l?
>=3B >=3B=3D20
>=3B >=3BSocketPosix.m3:
>=3B >=3B= >=3D20
>=3B >=3BPROCEDURE GetHostAddr (): Address RAISES {OSError.E} = >=3D3D VAR host : AR=3D
>=3B >=3BRAY [0..255] OF CHAR=3D3B info : Une= >tdb.struct_hostent_star=3D3B ua : U=3D
>=3B >=3Bin.struct_in_addr=3D= >3B BEGIN IF Unix.gethostname (ADR (host[0])=3D2C BYTESI=3D
>=3B >=3B= >ZE (host)) # 0 THEN IOError (Unexpected)=3D3B END=3D3B
>=3B >=3B inf= >o :=3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3B IF info =3D3D NIL TH=3D<= >BR>>=3B >=3BEN IOError (Unexpected)=3D3B END=3D3B <=3B* ASSERT info.h= >_length <=3B=3D3D BYTESIZE =3D
>=3B >=3B(Address) *>=3B
>= >=3B >=3B ua :=3D3D LOOPHOLE(info.h_addr_list=3D2C UNTRACED REF UNT=3D
= >>=3B >=3BRACED REF Uin.struct_in_addr)^^=3D3B RETURN LOOPHOLE (ua.s_add= >r=3D2C Address=3D
>=3B >=3B)=3D3B END GetHostAddr=3D3B
>=3B >= >=3B=3D20
>=3B >=3B=3D20
>=3B >=3BIt is again disappointing to= > see such code duplication.
>=3B >=3B=3D20
>=3B >=3B=3D20
= >>=3B >=3BI guess SameHost can duplicate the logic to predict the error = >state and ret=3D
>=3B >=3Burn false upon error?
>=3B >=3BDupl= >icating the logic for a third time. :(
>=3B >=3B=3D20
>=3B >= >=3B - Jay=3D
>=3B >=3B
>=3B >=3B--_9e67232c-a064-417d-879e-22= >7a77e310f9_
>=3B >=3BContent-Type: text/html=3B charset=3D"iso-8859-= >1"
>=3B >=3BContent-Transfer-Encoding: quoted-printable
>=3B &g= >t=3B
>=3B >=3B<=3Bhtml>=3B
>=3B >=3B<=3Bhead>=3B
&= >gt=3B >=3B<=3Bstyle>=3B
>=3B >=3B.hmmessage P
>=3B >=3B= >{
>=3B >=3Bmargin:0px=3D3B
>=3B >=3Bpadding:0px
>=3B >= >=3B}
>=3B >=3Bbody.hmmessage
>=3B >=3B{
>=3B >=3Bfont-= >size: 10pt=3D3B
>=3B >=3Bfont-family:Verdana
>=3B >=3B}
&g= >t=3B >=3B<=3B/style>=3B
>=3B >=3B<=3B/head>=3B
>=3B &= >gt=3B<=3Bbody class=3D3D'hmmessage'>=3B
>=3B >=3BHi. Unix networ= >k programming question..<=3BBR>=3B
>=3B >=3B<=3BBR>=3BAMD64_= >FREEBSD:<=3BBR>=3B
>=3B >=3B<=3BBR>=3B$DISPLAY is set to poi= >nt back to Cygwin host.<=3BBR>=3BIt works for PPC_LINUX=3D
>=3B &g= >t=3B.<=3BBR>=3B
>=3B >=3B<=3BBR>=3B[jay at fbsdamd64a /cm3/bin]= >$ ./Juno<=3BBR>=3B
>=3B >=3B<=3BBR>=3B***<=3BBR>=3B*** r= >untime error:<=3BBR>=3B***&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp= >=3D3B Exception "IPE=3D
>=3B >=3Brror.FatalError" not in RAISES list= ><=3BBR>=3B***&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B file "..= >=3D
>=3B >=3B/src/common/IPError.m3"=3D2C line 27<=3BBR>=3B***&l= >t=3BBR>=3B
>=3B >=3B<=3BBR>=3BAbort trap: 6 (core dumped)<= >=3BBR>=3B[jay at fbsdamd64a /cm3/bin]$<=3BBR>=3B
>=3B >=3B<=3BB= >R>=3BIP.m3:<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B<= >BR>>=3B >=3BPROCEDURE GetHostAddr(): Address =3D3D<=3BBR>=3B&=3B= >nbsp=3D3B VAR hname: ARRAY [0..255] =3D
>=3B OF CHAR=3D3B<=3BBR>= >=3B&=3Bnbsp=3D3B BEGIN<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&= >=3Bnbsp=3D3B LOCK mu DO<=3BBR>=3B&=3Bnbs=3D
>=3B >=3Bp=3D3B&a= >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B IF Unix.geth= >ostname(ADR(hname[0])=3D2C B=3D
>=3B >=3BYTESIZE(hname)) # 0 THEN<= >=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B= >&=3Bnbsp=3D3B&=3Bnbsp=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B IPErro= >r.Die ()=3D3B<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B= >&=3Bnbsp=3D3B&=3Bnbsp=3D3B E=3D
>=3B >=3BND=3D3B<=3BBR>=3B= >&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp= >=3D3B VAR h :=3D3D Unetdb.gethost=3D
>=3B >=3Bbyname(ADR(hname[0]))= >=3D3B BEGIN<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&a= >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3B=3D
>=3B >=3Bnbsp=3D3B&=3Bnb= >sp=3D3B IF h =3D3D NIL THEN IPError.Die()=3D3B END=3D3B<=3BBR>=3B&= >=3Bnbsp=3D3B&=3Bnbsp=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B&=3Bnbsp= >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B RETURN GetAddress(h)= >=3D3B<=3BBR>=3B&=3Bnbs=3D
>=3B >=3Bp=3D3B&=3Bnbsp=3D3B&= >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B END=3D3B<=3BBR>=3B&=3Bn= >bsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B END=3D
>=3B >=3B=3D3B<=3B= >BR>=3B&=3Bnbsp=3D3B END GetHostAddr=3D3B<=3BBR>=3B
>=3B >= >=3B<=3BBR>=3BPROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Ad= >dress =3D3D<=3BBR>=3B=3D
>=3B >=3B&=3Bnbsp=3D3B VAR ua: Uin.s= >truct_in_addr=3D3B<=3BBR>=3B&=3Bnbsp=3D3B BEGIN<=3BBR>=3B&=3B= >nbsp=3D3B&=3Bnbsp=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B &=3Blt=3D3= >B* ASSERT ent.h_length &=3Blt=3D3B=3D3D BYTESIZE(Address) *&=3Bgt=3D3= >B=3D
>=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bn= >bsp=3D3B ua :=3D3D LOOPHOLE(ent.h_addr_list=3D2C<=3BBR>=3B&=3Bnbsp= >=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&a= >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp= >=3D3B&=3Bnbsp=3D3B=3D
>=3B >=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&a= >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp= >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B UN=3D
>=3B >=3BTRACED REF UNTR= ACED REF Uin.struct_in_addr)^^=3D3B<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbs= >p=3D3B&=3Bnbsp=3D
>=3B >=3B=3D3B RETURN LOOPHOLE(ua.s_addr=3D2C A= >ddress)=3D3B<=3BBR>=3B&=3Bnbsp=3D3B END GetAddress=3D3B<=3B=3D
= >>=3B >=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>= >=3B >=3Bgethostbyname is failing.<=3BBR>=3B
>=3B >=3B<=3BBR&= >gt=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BAnalogous C code also f= >ails:<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>= >=3B >=3B<=3BBR>=3B[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c<=3BBR>=3B#= >include &=3Blt=3D3Bassert.h&=3Bgt=3D3B<=3BB=3D
>=3B >=3BR>= >=3B#include &=3Blt=3D3Bnetdb.h&=3Bgt=3D3B<=3BBR>=3B#include &= >=3Blt=3D3Bstdio.h&=3Bgt=3D3B<=3BBR>=3B#include =3D
>=3B >=3B&= >amp=3Blt=3D3Berrno.h&=3Bgt=3D3B<=3BBR>=3Btypedef struct hostent host= >ent_t=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
= >>=3B >=3Bint main()<=3BBR>=3B{<=3BBR>=3B&=3Bnbsp=3D3Bchar ho= >stname[200]=3D3B<=3BBR>=3B&=3Bnbsp=3D3Bhostent_t* h=3D3B=3D
>= >=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3Bint i=3D3B<=3BBR>=3B
>=3B = >>=3B&=3Bnbsp=3D3Bi =3D3D gethostname(hostname=3D2C 200)=3D3B<=3BBR&g= >t=3B&=3Bnbsp=3D3Bassert(i =3D3D=3D3D 0)=3D
>=3B >=3B=3D3B<=3BBR= >>=3B&=3Bnbsp=3D3Bprintf("hostname: %s\n"=3D2C hostname)=3D3B<=3BBR&g= >t=3B&=3Bnbsp=3D3Bh =3D3D get=3D
>=3B >=3Bhostbyname(hostname)=3D3= >B<=3BBR>=3B&=3Bnbsp=3D3Bherror("foo")=3D3B<=3BBR>=3B&=3Bnbsp= >=3D3Bprintf("%p %=3D
>=3B >=3Bd %d\n"=3D2C h=3D2C errno=3D2C h_errno= >)=3D3B<=3BBR>=3B&=3Bnbsp=3D3Bassert(h)=3D3B<=3BBR>=3B&=3Bnbsp= >=3D3Bret=3D
>=3B >=3Burn 0=3D3B<=3BBR>=3B}<=3BBR>=3B
>= >=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3Bherror says "unkno= >wn host".<=3BBR>=3B
>=3B >=3B<=3BBR>=3BStack is:<=3BBR>= >=3B
>=3B >=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B at ../= >src/runtime/ex_frame/RTExFrame.m3:58<=3BBR>=3B#13 =3D
>=3B >=3B0= >x0000000801a7f2b3 in RTHooks__Raise (M3_AJWxb1_ex=3D3DError accessing memor= >y=3D
>=3B >=3B ad<=3BBR>=3Bdress 0x8000ffffd278: Bad address.<= >=3BBR>=3B)<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B = >=3D
>=3B >=3Bat ../src/runtime/common/RTHooks.m3:79<=3BBR>=3B#14= > 0x000000080169c8d3 in IPError=3D
>=3B >=3B__Die () at ../src/common= >/IPError.m3:27<=3BBR>=3B#15 0x0000000801698a3e in IP__Ge=3D
>=3B &= >gt=3BtHostAddr (M3_BCxjPn__result=3D3DError accessing mem<=3BBR>=3Bory = >address 0x8000fff=3D
>=3B >=3Bfd338: Bad address.<=3BBR>=3B)<= >=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B at ../src/POSIX= >/IP.m3:=3D
>=3B >=3B82<=3BBR>=3B#16 0x00000008012133d0 in XShare= >dMem__SameHost (M3_AQuuui_trsl=3D3DErro=3D
>=3B >=3Br accessing m<= >=3BBR>=3Bemory address 0x8000ffffd4d8: Bad address.<=3BBR>=3B)<=3BB= >R>=3B&=3Bnbsp=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B= > at ../src/xvbt/XSharedMem.m3:96<=3BBR>=3B#17 0x0000000801212a=3D
&g= >t=3B >=3Bb7 in XSharedMem__InitXClient (M3_AQuuui_v=3D3DError accessing m= ><=3BBR>=3Bemory add=3D
>=3B >=3Bress 0x8000ffffd648: Bad address= >.<=3BBR>=3B)<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp= >=3D3B at ../sr=3D
>=3B >=3Bc/xvbt/XSharedMem.m3:29<=3BBR>=3B#18 = >0x0000000801211819 in XExtensions__InitXClie=3D
>=3B >=3Bnt (M3_AQuu= >ui_xclient=3D3DError acce<=3BBR>=3Bssing memory address 0x8000ffffd7f8:= > =3D
>=3B >=3BBad address.<=3BBR>=3B)<=3BBR>=3B&=3Bnbsp= >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B at ../src/xvbt/XExtensions.m3=3D
&= >gt=3B >=3B:14<=3BBR>=3B#19 0x00000008012467a4 in XClientF__Connect (M= >3_Bd56fi_inst=3D3D0x1879=3D
>=3B >=3Bb=3D2C<=3BBR>=3B&=3Bnbsp= >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B M3_AQuuui_trsl=3D3D0x6) at ../src/xvb= >t/XClie=3D
>=3B >=3BntF.m3:583<=3BBR>=3B---Type &=3Blt=3D3Bre= >turn&=3Bgt=3D3B to continue=3D2C or q &=3Blt=3D3Breturn&=3Bg=3D>>=3B >=3Bt=3D3B to quit---<=3BBR>=3B(More stack frames follow...)&= >lt=3BBR>=3B(gdb)<=3BBR>=3B
>=3B >=3B<=3BBR>=3B(* return TR= >UE if server and client are on same host *)<=3BBR>=3BPROCEDURE Sa=3D>>=3B >=3BmeHost (trsl: XClient.T): BOOLEAN =3D3D<=3BBR>=3B&=3Bn= >bsp=3D3B VAR<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bn=3D
&g= >t=3B >=3Bbsp=3D3B display&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B= >&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp= >=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&a= >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp= >=3D3B :=3D3D Di=3D
>=3B >=3BsplayHost(trsl)=3D3B<=3BBR>=3B&= >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B displayAddr: IP.Address=3D3B&l= >t=3BB=3D
>=3B >=3BR>=3B&=3Bnbsp=3D3B BEGIN<=3BBR>=3B&=3B= >nbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B IF display =3D3D NIL THEN RETURN= >=3D
>=3B >=3B TRUE=3D3B END=3D3B<=3BBR>=3B
>=3B >=3B&= >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B TRY<=3BBR>=3B&=3Bnbsp= >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B IF=3D= >
>=3B >=3B NOT IP.GetHostByName(display=3D2C displayAddr) THEN RETUR= >N FALSE=3D3B END=3D3B<=3BB=3D
>=3B >=3BR>=3B&=3Bnbsp=3D3B&= >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B RETURN display= >Addr =3D3D IP.GetHos=3D
>=3B >=3BtAddr()=3D3B<=3BBR>=3B&=3Bnb= >sp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B EXCEPT<=3BBR>=3B&=3Bnbsp=3D3= >B&=3Bnbsp=3D3B&=3Bnbsp=3D3B |=3D
>=3B >=3B IP.Error =3D3D&= >=3Bgt=3D3B RETURN FALSE=3D3B<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&= >amp=3Bnbsp=3D3B END=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bnbsp=3D3B = >END SameHost=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>= >=3B
>=3B >=3BThoughts?<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3= >B<=3BBR>=3B
>=3B >=3B<=3BBR>=3BPerhaps my network isn't setu= >p well=3D2C like I should add the local mach=3D
>=3B >=3Bine to /etc= >/hosts.<=3BBR>=3BI think this can be made to fail gracefully though.<= >=3BB=3D
>=3B >=3BR>=3BIt seems like it has nothing to do with AMD6= >4_FREEBSD=3D2C but could have t=3D
>=3B >=3Bo do with FreeBSD.<=3B= >BR>=3B
>=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B
&g= >t=3B >=3BSeems like SocketPosix has nearly the exact same code but appear= >s<=3BBR>=3Bmore f=3D
>=3B >=3Borgiving.. IOError instead of Fata= >l?<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B &= >gt=3B<=3BBR>=3BSocketPosix.m3:<=3BBR>=3B
>=3B >=3B&=3Bnbs= >p=3D3B<=3BBR>=3B
>=3B >=3B<=3BBR>=3BPROCEDURE GetHostAddr ()= >: Address<=3BBR>=3B&=3Bnbsp=3D3B RAISES {OSError.E} =3D3D<=3BBR=3D= >
>=3B >=3B>=3B&=3Bnbsp=3D3B VAR<=3BBR>=3B&=3Bnbsp=3D3B&a= >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B host : ARRAY [0..255] OF CHAR=3D3B<=3B=3D<= >BR>>=3B >=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B in= >fo : Unetdb.struct_hostent_star=3D3B<=3BBR>=3B&=3Bnbsp=3D
>=3B = >>=3B=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B ua&=3Bnbsp=3D3B&=3Bnbsp= >=3D3B : Uin.struct_in_addr=3D3B<=3BBR>=3B&=3Bnbsp=3D3B =3D
>=3B= > >=3BBEGIN<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B = >IF Unix.gethostname (ADR (host[0])=3D2C BYT=3D
>=3B >=3BESIZE (host)= >) # 0 THEN<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&am= >p=3Bnbsp=3D3B&=3Bnbsp=3D3B IOError =3D
>=3B >=3B(Unexpected)=3D3B= ><=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B END=3D3B<= >=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3= >B info :=3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3B<=3B=3D
>=3B = >>=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B IF info =3D3= >D NIL THEN IOError (Unexpected)=3D3B EN=3D
>=3B >=3BD=3D3B<=3BBR&g= >t=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B &=3Blt=3D3B* ASSERT= > info.h_length &=3Blt=3D3B=3D3D BYT=3D
>=3B >=3BESIZE (Address) *= >&=3Bgt=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B&=3Bnbsp=3D= >3B&=3Bnbsp=3D3B ua :=3D3D LOOPHOLE(info.h_addr_list=3D2C<=3BBR>=3B&a= >mp=3Bnbsp=3D3B&=3Bn=3D
>=3B >=3Bbsp=3D3B&=3Bnbsp=3D3B&=3Bnb= >sp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&= >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D
>=3B >=3B=3D3B&=3Bnbsp= >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&= >=3Bnbsp=3D3B&=3Bnbsp=3D3B UNTRACED REF UN=3D
>=3B >=3BTRACED REF = >Uin.struct_in_addr)^^=3D3B<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&am= >p=3Bnbsp=3D3B RETURN LOOP=3D
>=3B >=3BHOLE (ua.s_addr=3D2C Address)= >=3D3B<=3BBR>=3B&=3Bnbsp=3D3B END GetHostAddr=3D3B<=3BBR>=3B
&= >gt=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B= ><=3BBR>=3B
>=3B >=3BIt is again disappointing to see such code d= >uplication.<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BI guess&=3B= >nbsp=3D3BSameHost can duplicate the logic to predict the error state =3D>>=3B >=3Band return false&=3Bnbsp=3D3Bupon error?<=3BBR>=3B
= >>=3B >=3BDuplicating the logic for a third time. :(<=3BBR>=3B
&g= >t=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B<=3BBR>=3B&am= >p=3Bnbsp=3D3B- Jay<=3BBR>=3B<=3BBR>=3B<=3B/body>=3B
>=3B &= >gt=3B<=3B/html>=3B=3D
>=3B >=3B
>=3B >=3B--_9e67232c-a064= >-417d-879e-227a77e310f9_--

>= > >--_b00371fe-730b-4981-9051-a874361296d7_-- From jay.krell at cornell.edu Mon Jan 12 10:12:44 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 09:12:44 +0000 Subject: [M3devel] Juno (X) networking problem on AMD64_FREEBSD In-Reply-To: <200901120906.n0C96Uwn074046@camembert.async.caltech.edu> References: Your message of "Sun, 11 Jan 2009 22:02:18 GMT." <200901120906.n0C96Uwn074046@camembert.async.caltech.edu> Message-ID: PPC_LINUX not PPC_DARWIN. I think. And at one point AMD64_LINUX (same machine as AMD64_FREEBSD, multiboot).I think I tested I386_OPENBSD Juno too and it worked,I don't remember. Oh, but that was in a VM, so different networking setup. This is Trestle startup, seeing if there mightbe shared memory available between the X client and server. If $DISPLAY is set, to specify the server, it wants to comparethat against "current", the client.You know, if I set DISPLAY=:0.0 or localhost:0.0, don't penalize perf,but if it really is remote, then do penalize perf. /Something/ like that. I hardly read the code.. - Jay> To: jay.krell at cornell.edu> Date: Mon, 12 Jan 2009 01:06:30 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Juno (X) networking problem on AMD64_FREEBSD> > Jay,> > I think the problem here is actually in the caller. Why does a> caller need "GetHostAddr()"? It is probably doing this for the> purpose of calling listen() or some such thing. What the caller> probably *really* wants is INADDR_ANY, and not the IP address of> some arbitrarily chosen interface on the host.> > I'm guessing it works on the Mac because the Mac libraries do> something complicated when you ask for the host's name (i.e., they> somehow generate a hostname that always maps to the IP address of> an interface on the computer).> > Mika> > Jay writes:> >--_b00371fe-730b-4981-9051-a874361296d7_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >Do you know the right way?> >=20> >PPC_LINUX "just worked"=2C and I can check Solaris and Darwin.> >=20> >I don't want to edit /etc/hosts -- I use DHCP.> >Though DHCP has been bothering me -- only for some of my machines do names => >resolve=2C so I end using IP addresses=2C which change sometimes=2C and I l=> >oop over them running ssh to all of them and "see what I get"=2C not ideal.> >=20> > - Jay> To: jay.krell at cornell.edu> Date: Sun=2C 11 Jan 2009 08:02:18 -0800>=> > From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3d=> >evel] Juno (X) networking problem on AMD64_FREEBSD> > This is a screwy thin=> >g in Modula-3. A bug I would call it.> > I've noticed a lot of networking M=> >3 programs don't work right unless> the return value of Unix's "hostname" m=> >aps to a real IP address via> gethostbyname. I accomplish it in practice by=> > adding my hostname> to /etc/hosts.> > This is obviously not the right way => >to fix it... > > Mika> > Jay writes:> >--_9e67232c-a064-417d-879e-227a77e31=> >0f9_> >Content-Type: text/plain=3B charset=3D"iso-8859-1"> >Content-Transfe=> >r-Encoding: quoted-printable> >> >> >Hi. Unix network programming question.=> >.> >AMD64_FREEBSD:> >$DISPLAY is set to point back to Cygwin host.It works => >for PPC_LINUX.> >[jay at fbsdamd64a /cm3/bin]$ ./Juno> >****** runtime error:*=> >** Exception "IPError.FatalError" not in RAISES li=3D> >st*** file "../src/=> >common/IPError.m3"=3D2C line 27***> >Abort trap: 6 (core dumped)[jay at fbsdam=> >d64a /cm3/bin]$> >IP.m3:> >=3D20> >PROCEDURE GetHostAddr(): Address =3D3D V=> >AR hname: ARRAY [0..255] OF CHAR=3D3B =3D> > BEGIN LOCK mu DO IF Unix.getho=> >stname(ADR(hname[0])=3D2C BYTESIZE(hna=3D> >me)) # 0 THEN IPError.Die ()=3D=> >3B END=3D3B VAR h :=3D3D Unetdb.g=3D> >ethostbyname(ADR(hname[0]))=3D3B BEG=> >IN IF h =3D3D NIL THEN IPError.Die()=3D> >=3D3B END=3D3B RETURN GetAddress(=> >h)=3D3B END=3D3B END=3D3B END GetHos=3D> >tAddr=3D3B> >PROCEDURE GetAddress=> > (ent: Unetdb.struct_hostent_star): Address =3D3D VAR ua=3D> >: Uin.struct_=> >in_addr=3D3B BEGIN <* ASSERT ent.h_length <=3D3D BYTESIZE(Addr=3D> >ess) *>=> > ua :=3D3D LOOPHOLE(ent.h_addr_list=3D2C UNTRACED =3D> >REF UNTRACED REF Ui=> >n.struct_in_addr)^^=3D3B RETURN LOOPHOLE(ua.s_addr=3D2C A=3D> >ddress)=3D3B=> > END GetAddress=3D3B> >=3D20> >gethostbyname is failing.> >=3D20> >Analogou=> >s C code also fails:> >=3D20> >[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c#include=> > #include #i=3D> >nclude #include type=> >def struct hostent hostent_t=3D3B> >=3D20> >int main(){ char hostname[200]=> >=3D3B hostent_t* h=3D3B int i=3D3B> > i =3D3D gethostname(hostname=3D2C 200=> >)=3D3B assert(i =3D3D=3D3D 0)=3D3B printf("hostna=3D> >me: %s\n"=3D2C hostn=> >ame)=3D3B h =3D3D gethostbyname(hostname)=3D3B herror("foo")=3D3B=3D> > pri=> >ntf("%p %d %d\n"=3D2C h=3D2C errno=3D2C h_errno)=3D3B assert(h)=3D3B return=> > 0=3D3B}> >=3D20> >herror says "unknown host".> >Stack is:> > at ../src/run=> >time/ex_frame/RTExFrame.m3:58#13 0x0000000801a7f2b3 in RTH=3D> >ooks__Raise=> > (M3_AJWxb1_ex=3D3DError accessing memory address 0x8000ffffd278: =3D> >Bad=> > address.) at ../src/runtime/common/RTHooks.m3:79#14 0x000000080169c8=3D> >=> >d3 in IPError__Die () at ../src/common/IPError.m3:27#15 0x0000000801698a3e => >=3D> >in IP__GetHostAddr (M3_BCxjPn__result=3D3DError accessing memory addr=> >ess 0x80=3D> >00ffffd338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x00000=> >008012133d0=3D> > in XSharedMem__SameHost (M3_AQuuui_trsl=3D3DError accessi=> >ng memory address 0=3D> >x8000ffffd4d8: Bad address.) at ../src/xvbt/XShare=> >dMem.m3:96#17 0x000000=3D> >0801212ab7 in XSharedMem__InitXClient (M3_AQuuu=> >i_v=3D3DError accessing memory=3D> > address 0x8000ffffd648: Bad address.) => >at ../src/xvbt/XSharedMem.m3:29#1=3D> >8 0x0000000801211819 in XExtensions_=> >_InitXClient (M3_AQuuui_xclient=3D3DError=3D> > accessing memory address 0x=> >8000ffffd7f8: Bad address.) at ../src/xvbt/X=3D> >Extensions.m3:14#19 0x000=> >00008012467a4 in XClientF__Connect (M3_Bd56fi_inst=3D> >=3D3D0x1879b=3D2C M=> >3_AQuuui_trsl=3D3D0x6) at ../src/xvbt/XClientF.m3:583---Typ=3D> >e => > to continue=3D2C or q to quit---(More stack frames follow=3D> >..=> >.)(gdb)> >(* return TRUE if server and client are on same host *)PROCEDURE => >SameHost (=3D> >trsl: XClient.T): BOOLEAN =3D3D VAR display :=3D3D DisplayH=> >=3D> >ost(trsl)=3D3B displayAddr: IP.Address=3D3B BEGIN IF display =3D3D NI=> >L THE=3D> >N RETURN TRUE=3D3B END=3D3B> > TRY IF NOT IP.GetHostByName(displ=> >ay=3D2C displayAddr) THEN RETURN FA=3D> >LSE=3D3B END=3D3B RETURN displayAd=> >dr =3D3D IP.GetHostAddr()=3D3B EXCEPT =3D> >| IP.Error =3D3D> RETURN FALSE=> >=3D3B END=3D3B END SameHost=3D3B> >=3D20> >Thoughts?> >=3D20> >Perhaps my n=> >etwork isn't setup well=3D2C like I should add the local machine =3D> >to /=> >etc/hosts.I think this can be made to fail gracefully though.It seems l=3D>=> > >ike it has nothing to do with AMD64_FREEBSD=3D2C but could have to do wit=> >h Fr=3D> >eeBSD.> >=3D20> >Seems like SocketPosix has nearly the exact same=> > code but appearsmore forgi=3D> >ving.. IOError instead of Fatal?> >=3D20> => >>SocketPosix.m3:> >=3D20> >PROCEDURE GetHostAddr (): Address RAISES {OSErro=> >r.E} =3D3D VAR host : AR=3D> >RAY [0..255] OF CHAR=3D3B info : Unetdb.struc=> >t_hostent_star=3D3B ua : U=3D> >in.struct_in_addr=3D3B BEGIN IF Unix.gethos=> >tname (ADR (host[0])=3D2C BYTESI=3D> >ZE (host)) # 0 THEN IOError (Unexpect=> >ed)=3D3B END=3D3B> > info :=3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3B => >IF info =3D3D NIL TH=3D> >EN IOError (Unexpected)=3D3B END=3D3B <* ASSERT i=> >nfo.h_length <=3D3D BYTESIZE =3D> >(Address) *>> > ua :=3D3D LOOPHOLE(info.=> >h_addr_list=3D2C UNTRACED REF UNT=3D> >RACED REF Uin.struct_in_addr)^^=3D3B=> > RETURN LOOPHOLE (ua.s_addr=3D2C Address=3D> >)=3D3B END GetHostAddr=3D3B> => >>=3D20> >=3D20> >It is again disappointing to see such code duplication.> >=> >=3D20> >=3D20> >I guess SameHost can duplicate the logic to predict the err=> >or state and ret=3D> >urn false upon error?> >Duplicating the logic for a t=> >hird time. :(> >=3D20> > - Jay=3D> >> >--_9e67232c-a064-417d-879e-227a77e31=> >0f9_> >Content-Type: text/html=3B charset=3D"iso-8859-1"> >Content-Transfer=> >-Encoding: quoted-printable> >> >> >> >> >> > >mmessage'>> >Hi. Unix network programming question..
> >
AMD64_FREEBS=> >D:
> >
$DISPLAY is set to point back to Cygwin host.
It works for => >PPC_LINUX=3D> >.
> >
[jay at fbsdamd64a /cm3/bin]$ ./Juno
> >
***<=> >BR>*** runtime error:
*** =3D3B =3D3B =3D3B Exception "IPE=> >=3D> >rror.FatalError" not in RAISES list
*** =3D3B =3D3B => >=3D3B file "..=3D> >/src/common/IPError.m3"=3D2C line 27
***
> >
A=> >bort trap: 6 (core dumped)
[jay at fbsdamd64a /cm3/bin]$
> >
IP.m3: >R>> > =3D3B
> >PROCEDURE GetHostAddr(): Address =3D3D
 =3D3B => >VAR hname: ARRAY [0..255] =3D> OF CHAR=3D3B
 =3D3B BEGIN
 =3D=> >3B =3D3B =3D3B LOCK mu DO
&nbs=3D> >p=3D3B =3D3B =3D3B&n=> >bsp=3D3B =3D3B IF Unix.gethostname(ADR(hname[0])=3D2C B=3D> >YTESIZE(hn=> >ame)) # 0 THEN
 =3D3B =3D3B =3D3B =3D3B =3D3B => >=3D> >=3D3B =3D3B IPError.Die ()=3D3B
 =3D3B =3D3B =3D3B=> > =3D3B =3D3B E=3D> >ND=3D3B
 =3D3B =3D3B =3D3B => >=3D3B =3D3B VAR h :=3D3D Unetdb.gethost=3D> >byname(ADR(hname[0]))=3D3B=> > BEGIN
 =3D3B =3D3B =3D3B =3D3B =3D3B&=3D> >nbsp=3D3=> >B =3D3B IF h =3D3D NIL THEN IPError.Die()=3D3B END=3D3B
 =3D3B&n=> >bsp=3D> >=3D3B =3D3B =3D3B =3D3B =3D3B =3D3B RETURN Get=> >Address(h)=3D3B
&nbs=3D> >p=3D3B =3D3B =3D3B =3D3B =3D3B=> > END=3D3B
 =3D3B =3D3B =3D3B END=3D> >=3D3B
 =3D3B EN=> >D GetHostAddr=3D3B
> >
PROCEDURE GetAddress (ent: Unetdb.struct_hoste=> >nt_star): Address =3D3D
=3D> > =3D3B VAR ua: Uin.struct_in_addr=3D3B=> >
 =3D3B BEGIN
 =3D3B =3D> >=3D3B =3D3B <=3D3B* ASSE=> >RT ent.h_length <=3D3B=3D3D BYTESIZE(Address) *>=3D3B=3D> >
 =3D=> >3B =3D3B =3D3B ua :=3D3D LOOPHOLE(ent.h_addr_list=3D2C
 =3D>=> > >=3D3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D=> >3B =3D3B =3D3B=3D> > =3D3B =3D3B =3D3B =3D3B => >=3D3B =3D3B =3D3B =3D3B =3D3B UN=3D> >TRACED REF UNTRACED R=> >EF Uin.struct_in_addr)^^=3D3B
 =3D3B =3D3B =3D> >=3D3B RETUR=> >N LOOPHOLE(ua.s_addr=3D2C Address)=3D3B
 =3D3B END GetAddress=3D3B<=> >=3D> >BR>> > =3D3B
> >gethostbyname is failing.
> >
 =3D3B=> >
> >Analogous C code also fails:
> > =3D3B
> >
[jay at fbsdamd=> >64a /cm3/bin]$ cat ~/5.c
#include <=3D3Bassert.h>=3D3B >R>#inc=> >lude <=3D3Bnetdb.h>=3D3B
#include <=3D3Bstdio.h>=3D3B
#includ=> >e =3D> ><=3D3Berrno.h>=3D3B
typedef struct hostent hostent_t=3D3B >>> > =3D3B
> >int main()
{
 =3D3Bchar hostname[200]=3D3B >R> =3D3Bhostent_t* h=3D3B=3D> >
 =3D3Bint i=3D3B
> > =3D3=> >Bi =3D3D gethostname(hostname=3D2C 200)=3D3B
 =3D3Bassert(i =3D3D=3D=> >3D 0)=3D> >=3D3B
 =3D3Bprintf("hostname: %s\n"=3D2C hostname)=3D3B >R> =3D3Bh =3D3D get=3D> >hostbyname(hostname)=3D3B
 =3D3Bherror(=> >"foo")=3D3B
 =3D3Bprintf("%p %=3D> >d %d\n"=3D2C h=3D2C errno=3D2C h=> >_errno)=3D3B
 =3D3Bassert(h)=3D3B
 =3D3Bret=3D> >urn 0=3D3B >R>}
> > =3D3B
> >herror says "unknown host".
> >
Stack is:<=> >BR>> > =3D3B =3D3B =3D3B at ../src/runtime/ex_frame/RTExFrame.m=> >3:58
#13 =3D> >0x0000000801a7f2b3 in RTHooks__Raise (M3_AJWxb1_ex=3D3DEr=> >ror accessing memory=3D> > ad
dress 0x8000ffffd278: Bad address.
) >> =3D3B =3D3B =3D3B =3D> >at ../src/runtime/common/RTHooks.m3:7=> >9
#14 0x000000080169c8d3 in IPError=3D> >__Die () at ../src/common/IPErr=> >or.m3:27
#15 0x0000000801698a3e in IP__Ge=3D> >tHostAddr (M3_BCxjPn__res=> ult=3D3DError accessing mem
ory address 0x8000fff=3D> >fd338: Bad addres=> >s.
)
 =3D3B =3D3B =3D3B at ../src/POSIX/IP.m3:=3D> >82 >>#16 0x00000008012133d0 in XSharedMem__SameHost (M3_AQuuui_trsl=3D3DErro=3D=> >> >r accessing m
emory address 0x8000ffffd4d8: Bad address.
)
&nbs=> >p=3D> >=3D3B =3D3B =3D3B at ../src/xvbt/XSharedMem.m3:96
#17 0x0=> >000000801212a=3D> >b7 in XSharedMem__InitXClient (M3_AQuuui_v=3D3DError acc=> >essing m
emory add=3D> >ress 0x8000ffffd648: Bad address.
)
 => >=3D3B =3D3B =3D3B at ../sr=3D> >c/xvbt/XSharedMem.m3:29
#18 0x00=> >00000801211819 in XExtensions__InitXClie=3D> >nt (M3_AQuuui_xclient=3D3DErr=> >or acce
ssing memory address 0x8000ffffd7f8: =3D> >Bad address.
)
=> > =3D3B =3D3B =3D3B at ../src/xvbt/XExtensions.m3=3D> >:14
#1=> >9 0x00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst=3D3D0x1879=3D> >b=> >=3D2C
 =3D3B =3D3B =3D3B M3_AQuuui_trsl=3D3D0x6) at ../src/x=> >vbt/XClie=3D> >ntF.m3:583
---Type <=3D3Breturn>=3D3B to continue=3D2=> >C or q <=3D3Breturn&g=3D> >t=3D3B to quit---
(More stack frames follow=> >...)
(gdb)
> >
(* return TRUE if server and client are on same hos=> >t *)
PROCEDURE Sa=3D> >meHost (trsl: XClient.T): BOOLEAN =3D3D
 => >=3D3B VAR
 =3D3B =3D3B&n=3D> >bsp=3D3B display =3D3B =3D=> >3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D> >=3D3B => >=3D3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D3B=> :=3D3D Di=3D> >splayHost(trsl)=3D3B
 =3D3B =3D3B =3D3B disp=> >layAddr: IP.Address=3D3B >R> =3D3B BEGIN
 =3D3B =3D3B&=> >nbsp=3D3B IF display =3D3D NIL THEN RETURN=3D> > TRUE=3D3B END=3D3B
> >&=> >nbsp=3D3B =3D3B =3D3B TRY
 =3D3B =3D3B =3D3B =3D=> >3B =3D3B IF=3D> > NOT IP.GetHostByName(display=3D2C displayAddr) THEN R=> >ETURN FALSE=3D3B END=3D3B >R> =3D3B =3D3B =3D3B =3D3B=> > =3D3B RETURN displayAddr =3D3D IP.GetHos=3D> >tAddr()=3D3B
 =3D=> >3B =3D3B =3D3B EXCEPT
 =3D3B =3D3B =3D3B |=3D> > IP.=> >Error =3D3D>=3D3B RETURN FALSE=3D3B
 =3D3B =3D3B =3D3B END=> >=3D3B
&=3D> >nbsp=3D3B END SameHost=3D3B
> > =3D3B
> >Thoughts=> >?
> > =3D3B
> >
Perhaps my network isn't setup well=3D2C like => >I should add the local mach=3D> >ine to /etc/hosts.
I think this can be => >made to fail gracefully though. >R>It seems like it has nothing to do=> > with AMD64_FREEBSD=3D2C but could have t=3D> >o do with FreeBSD.
> > >> =3D3B
> >Seems like SocketPosix has nearly the exact same code but=> > appears
more f=3D> >orgiving.. IOError instead of Fatal?
> > =3D=> >3B
> >
SocketPosix.m3:
> > =3D3B
> >
PROCEDURE GetHostAd=> >dr (): Address
 =3D3B RAISES {OSError.E} =3D3D >> =3D3B V=> >AR
 =3D3B =3D3B =3D3B host : ARRAY [0..255] OF CHAR=3D3B<=3D=> >> >BR> =3D3B =3D3B =3D3B info : Unetdb.struct_hostent_star=3D3B=> >
 =3D> >=3D3B =3D3B =3D3B ua =3D3B =3D3B : Uin.struc=> >t_in_addr=3D3B
 =3D3B =3D> >BEGIN
 =3D3B =3D3B =3D3B => >IF Unix.gethostname (ADR (host[0])=3D2C BYT=3D> >ESIZE (host)) # 0 THEN
=> > =3D3B =3D3B =3D3B =3D3B =3D3B IOError =3D> >(Unexpecte=> >d)=3D3B
 =3D3B =3D3B =3D3B END=3D3B
> > =3D3B =3D=> >3B =3D3B info :=3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3B<=3D> >BR=> >> =3D3B =3D3B =3D3B IF info =3D3D NIL THEN IOError (Unexpected)=> >=3D3B EN=3D> >D=3D3B
 =3D3B =3D3B =3D3B <=3D3B* ASSERT inf=> >o.h_length <=3D3B=3D3D BYT=3D> >ESIZE (Address) *>=3D3B
> > =3D3=> >B =3D3B =3D3B ua :=3D3D LOOPHOLE(info.h_addr_list=3D2C
 =3D3=> >B&n=3D> >bsp=3D3B =3D3B =3D3B =3D3B =3D3B =3D3B =3D=> >3B =3D3B =3D3B =3D> >=3D3B =3D3B =3D3B =3D3B => >=3D3B =3D3B =3D3B =3D3B UNTRACED REF UN=3D> >TRACED REF Uin.str=> >uct_in_addr)^^=3D3B
 =3D3B =3D3B =3D3B RETURN LOOP=3D> >HOLE=> > (ua.s_addr=3D2C Address)=3D3B
 =3D3B END GetHostAddr=3D3B
> >&nb=> >sp=3D3B
> > =3D3B
> >It is again disappointing to see such code d=> >uplication.
> > =3D3B
> > =3D3B
> >I guess =3D3BSameHo=> >st can duplicate the logic to predict the error state =3D> >and return fals=> >e =3D3Bupon error?
> >Duplicating the logic for a third time. :(
=> >> > =3D3B
> >
 =3D3B- Jay

> >=3D> >> >--=> >_9e67232c-a064-417d-879e-227a77e310f9_--=> >> >--_b00371fe-730b-4981-9051-a874361296d7_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >> >Do you know the right way?
> > =3B
> >PPC_LINUX "just worked"=2C and I can check Solaris and Darwin.
> > =3B
> >I don't want to edit /etc/hosts -- I use DHCP.
> >Though DHCP has been bothering me -- only for some of my machines do names => >resolve=2C so I end using IP addresses=2C which change sometimes=2C and I l=> >oop over them running ssh to all of them and "see what I get"=2C not ideal.=> >
> > =3B
> > =3B- Jay


>=3B To: jay.krell at cornell.edu
>=3B Date: S=> >un=2C 11 Jan 2009 08:02:18 -0800
>=3B From: mika at async.caltech.edu
=> >>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] Juno (X) => >networking problem on AMD64_FREEBSD
>=3B
>=3B This is a screwy t=> >hing in Modula-3. A bug I would call it.
>=3B
>=3B I've noticed => >a lot of networking M3 programs don't work right unless
>=3B the retur=> >n value of Unix's "hostname" maps to a real IP address via
>=3B gethos=> >tbyname. I accomplish it in practice by adding my hostname
>=3B to /et=> >c/hosts.
>=3B
>=3B This is obviously not the right way to fix it=> >...
>=3B
>=3B Mika
>=3B
>=3B Jay writes:
>=3B &=> >gt=3B--_9e67232c-a064-417d-879e-227a77e310f9_
>=3B >=3BContent-Type:=> > text/plain=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Enco=> >ding: quoted-printable
>=3B >=3B
>=3B >=3B
>=3B >=3BHi=> >. Unix network programming question..
>=3B >=3BAMD64_FREEBSD:
>=> >=3B >=3B$DISPLAY is set to point back to Cygwin host.It works for PPC_LIN=> >UX.
>=3B >=3B[jay at fbsdamd64a /cm3/bin]$ ./Juno
>=3B >=3B*****=> >* runtime error:*** Exception "IPError.FatalError" not in RAISES li=3D
&=> >gt=3B >=3Bst*** file "../src/common/IPError.m3"=3D2C line 27***
>=3B=> > >=3BAbort trap: 6 (core dumped)[jay at fbsdamd64a /cm3/bin]$
>=3B >=> >=3BIP.m3:
>=3B >=3B=3D20
>=3B >=3BPROCEDURE GetHostAddr(): Ad=> >dress =3D3D VAR hname: ARRAY [0..255] OF CHAR=3D3B =3D
>=3B >=3B BEG=> >IN LOCK mu DO IF Unix.gethostname(ADR(hname[0])=3D2C BYTESIZE(hna=3D
>=> >=3B >=3Bme)) # 0 THEN IPError.Die ()=3D3B END=3D3B VAR h :=3D3D Unetdb.g=> >=3D
>=3B >=3Bethostbyname(ADR(hname[0]))=3D3B BEGIN IF h =3D3D NIL T=> >HEN IPError.Die()=3D
>=3B >=3B=3D3B END=3D3B RETURN GetAddress(h)=3D=> >3B END=3D3B END=3D3B END GetHos=3D
>=3B >=3BtAddr=3D3B
>=3B >=> >=3BPROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Address =3D3D VA=> >R ua=3D
>=3B >=3B: Uin.struct_in_addr=3D3B BEGIN <=3B* ASSERT ent.=> >h_length <=3B=3D3D BYTESIZE(Addr=3D
>=3B >=3Bess) *>=3B ua :=3D3=> >D LOOPHOLE(ent.h_addr_list=3D2C UNTRACED =3D
>=3B >=3BREF UNTRACED R=> >EF Uin.struct_in_addr)^^=3D3B RETURN LOOPHOLE(ua.s_addr=3D2C A=3D
>=3B=> > >=3Bddress)=3D3B END GetAddress=3D3B
>=3B >=3B=3D20
>=3B >=> >=3Bgethostbyname is failing.
>=3B >=3B=3D20
>=3B >=3BAnalogou=> >s C code also fails:
>=3B >=3B=3D20
>=3B >=3B[jay at fbsdamd64a => >/cm3/bin]$ cat ~/5.c#include <=3Bassert.h>=3B#include <=3Bnetdb.h>=> >=3B#i=3D
>=3B >=3Bnclude <=3Bstdio.h>=3B#include <=3Berrno.h&g=> >t=3Btypedef struct hostent hostent_t=3D3B
>=3B >=3B=3D20
>=3B &=> >gt=3Bint main(){ char hostname[200]=3D3B hostent_t* h=3D3B int i=3D3B
&g=> >t=3B >=3B i =3D3D gethostname(hostname=3D2C 200)=3D3B assert(i =3D3D=3D3D=> > 0)=3D3B printf("hostna=3D
>=3B >=3Bme: %s\n"=3D2C hostname)=3D3B h => >=3D3D gethostbyname(hostname)=3D3B herror("foo")=3D3B=3D
>=3B >=3B p=> >rintf("%p %d %d\n"=3D2C h=3D2C errno=3D2C h_errno)=3D3B assert(h)=3D3B retu=> >rn 0=3D3B}
>=3B >=3B=3D20
>=3B >=3Bherror says "unknown host"=> >.
>=3B >=3BStack is:
>=3B >=3B at ../src/runtime/ex_frame/RTE=> >xFrame.m3:58#13 0x0000000801a7f2b3 in RTH=3D
>=3B >=3Books__Raise (M=> >3_AJWxb1_ex=3D3DError accessing memory address 0x8000ffffd278: =3D
>=> >=3B >=3BBad address.) at ../src/runtime/common/RTHooks.m3:79#14 0x0000000=> >80169c8=3D
>=3B >=3Bd3 in IPError__Die () at ../src/common/IPError.m=> >3:27#15 0x0000000801698a3e =3D
>=3B >=3Bin IP__GetHostAddr (M3_BCxjP=> >n__result=3D3DError accessing memory address 0x80=3D
>=3B >=3B00ffff=> >d338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x00000008012133d0=3D
&g=> >t=3B >=3B in XSharedMem__SameHost (M3_AQuuui_trsl=3D3DError accessing mem=> >ory address 0=3D
>=3B >=3Bx8000ffffd4d8: Bad address.) at ../src/xvb=> >t/XSharedMem.m3:96#17 0x000000=3D
>=3B >=3B0801212ab7 in XSharedMem_=> >_InitXClient (M3_AQuuui_v=3D3DError accessing memory=3D
>=3B >=3B ad=> >dress 0x8000ffffd648: Bad address.) at ../src/xvbt/XSharedMem.m3:29#1=3D >>>=3B >=3B8 0x0000000801211819 in XExtensions__InitXClient (M3_AQuuui_x=> >client=3D3DError=3D
>=3B >=3B accessing memory address 0x8000ffffd7f=> >8: Bad address.) at ../src/xvbt/X=3D
>=3B >=3BExtensions.m3:14#19 0x=> >00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst=3D
>=3B >=3B=> >=3D3D0x1879b=3D2C M3_AQuuui_trsl=3D3D0x6) at ../src/xvbt/XClientF.m3:583---=> >Typ=3D
>=3B >=3Be <=3Breturn>=3B to continue=3D2C or q <=3Bret=> >urn>=3B to quit---(More stack frames follow=3D
>=3B >=3B...)(gdb)<=> >BR>>=3B >=3B(* return TRUE if server and client are on same host *)PROC=> >EDURE SameHost (=3D
>=3B >=3Btrsl: XClient.T): BOOLEAN =3D3D VAR dis=> >play :=3D3D DisplayH=3D
>=3B >=3Bost(trsl)=3D3B displayAddr: IP.Addr=> >ess=3D3B BEGIN IF display =3D3D NIL THE=3D
>=3B >=3BN RETURN TRUE=3D=> >3B END=3D3B
>=3B >=3B TRY IF NOT IP.GetHostByName(display=3D2C displ=> >ayAddr) THEN RETURN FA=3D
>=3B >=3BLSE=3D3B END=3D3B RETURN displayA=> >ddr =3D3D IP.GetHostAddr()=3D3B EXCEPT =3D
>=3B >=3B| IP.Error =3D3D=> >>=3B RETURN FALSE=3D3B END=3D3B END SameHost=3D3B
>=3B >=3B=3D20 >R>>=3B >=3BThoughts?
>=3B >=3B=3D20
>=3B >=3BPerhaps my n=> >etwork isn't setup well=3D2C like I should add the local machine =3D
>=> >=3B >=3Bto /etc/hosts.I think this can be made to fail gracefully though.=> >It seems l=3D
>=3B >=3Bike it has nothing to do with AMD64_FREEBSD=> >=3D2C but could have to do with Fr=3D
>=3B >=3BeeBSD.
>=3B >=> >=3B=3D20
>=3B >=3BSeems like SocketPosix has nearly the exact same c=> >ode but appearsmore forgi=3D
>=3B >=3Bving.. IOError instead of Fata=> >l?
>=3B >=3B=3D20
>=3B >=3BSocketPosix.m3:
>=3B >=3B=> >=3D20
>=3B >=3BPROCEDURE GetHostAddr (): Address RAISES {OSError.E} => >=3D3D VAR host : AR=3D
>=3B >=3BRAY [0..255] OF CHAR=3D3B info : Une=> >tdb.struct_hostent_star=3D3B ua : U=3D
>=3B >=3Bin.struct_in_addr=3D=> >3B BEGIN IF Unix.gethostname (ADR (host[0])=3D2C BYTESI=3D
>=3B >=3B=> >ZE (host)) # 0 THEN IOError (Unexpected)=3D3B END=3D3B
>=3B >=3B inf=> >o :=3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3B IF info =3D3D NIL TH=3D<=> >BR>>=3B >=3BEN IOError (Unexpected)=3D3B END=3D3B <=3B* ASSERT info.h=> >_length <=3B=3D3D BYTESIZE =3D
>=3B >=3B(Address) *>=3B
>=> >=3B >=3B ua :=3D3D LOOPHOLE(info.h_addr_list=3D2C UNTRACED REF UNT=3D
=> >>=3B >=3BRACED REF Uin.struct_in_addr)^^=3D3B RETURN LOOPHOLE (ua.s_add=> >r=3D2C Address=3D
>=3B >=3B)=3D3B END GetHostAddr=3D3B
>=3B >=> >=3B=3D20
>=3B >=3B=3D20
>=3B >=3BIt is again disappointing to=> > see such code duplication.
>=3B >=3B=3D20
>=3B >=3B=3D20
=> >>=3B >=3BI guess SameHost can duplicate the logic to predict the error => >state and ret=3D
>=3B >=3Burn false upon error?
>=3B >=3BDupl=> >icating the logic for a third time. :(
>=3B >=3B=3D20
>=3B >=> >=3B - Jay=3D
>=3B >=3B
>=3B >=3B--_9e67232c-a064-417d-879e-22=> >7a77e310f9_
>=3B >=3BContent-Type: text/html=3B charset=3D"iso-8859-=> >1"
>=3B >=3BContent-Transfer-Encoding: quoted-printable
>=3B &g=> >t=3B
>=3B >=3B<=3Bhtml>=3B
>=3B >=3B<=3Bhead>=3B
&=> >gt=3B >=3B<=3Bstyle>=3B
>=3B >=3B.hmmessage P
>=3B >=3B=> >{
>=3B >=3Bmargin:0px=3D3B
>=3B >=3Bpadding:0px
>=3B >=> >=3B}
>=3B >=3Bbody.hmmessage
>=3B >=3B{
>=3B >=3Bfont-=> >size: 10pt=3D3B
>=3B >=3Bfont-family:Verdana
>=3B >=3B}
&g=> >t=3B >=3B<=3B/style>=3B
>=3B >=3B<=3B/head>=3B
>=3B &=> >gt=3B<=3Bbody class=3D3D'hmmessage'>=3B
>=3B >=3BHi. Unix networ=> >k programming question..<=3BBR>=3B
>=3B >=3B<=3BBR>=3BAMD64_=> >FREEBSD:<=3BBR>=3B
>=3B >=3B<=3BBR>=3B$DISPLAY is set to poi=> >nt back to Cygwin host.<=3BBR>=3BIt works for PPC_LINUX=3D
>=3B &g=> >t=3B.<=3BBR>=3B
>=3B >=3B<=3BBR>=3B[jay at fbsdamd64a /cm3/bin]=> >$ ./Juno<=3BBR>=3B
>=3B >=3B<=3BBR>=3B***<=3BBR>=3B*** r=> >untime error:<=3BBR>=3B***&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=> >=3D3B Exception "IPE=3D
>=3B >=3Brror.FatalError" not in RAISES list=> ><=3BBR>=3B***&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B file "..=> >=3D
>=3B >=3B/src/common/IPError.m3"=3D2C line 27<=3BBR>=3B***&l=> >t=3BBR>=3B
>=3B >=3B<=3BBR>=3BAbort trap: 6 (core dumped)<=> >=3BBR>=3B[jay at fbsdamd64a /cm3/bin]$<=3BBR>=3B
>=3B >=3B<=3BB=> >R>=3BIP.m3:<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B<=> >BR>>=3B >=3BPROCEDURE GetHostAddr(): Address =3D3D<=3BBR>=3B&=3B=> >nbsp=3D3B VAR hname: ARRAY [0..255] =3D
>=3B OF CHAR=3D3B<=3BBR>=> >=3B&=3Bnbsp=3D3B BEGIN<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=> >=3Bnbsp=3D3B LOCK mu DO<=3BBR>=3B&=3Bnbs=3D
>=3B >=3Bp=3D3B&a=> >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B IF Unix.geth=> >ostname(ADR(hname[0])=3D2C B=3D
>=3B >=3BYTESIZE(hname)) # 0 THEN<=> >=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B=> >&=3Bnbsp=3D3B&=3Bnbsp=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B IPErro=> >r.Die ()=3D3B<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B=> >&=3Bnbsp=3D3B&=3Bnbsp=3D3B E=3D
>=3B >=3BND=3D3B<=3BBR>=3B=> >&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=> >=3D3B VAR h :=3D3D Unetdb.gethost=3D
>=3B >=3Bbyname(ADR(hname[0]))=> >=3D3B BEGIN<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&a=> >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3B=3D
>=3B >=3Bnbsp=3D3B&=3Bnb=> >sp=3D3B IF h =3D3D NIL THEN IPError.Die()=3D3B END=3D3B<=3BBR>=3B&=> >=3Bnbsp=3D3B&=3Bnbsp=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B&=3Bnbsp=> >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B RETURN GetAddress(h)=> >=3D3B<=3BBR>=3B&=3Bnbs=3D
>=3B >=3Bp=3D3B&=3Bnbsp=3D3B&=> >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B END=3D3B<=3BBR>=3B&=3Bn=> >bsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B END=3D
>=3B >=3B=3D3B<=3B=> >BR>=3B&=3Bnbsp=3D3B END GetHostAddr=3D3B<=3BBR>=3B
>=3B >=> >=3B<=3BBR>=3BPROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Ad=> >dress =3D3D<=3BBR>=3B=3D
>=3B >=3B&=3Bnbsp=3D3B VAR ua: Uin.s=> >truct_in_addr=3D3B<=3BBR>=3B&=3Bnbsp=3D3B BEGIN<=3BBR>=3B&=3B=> >nbsp=3D3B&=3Bnbsp=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B &=3Blt=3D3=> >B* ASSERT ent.h_length &=3Blt=3D3B=3D3D BYTESIZE(Address) *&=3Bgt=3D3=> >B=3D
>=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bn=> >bsp=3D3B ua :=3D3D LOOPHOLE(ent.h_addr_list=3D2C<=3BBR>=3B&=3Bnbsp=> >=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&a=> >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=> >=3D3B&=3Bnbsp=3D3B=3D
>=3B >=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&a=> >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=> >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B UN=3D
>=3B >=3BTRACED REF UNTR=> ACED REF Uin.struct_in_addr)^^=3D3B<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbs=> >p=3D3B&=3Bnbsp=3D
>=3B >=3B=3D3B RETURN LOOPHOLE(ua.s_addr=3D2C A=> >ddress)=3D3B<=3BBR>=3B&=3Bnbsp=3D3B END GetAddress=3D3B<=3B=3D
=> >>=3B >=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=> >=3B >=3Bgethostbyname is failing.<=3BBR>=3B
>=3B >=3B<=3BBR&=> >gt=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BAnalogous C code also f=> >ails:<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=> >=3B >=3B<=3BBR>=3B[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c<=3BBR>=3B#=> >include &=3Blt=3D3Bassert.h&=3Bgt=3D3B<=3BB=3D
>=3B >=3BR>=> >=3B#include &=3Blt=3D3Bnetdb.h&=3Bgt=3D3B<=3BBR>=3B#include &=> >=3Blt=3D3Bstdio.h&=3Bgt=3D3B<=3BBR>=3B#include =3D
>=3B >=3B&=> >amp=3Blt=3D3Berrno.h&=3Bgt=3D3B<=3BBR>=3Btypedef struct hostent host=> >ent_t=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
=> >>=3B >=3Bint main()<=3BBR>=3B{<=3BBR>=3B&=3Bnbsp=3D3Bchar ho=> >stname[200]=3D3B<=3BBR>=3B&=3Bnbsp=3D3Bhostent_t* h=3D3B=3D
>=> >=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3Bint i=3D3B<=3BBR>=3B
>=3B => >>=3B&=3Bnbsp=3D3Bi =3D3D gethostname(hostname=3D2C 200)=3D3B<=3BBR&g=> >t=3B&=3Bnbsp=3D3Bassert(i =3D3D=3D3D 0)=3D
>=3B >=3B=3D3B<=3BBR=> >>=3B&=3Bnbsp=3D3Bprintf("hostname: %s\n"=3D2C hostname)=3D3B<=3BBR&g=> >t=3B&=3Bnbsp=3D3Bh =3D3D get=3D
>=3B >=3Bhostbyname(hostname)=3D3=> >B<=3BBR>=3B&=3Bnbsp=3D3Bherror("foo")=3D3B<=3BBR>=3B&=3Bnbsp=> >=3D3Bprintf("%p %=3D
>=3B >=3Bd %d\n"=3D2C h=3D2C errno=3D2C h_errno=> >)=3D3B<=3BBR>=3B&=3Bnbsp=3D3Bassert(h)=3D3B<=3BBR>=3B&=3Bnbsp=> >=3D3Bret=3D
>=3B >=3Burn 0=3D3B<=3BBR>=3B}<=3BBR>=3B
>=> >=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3Bherror says "unkno=> >wn host".<=3BBR>=3B
>=3B >=3B<=3BBR>=3BStack is:<=3BBR>=> >=3B
>=3B >=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B at ../=> >src/runtime/ex_frame/RTExFrame.m3:58<=3BBR>=3B#13 =3D
>=3B >=3B0=> >x0000000801a7f2b3 in RTHooks__Raise (M3_AJWxb1_ex=3D3DError accessing memor=> >y=3D
>=3B >=3B ad<=3BBR>=3Bdress 0x8000ffffd278: Bad address.<=> >=3BBR>=3B)<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B => >=3D
>=3B >=3Bat ../src/runtime/common/RTHooks.m3:79<=3BBR>=3B#14=> > 0x000000080169c8d3 in IPError=3D
>=3B >=3B__Die () at ../src/common=> >/IPError.m3:27<=3BBR>=3B#15 0x0000000801698a3e in IP__Ge=3D
>=3B &=> >gt=3BtHostAddr (M3_BCxjPn__result=3D3DError accessing mem<=3BBR>=3Bory => >address 0x8000fff=3D
>=3B >=3Bfd338: Bad address.<=3BBR>=3B)<=> >=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B at ../src/POSIX=> >/IP.m3:=3D
>=3B >=3B82<=3BBR>=3B#16 0x00000008012133d0 in XShare=> >dMem__SameHost (M3_AQuuui_trsl=3D3DErro=3D
>=3B >=3Br accessing m<=> >=3BBR>=3Bemory address 0x8000ffffd4d8: Bad address.<=3BBR>=3B)<=3BB=> >R>=3B&=3Bnbsp=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B=> > at ../src/xvbt/XSharedMem.m3:96<=3BBR>=3B#17 0x0000000801212a=3D
&g=> >t=3B >=3Bb7 in XSharedMem__InitXClient (M3_AQuuui_v=3D3DError accessing m=> ><=3BBR>=3Bemory add=3D
>=3B >=3Bress 0x8000ffffd648: Bad address=> >.<=3BBR>=3B)<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=> >=3D3B at ../sr=3D
>=3B >=3Bc/xvbt/XSharedMem.m3:29<=3BBR>=3B#18 => >0x0000000801211819 in XExtensions__InitXClie=3D
>=3B >=3Bnt (M3_AQuu=> >ui_xclient=3D3DError acce<=3BBR>=3Bssing memory address 0x8000ffffd7f8:=> > =3D
>=3B >=3BBad address.<=3BBR>=3B)<=3BBR>=3B&=3Bnbsp=> >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B at ../src/xvbt/XExtensions.m3=3D
&=> >gt=3B >=3B:14<=3BBR>=3B#19 0x00000008012467a4 in XClientF__Connect (M=> >3_Bd56fi_inst=3D3D0x1879=3D
>=3B >=3Bb=3D2C<=3BBR>=3B&=3Bnbsp=> >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B M3_AQuuui_trsl=3D3D0x6) at ../src/xvb=> >t/XClie=3D
>=3B >=3BntF.m3:583<=3BBR>=3B---Type &=3Blt=3D3Bre=> >turn&=3Bgt=3D3B to continue=3D2C or q &=3Blt=3D3Breturn&=3Bg=3D >>>=3B >=3Bt=3D3B to quit---<=3BBR>=3B(More stack frames follow...)&=> >lt=3BBR>=3B(gdb)<=3BBR>=3B
>=3B >=3B<=3BBR>=3B(* return TR=> >UE if server and client are on same host *)<=3BBR>=3BPROCEDURE Sa=3D >>>=3B >=3BmeHost (trsl: XClient.T): BOOLEAN =3D3D<=3BBR>=3B&=3Bn=> >bsp=3D3B VAR<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bn=3D
&g=> >t=3B >=3Bbsp=3D3B display&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B=> >&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=> >=3D
>=3B >=3B=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&a=> >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=> >=3D3B :=3D3D Di=3D
>=3B >=3BsplayHost(trsl)=3D3B<=3BBR>=3B&=> >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B displayAddr: IP.Address=3D3B&l=> >t=3BB=3D
>=3B >=3BR>=3B&=3Bnbsp=3D3B BEGIN<=3BBR>=3B&=3B=> >nbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B IF display =3D3D NIL THEN RETURN=> >=3D
>=3B >=3B TRUE=3D3B END=3D3B<=3BBR>=3B
>=3B >=3B&=> >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B TRY<=3BBR>=3B&=3Bnbsp=> >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B IF=3D=> >
>=3B >=3B NOT IP.GetHostByName(display=3D2C displayAddr) THEN RETUR=> >N FALSE=3D3B END=3D3B<=3BB=3D
>=3B >=3BR>=3B&=3Bnbsp=3D3B&=> >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B RETURN display=> >Addr =3D3D IP.GetHos=3D
>=3B >=3BtAddr()=3D3B<=3BBR>=3B&=3Bnb=> >sp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B EXCEPT<=3BBR>=3B&=3Bnbsp=3D3=> >B&=3Bnbsp=3D3B&=3Bnbsp=3D3B |=3D
>=3B >=3B IP.Error =3D3D&=> >=3Bgt=3D3B RETURN FALSE=3D3B<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=> >amp=3Bnbsp=3D3B END=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bnbsp=3D3B => >END SameHost=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=> >=3B
>=3B >=3BThoughts?<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3=> >B<=3BBR>=3B
>=3B >=3B<=3BBR>=3BPerhaps my network isn't setu=> >p well=3D2C like I should add the local mach=3D
>=3B >=3Bine to /etc=> >/hosts.<=3BBR>=3BI think this can be made to fail gracefully though.<=> >=3BB=3D
>=3B >=3BR>=3BIt seems like it has nothing to do with AMD6=> >4_FREEBSD=3D2C but could have t=3D
>=3B >=3Bo do with FreeBSD.<=3B=> >BR>=3B
>=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B
&g=> >t=3B >=3BSeems like SocketPosix has nearly the exact same code but appear=> >s<=3BBR>=3Bmore f=3D
>=3B >=3Borgiving.. IOError instead of Fata=> >l?<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B &=> >gt=3B<=3BBR>=3BSocketPosix.m3:<=3BBR>=3B
>=3B >=3B&=3Bnbs=> >p=3D3B<=3BBR>=3B
>=3B >=3B<=3BBR>=3BPROCEDURE GetHostAddr ()=> >: Address<=3BBR>=3B&=3Bnbsp=3D3B RAISES {OSError.E} =3D3D<=3BBR=3D=> >
>=3B >=3B>=3B&=3Bnbsp=3D3B VAR<=3BBR>=3B&=3Bnbsp=3D3B&a=> >mp=3Bnbsp=3D3B&=3Bnbsp=3D3B host : ARRAY [0..255] OF CHAR=3D3B<=3B=3D<=> >BR>>=3B >=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B in=> >fo : Unetdb.struct_hostent_star=3D3B<=3BBR>=3B&=3Bnbsp=3D
>=3B => >>=3B=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B ua&=3Bnbsp=3D3B&=3Bnbsp=> >=3D3B : Uin.struct_in_addr=3D3B<=3BBR>=3B&=3Bnbsp=3D3B =3D
>=3B=> > >=3BBEGIN<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B => >IF Unix.gethostname (ADR (host[0])=3D2C BYT=3D
>=3B >=3BESIZE (host)=> >) # 0 THEN<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&am=> >p=3Bnbsp=3D3B&=3Bnbsp=3D3B IOError =3D
>=3B >=3B(Unexpected)=3D3B=> ><=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B END=3D3B<=> >=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3=> >B info :=3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3B<=3B=3D
>=3B => >>=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B IF info =3D3=> >D NIL THEN IOError (Unexpected)=3D3B EN=3D
>=3B >=3BD=3D3B<=3BBR&g=> >t=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B &=3Blt=3D3B* ASSERT=> > info.h_length &=3Blt=3D3B=3D3D BYT=3D
>=3B >=3BESIZE (Address) *=> >&=3Bgt=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B&=3Bnbsp=3D=> >3B&=3Bnbsp=3D3B ua :=3D3D LOOPHOLE(info.h_addr_list=3D2C<=3BBR>=3B&a=> >mp=3Bnbsp=3D3B&=3Bn=3D
>=3B >=3Bbsp=3D3B&=3Bnbsp=3D3B&=3Bnb=> >sp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=> >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D
>=3B >=3B=3D3B&=3Bnbsp=> >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=> >=3Bnbsp=3D3B&=3Bnbsp=3D3B UNTRACED REF UN=3D
>=3B >=3BTRACED REF => >Uin.struct_in_addr)^^=3D3B<=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&am=> >p=3Bnbsp=3D3B RETURN LOOP=3D
>=3B >=3BHOLE (ua.s_addr=3D2C Address)=> >=3D3B<=3BBR>=3B&=3Bnbsp=3D3B END GetHostAddr=3D3B<=3BBR>=3B
&=> >gt=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B=> ><=3BBR>=3B
>=3B >=3BIt is again disappointing to see such code d=> >uplication.<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B >>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BI guess&=3B=> >nbsp=3D3BSameHost can duplicate the logic to predict the error state =3D >>>=3B >=3Band return false&=3Bnbsp=3D3Bupon error?<=3BBR>=3B
=> >>=3B >=3BDuplicating the logic for a third time. :(<=3BBR>=3B
&g=> >t=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B<=3BBR>=3B&am=> >p=3Bnbsp=3D3B- Jay<=3BBR>=3B<=3BBR>=3B<=3B/body>=3B
>=3B &=> >gt=3B<=3B/html>=3B=3D
>=3B >=3B
>=3B >=3B--_9e67232c-a064=> >-417d-879e-227a77e310f9_--

> >=> >> >--_b00371fe-730b-4981-9051-a874361296d7_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 12 10:31:13 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jan 2009 20:31:13 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20090112092033.2748010D5FD1@birch.elegosoft.com> References: <20090112092033.2748010D5FD1@birch.elegosoft.com> Message-ID: Jay, I have to call it quits on this tonight. As you can see, I've reverted the clients of SchedulerPosix.WaitProcess to do the re- packing based on the original definitions in Uexec. We need to do a more wholesale check of the clients of Process.Wait and System.Wait to see who 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. I think we can make this much cleaner if we can get rid of the re-packing. I am still concerned that there is needless splitting of the threads files. Perhaps ThreadPWait.m3 and ThreadPScheduler.m3 can be merged. I still don't like either of those names, but we should avoid SchedulerPosix.m3 since ThreadPosix.m3 also exports SchedulerPosix. It would really be much nicer if you could get CygWin to run using PTHREAD instead of the weird WIN32 hybrid. I'm hoping I can get back to more productive pursuits tomorrow... today has been pretty much destroyed as a result of these commits... The productive things are improving concurrency in the garbage collector -- I'd like to be able to do collection in parallel... ;-) On 12 Jan 2009, at 10:20, Antony Hosking wrote: > 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 mika at async.caltech.edu Mon Jan 12 10:34:24 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 12 Jan 2009 01:34:24 -0800 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: Your message of "Mon, 12 Jan 2009 08:47:17 GMT." Message-ID: <200901120934.n0C9YOs8074851@camembert.async.caltech.edu> You present it as a true tragic Dilemma. But isn't there a Third Way---to wit, can't you "Ask the Computer" to do the work for you? Generate the code somehow... Parsing the C headers is an obvious way but there may be others that are simpler, such as writing a Modula-3 program to generate the cloned M3 headers, sorry, interfaces. If I had to do this I would use my Scheme interpreter that's coded in Modula-3 to write a Scheme program to generate the headers. This program could pull whatever tricks are deemed necessary and suitable, down to the point of generating and compiling and running C programs as necessary (or parsing C code, or reading tea leaves). But the end result would be a set of interfaces written in "Pure Modula-3". The process of running the header generator would also have very few dependencies on anything outside the M3 distribution. Mika Jay writes: >--_6117a048-9185-4c03-badb-ef8f93402268_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >This is what you "have to" chose between. >Header cloning or C code (and C headers). >=20 >CONST or VAR (or functions?) >=20 >I'm going to likely make the Uerror change tonight. >You can still veto it (er=2C vote against it :) ) >=20 >Possibly some convuluted C (enum/#undef)=2C or splitting the Modula-3 >at boundaries that weren't previously believed "natural". >(See how SetupHandlers is ~two lines in Modula-3 and the rest in C=3B >this is partly out of ignorance. I don't know how to write those >two lines in C=3B and laziness=2C I didn't look into how). >=20 >=20 >=20 >Remember I'm still staying away from mainstream platforms=2C >so the value isn't what it might appear to be=2C but it is "stage setting"= >=2C >and the show might go on. :) >=20 >=20 >Also=2C the dilemna does get more difficult now=2C with the little C header= > cloning that remains. >=20 >For example=2C look at Upthreads.i3. >Mainly=2C look at function prototypes. >Constants and types are "known problems". >Prototypes are gray. They actually tend to be portable. >=20 >For example: >=20 >TYPE pid_t =3D INTEGER=3B ><*EXTERNAL "m3_getpid*> PROCEDURE getpid():pid_t=3B >=20 >or leave it alone? >getpid is probably the worst example. >It is so very portable declared in Modula-3. >But still=2C imagine pid_t might be 16bits or 32 or 64. >Writing a wrapper is more portable -- as long as the pid isn't stuff into s= >ome record that the system defines. >=20 >=20 >Again=2C Upthreads.i3. >Would you like to see it reduced=2C or left alone? >Only deal with the types and initializers=2C or also the prototypes? >You know=2C I could write a little portable layer=2C where all the types ar= >e pointers=2C always null initialized. >It would buy /some/ portability=2C and cost some. >=20 >=20 >Do you like the sem_t change? Partly? Not at all? >There is one sem_t in the system. So I moved it to be in C code. >Or=2C as I had it before=2C declared as the max size/align of all the platf= >orms -- getting that right is the same work as getting it right "the old wa= >y"=2C except if you make a mistake=2C odds are still good of it being ok. >=20 >=20 >Should the line be drawn at generating the remaining headers=2C rather than= > eliminating them? >Uerror.i3 is easily generated. Good enough? >=20 >Upthread.i3's types can be generated generally as records with opaque array= >s with the right size and alignment. >=20 >Other stuff can be generated or at least checked. >e.g. to check that getpid is declared correctly=2C you can assign it to a f= >unction pointer and see if that compiles. >=20 >Perf on Uerror arguably doesn't matter. >Is it only error handling code?Or do sockets often go down "error" paths=2C= > because they are slow and you are waiting for more data? >=20 >Anyway=2C point is=2C I agree for sure this is valuable=2C but I might be h= >itting the "tail" of the approach and should switch=2C I'm not sure. I keep= > saying that though=2C and then press further. >=20 >=20 > - Jay > > > >From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon=2C 12 Jan 200= >9 19:24:50 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a= > type's existance but not enough to instantiate it? > > >Point taken. We live in a C universe and so need to interact. I do think = >your work with the headers is useful=2C and I want it to continue. Especia= >lly in simplifying ports. > > >On 12 Jan 2009=2C at 19:18=2C Jay wrote: > >I don't think a development system without C headers is interesting.. Is it= > really? The transform I apply at times is wherever there is interaction wi= >th C code that is described by system-dependent headers=2C or perhaps even = >fairly system-independent headers outside the Modula-3 tree=2C either write= > wrapper functions for the functionality in the headers (e.g. stat=2C waitp= >id)=2C which can be done in a system-independent way=2C or move the Modula-= >3<->C transition higher=2C which is also usually system-independent=2C e.g.= > ThreadPThreadC_SetupHandlers. It is either that or clone the headers=2C wh= >ich seems like the worse evil. There is always going to be a Modula-3<->C t= >ransition=2C it is just a matter of where it occurs. - Jay > >CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.e= >duSubject: Re: [M3devel] declaring a type's existance but not enough to ins= >tantiate it?Date: Mon=2C 12 Jan 2009 12:32:15 +1100 > > >Jay=2C I really think you are bending over backwards too far just to be abl= >e to shoe-horn things into C. I *like* having the transpar of C header fil= >es expressed in Modula-3=2C *particularly* for system calls=2C where you mi= >ght even be trying to build on a system that does not have the C header fil= >es installed=2C even though the libraries exist and can be linked to. Fund= >amentally=2C I think anytime the Modula-3 code is made less transparent you= > should think hard about what you are doing. The same with the change of c= >onstants to variables. > >I am getting very nervous that the changes you are making are destroying th= >e clarity of the Modula-3 run-time code. > >In this particular case=2C you are wanting to use a Modula-3 parameter pass= >ing mechanism on something that is not declared in Modula-3. Seems kind of= > dubious to me. Also=2C I really don't like the idea of accessing external= > variables in C. > >-- Tony > >On 12 Jan 2009=2C at 11:55=2C Jay wrote: > >I considered ADDRESS.However I think it still doesn't satisfy. I want to be= > able to do this: TYPE Foo_t =3D something=3B<* EXTERNAL *> VAR Foo1=2C Foo= >2:Foo_t=3B<* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t)= >=3B (* Modula-3=2C not external *)PROCEDURE x()=3DBEGIN UseFoo(Foo1)=3B U= >seFoo(Foo2)=3BEND x=3B AND I want any use of:VAR Foo3:Foo3_t=3B (* Modula-3= >=2C not external *)to error. This is sem_t and sigset_t in particular. Poss= >ibly renaming is the thing.They used to be declared in Modula-3=2C system-d= >ependently=2C butI moved them to portable C. I could remove the types entir= >ely and change UseFoo to take an address=2Cand declare mask and ackSem to b= >e integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END=3B That would sat= >isfy but I thought it might be nicer to still provide the namedtypes to ref= >er to the external variables. - Jay > >From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon=2C 12 Jan 200= >9 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a= > type's existance but not enough to instantiate it?What's wrong with using = >ADDRESS for references to opaque values? If sigset_t is never instantiated= > in Modula-3=2C then why do you need it declared there? > > > >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=2C at 01:44=2C Jay wrote: > >Is there a way in Modula-3 to declare that a type exists=2C and there are <= >*external*> instances of it=2C without "fully" declaring it=2C so that no M= >odula-3 can instantiate it? I have done this for sigset_t and sem_t=2C but = >they could erroneously be instantiated by Modula-3 and I'd like to remove t= >hat ability to mess up so easily. (* This type is not declared correctly. I= >t is only instantiated in C code. *) sigset_t =3D RECORD END=3B(* This typ= >e is not declared correctly. It is only instantiated in C code. *) sem_t = >=3D RECORD END=3BIn C I believe you can do this=2C like: typedef struct fo= >o foo_t=3B extern foo_t foo=3B void UseFoo(foo_t*)=3B foo_t* GetFoo= >(void)=3B Thanks=2C - Jay= > >--_6117a048-9185-4c03-badb-ef8f93402268_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >This is what you "have to" chose between.
>Header cloning or C code (and C headers).
> =3B
>CONST or VAR (or functions?)
> =3B
>I'm going to likely make the Uerror change tonight.
>You can still veto it (er=2C vote against it :) )
> =3B
>Possibly some convuluted C (enum/#undef)=2C or splitting the Modula-3
>at boundaries that weren't previously believed "natural".
>(See how SetupHandlers is ~two lines in Modula-3 and the rest in C=3B
>this is partly out of ignorance. I don't know how to write those
>two lines in C=3B and laziness=2C I didn't look into how).
> =3B
> =3B
> =3B
>Remember I'm still staying away from mainstream platforms=2C
>so the value isn't what it might appear to be=2C but it is "stage setting"= >=2C
>and the show might go on. :)
> =3B
> =3B
>Also=2C the dilemna does get more difficult now=2C with the little C header= > cloning that remains.
> =3B
>For example=2C look at Upthreads.i3.
>Mainly=2C look at function prototypes.
>Constants and types are "known problems".
>Prototypes are gray. They actually tend to be portable.
> =3B
>For example:
> =3B
>TYPE pid_t =3D INTEGER=3B
><=3B*EXTERNAL "m3_getpid*>=3B PROCEDURE getpid():pid_t=3B
> =3B
>or leave it alone?
>getpid is probably the worst example.
>It is so very portable declared in Modula-3.
>But still=2C imagine pid_t might be 16bits or 32 or 64.
>Writing a wrapper is more portable -- as long as the pid isn't stuff into s= >ome record that the system defines.
> =3B
> =3B
>Again=2C Upthreads.i3.
>Would you like to see it reduced=2C or left alone?
>Only deal with the types and initializers=2C or also the prototypes?
>You know=2C I could write a little portable layer=2C where all the types ar= >e pointers=2C always null initialized.
>It would buy /some/ portability=2C and cost some.
> =3B
> =3B
>Do you like the sem_t change? Partly? Not at all?
>There is one sem_t in the system. So I moved it to be in C code.
>Or=2C as I had it before=2C declared as the max size/align of all the platf= >orms -- getting that right is the same work as getting it right "the old wa= >y"=2C except if you make a mistake=2C odds are still good of it being ok.R> > =3B
> =3B
>Should the line be drawn at generating the remaining headers=2C rather than= > eliminating them?
>Uerror.i3 is easily generated. Good enough?
> =3B
>Upthread.i3's types can be generated generally as records with opaque array= >s with the right size and alignment.
> =3B
>Other stuff can be generated or at least checked.
>e.g. to check that getpid is declared correctly=2C you can assign it to a f= >unction pointer and see if that compiles.
> =3B
>Perf on Uerror arguably doesn't matter.
>Is it only error handling code?
Or do sockets often go down "error" path= >s=2C because they are slow and you are waiting for more data?
> =3B
>Anyway=2C point is=2C I agree for sure this is valuable=2C but I might be h= >itting the "tail" of the approach and should switch=2C I'm not sure. I keep= > saying that though=2C and then press further.
> =3B
> =3B
> =3B- Jay

> >

>From: hosking at cs.purdue.edu
To: jay.krell at cornell.edu
Date: Mon=2C 12= > Jan 2009 19:24:50 +1100
CC: m3devel at elegosoft.com
Subject: Re: [M3de= >vel] declaring a type's existance but not enough to instantiate it?

= >
>
12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-IND= >ENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPS= >E: separate"> >
e=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B C= >OLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-S= >PACING: normal=3B BORDER-COLLAPSE: separate">pan style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: n= >one=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B = >LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate">-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRAN= >SFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: no= >rmal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate">EC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B T= >EXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-S= >PACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate">class=3DEC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvet= >ica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B= > WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate= >">x Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT= >: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: = >separate">ONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEX= >T-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-CO= >LLAPSE: separate">0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0= >)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B B= >ORDER-COLLAPSE: separate"> >
Point taken.  =3BWe live in a C universe and so need to interact. = > =3BI do think your work with the headers is useful=2C and I want it to= > continue.  =3BEspecially in simplifying ports.
>

V>
>
>
On 12 Jan 2009=2C at 19:18=2C Jay wrote:

erchange-newline> >
FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B T= >EXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-= >COLLAPSE: separate"> >
>I don't think a development system without C headers is interesting.. Is i= >t really?
 =3B
The transform I apply at times is wherever there i= >s interaction with C code that is described by system-dependent headers=2C = >or perhaps even fairly system-independent headers outside the Modula-3 tree= >=2C either write wrapper functions for the functionality in the headers (e.= >g. stat=2C waitpid)=2C which =3Bcan be done in a system-independent way= >=2C =3Bor move the Modula-3<=3B->=3BC transition higher=2C which is= > also usually system-independent=2C e.g. ThreadPThreadC_SetupHandlers.
&= >nbsp=3B
It is either that or clone the headers=2C which seems like the w= >orse evil.
 =3B
There is always going to be a Modula-3<=3B->= >=3BC transition=2C it is just a matter of where it occurs.
 =3B
&= >nbsp=3B- Jay

>
>
CC: =3Blto:m3devel at elegosoft.com">m3devel at elegosoft.com
From:EC_Apple-converted-space> =3B.edu">hosking at cs.purdue.edu
To:e> =3Bjay.krell at cornell= >.edu
Subject: Re: [M3devel] declaring a type's existance but not eno= >ugh to instantiate it?
Date: Mon=2C 12 Jan 2009 12:32:15 +1100

R>
T: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-= >INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLL= >APSE: separate"> >
tyle=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none= >=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LET= >TER-SPACING: normal=3B BORDER-COLLAPSE: separate">-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRAN= >SFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: no= >rmal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate">EC_EC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica= >=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WH= >ITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate"><= >SPAN class=3DEC_EC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12p= >x Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT= >: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: = >separate">=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)= >=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BO= >RDER-COLLAPSE: separate">-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb= >(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: n= >ormal=3B BORDER-COLLAPSE: separate">yle=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B= > COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER= >-SPACING: normal=3B BORDER-COLLAPSE: separate">yle-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFO= >RM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: norma= >l=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate"> >
Jay=2C I really think you are bending over backwards too far just to b= >e able to shoe-horn things into C.  =3BI *like* having the transpar of = >C header files expressed in Modula-3=2C *particularly* for system calls=2C = >where you might even be trying to build on a system that does not have the = >C header files installed=2C even though the libraries exist and can be link= >ed to.  =3BFundamentally=2C I think anytime the Modula-3 code is made l= >ess transparent you should think hard about what you are doing.  =3BThe= > same with the change of constants to variables.
>

>
I am getting very nervous that the changes you are making are destroyi= >ng the clarity of the Modula-3 run-time code.
>

>
In this particular case=2C you are wanting to use a Modula-3 parameter= > passing mechanism on something that is not declared in Modula-3.  =3BS= >eems kind of dubious to me.  =3BAlso=2C I really don't like the idea of= > accessing external variables in C.
>

>
-- Tony
<= >/DIV>

>
>
On 12 Jan 2009=2C at 11:55=2C Jay wrote:

interchange-newline> >
=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)= >=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BO= >RDER-COLLAPSE: separate"> >
na">I considered ADDRESS.
However I think it still doesn't satisfy.
&= >nbsp=3B
I want to be able to do this:
 =3B
TYPE =3BFoo_t = >=3D something=3B
<=3B* EXTERNAL *>=3B VAR Foo1=2C Foo2:Foo_t=3B
&= >lt=3B* EXTERNAL *>=3B PROCEDURE =3BUseFoo(READONLY (* or VAR *) foo:F= >oo_t)=3B
 =3B
(* Modula-3=2C not external *)
PROCEDURE x()=3D<= >BR>BEGIN
 =3B UseFoo(Foo1)=3B
 =3B UseFoo(Foo2)=3B
END x= >=3B
 =3B
AND I want any use of:
VAR Foo3:Foo3_t=3B (* Modula-3= >=2C not external *)

to error. This is sem_t and sigset_t in particul= >ar.
 =3B
Possibly renaming is the thing.
They used to be decla= >red in Modula-3=2C system-dependently=2C but
I moved them to portable C.= >
 =3B
I could remove the types entirely and change UseFoo to take= > an address=2C
and declare mask and ackSem to be integers or I guess.><=3B*EXTERNAL>=3B VAR ackSem =3B: RECORD END=3B
 =3B
Tha= >t would satisfy but I thought it might be nicer to still provide the named<= >BR>types to refer to the external variables.
 =3B
 =3B- JayR>
>
>
From: =3B=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu
To:ss=3DEC_EC_Apple-converted-space> =3B@cornell.edu">jay.krell at cornell.edu
Date: Mon=2C 12 Jan 2009 11:13:0= >0 +1100
CC: =3Bref=3D"mailto:m3devel at elegosoft.com">m3devel at elegosoft.com
Subject: = >Re: [M3devel] declaring a type's existance but not enough to instantiate it= >?

What's wrong with using ADDRESS for references to opaque values? &= >nbsp=3BIf sigset_t is never instantiated in Modula-3=2C then why do you nee= >d it declared there?
>

>
FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TE= >XT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-C= >OLLAPSE: separate"> >
n style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: non= >e=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LE= >TTER-SPACING: normal=3B BORDER-COLLAPSE: separate">pple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-= >TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE= >: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate">s=3DEC_EC_EC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helv= >etica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px= >=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separ= >ate">FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TE= >XT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-C= >OLLAPSE: separate">ACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0= >=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: nor= >mal=3B BORDER-COLLAPSE: separate">tyle=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none= >=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LET= >TER-SPACING: normal=3B BORDER-COLLAPSE: separate">ple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-T= >RANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE:= > normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate">=3DEC_EC_EC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helve= >tica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px= >=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separ= >ate"> >
EC_EC_EC_Apple-style-span face=3D"Gill Sans">tyle-span style=3D"COLOR: rgb(0=2C0=2C255)=3B FONT-FAMILY: 'Gill Sans'">AN class=3DEC_EC_EC_Apple-style-span style=3D"COLOR: rgb(0=2C0=2C255)=3B FO= >NT-FAMILY: 'Gill Sans'">Antony Hoskingss=3DEC_EC_EC_Apple-style-span face=3D"Gill Sans">ple-style-span style=3D"FONT-FAMILY: 'Gill Sans'">ple-style-span style=3D"FONT-FAMILY: 'Gill Sans'">-converted-space> =3B|= > =3B=3D"FONT-FAMILY: 'Gill Sans'">=3D"FONT-FAMILY: 'Gill Sans'">Associate Professor=3DEC_EC_EC_Apple-style-span style=3D"FONT-FAMILY: 'Gill Sans'">=3DEC_EC_EC_Apple-style-span style=3D"FONT-FAMILY: 'Gill Sans'"> =3B| C= >omputer Science | Purdue University
>
ass=3DEC_EC_EC_Apple-style-span style=3D"FONT-FAMILY: GillSans-Light">305 N= >. University Street | West Lafayette | IN 47907 | USA
>
00ff>5)=3B FONT-FAMILY: 'Gill Sans'">le=3D"COLOR: rgb(0=2C0=2C255)=3B FONT-FAMILY: 'Gill Sans'">OfficePAN>PAN class=3DEC_EC_EC_Apple-style-span style=3D"FONT-FAMILY: GillSans-Light"= >>ht"> =3B+1 765 494 6001 |&nbs= >p=3Be=3D"Gill Sans" color=3D#0000ff>le=3D"COLOR: rgb(0=2C0=2C255)=3B FONT-FAMILY: 'Gill Sans'">_EC_EC_Apple-style-span style=3D"COLOR: rgb(0=2C0=2C255)=3B FONT-FAMILY: 'G= >ill Sans'">Mobilean face=3DGillSans-Light>ONT-FAMILY: GillSans-Light">=3D"FONT-FAMILY: GillSans-Light">= > =3B+1 765 427 5484
>

s=3DEC_EC_EC_khtml-block-placeholder>
AN>
AN>

>
>
On 12 Jan 2009=2C at 01:44=2C Jay wrote:

le-interchange-newline> >
0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0= >)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B B= >ORDER-COLLAPSE: separate"> >
rdana">Is there a way in Modula-3 to declare that =3Ba type exists=2C a= >nd there are <=3B*external*>=3B instances of it=2C without "fully" decl= >aring it=2C so that no Modula-3 can instantiate it?
 =3B
I have d= >one this for sigset_t and sem_t=2C but they could erroneously be instantiat= >ed by Modula-3 and I'd like to remove that ability to mess up so easily.> =3B
(* This type is not declared correctly. It is only instantiate= >d in C code. *)
 =3B sigset_t =3D RECORD END=3B

(* This type = >is not declared correctly. It is only instantiated in C code. *)
 = >=3B sem_t =3D RECORD END=3B

In C I believe you can do this=2C like:<= >BR> =3B =3Btypedef struct foo foo_t=3B =3BC_Apple-converted-space> =3B
 =3B =3Bextern foo_t foo= >=3B =3B =3B
= > =3B
 =3Bvoid UseFoo(foo_t*)=3Berted-space> =3B
 =3B foo_t* GetFoo(void)=3B=3DEC_EC_EC_Apple-converted-space> =3B
 =3B
Thanks=2C<= >BR> =3B- Jay




<= >/DIV>
= >

V>
>= > >--_6117a048-9185-4c03-badb-ef8f93402268_-- From mika at async.caltech.edu Mon Jan 12 10:37:42 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 12 Jan 2009 01:37:42 -0800 Subject: [M3devel] Juno (X) networking problem on AMD64_FREEBSD In-Reply-To: Your message of "Mon, 12 Jan 2009 09:12:44 GMT." Message-ID: <200901120937.n0C9bgR5074988@camembert.async.caltech.edu> netobjd has similar problems. Hmm, yes, in both cases it is somehow related to listening on a port. In your X case it also sounds wrong. It should just check hname[0] against the DISPLAY env var. It doesn't need GetHostAddress. Mika Jay writes: >--_b0c10337-0e1c-414e-aae5-e611dcd4be8a_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >PPC_LINUX not PPC_DARWIN. >I think. >And at one point AMD64_LINUX (same machine as AMD64_FREEBSD=2C multiboot).I= > think I tested I386_OPENBSD Juno too and it worked=2CI don't remember. Oh= >=2C but that was in a VM=2C so different networking setup. >This is Trestle startup=2C seeing if there mightbe shared memory available = >between the X client and server. >If $DISPLAY is set=2C to specify the server=2C it wants to comparethat agai= >nst "current"=2C the client.You know=2C if I set DISPLAY=3D:0.0 or localhos= >t:0.0=2C don't penalize perf=2Cbut if it really is remote=2C then do penali= >ze perf. >/Something/ like that. >I hardly read the code.. > - Jay> To: jay.krell at cornell.edu> Date: Mon=2C 12 Jan 2009 01:06:30 -0800>= > From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3d= >evel] Juno (X) networking problem on AMD64_FREEBSD> > Jay=2C> > I think the= > problem here is actually in the caller. Why does a> caller need "GetHostAd= >dr()"? It is probably doing this for the> purpose of calling listen() or so= >me such thing. What the caller> probably *really* wants is INADDR_ANY=2C an= >d not the IP address of> some arbitrarily chosen interface on the host.> > = >I'm guessing it works on the Mac because the Mac libraries do> something co= >mplicated when you ask for the host's name (i.e.=2C they> somehow generate = >a hostname that always maps to the IP address of> an interface on the compu= >ter).> > Mika> > Jay writes:> >--_b00371fe-730b-4981-9051-a874361296d7_> >C= >ontent-Type: text/plain=3B charset=3D"iso-8859-1"> >Content-Transfer-Encodi= >ng: quoted-printable> >> >> >Do you know the right way?> >=3D20> >PPC_LINUX= > "just worked"=3D2C and I can check Solaris and Darwin.> >=3D20> >I don't w= >ant to edit /etc/hosts -- I use DHCP.> >Though DHCP has been bothering me -= >- only for some of my machines do names =3D> >resolve=3D2C so I end using I= >P addresses=3D2C which change sometimes=3D2C and I l=3D> >oop over them run= >ning ssh to all of them and "see what I get"=3D2C not ideal.> >=3D20> > - J= >ay> To: jay.krell at cornell.edu> Date: Sun=3D2C 11 Jan 2009 08:02:18 -0800>= >=3D> > From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re= >: [M3d=3D> >evel] Juno (X) networking problem on AMD64_FREEBSD> > This is a= > screwy thin=3D> >g in Modula-3. A bug I would call it.> > I've noticed a l= >ot of networking M=3D> >3 programs don't work right unless> the return valu= >e of Unix's "hostname" m=3D> >aps to a real IP address via> gethostbyname. = >I accomplish it in practice by=3D> > adding my hostname> to /etc/hosts.> > = >This is obviously not the right way =3D> >to fix it... > > Mika> > Jay writ= >es:> >--_9e67232c-a064-417d-879e-227a77e31=3D> >0f9_> >Content-Type: text/p= >lain=3D3B charset=3D3D"iso-8859-1"> >Content-Transfe=3D> >r-Encoding: quote= >d-printable> >> >> >Hi. Unix network programming question.=3D> >.> >AMD64_F= >REEBSD:> >$DISPLAY is set to point back to Cygwin host.It works =3D> >for P= >PC_LINUX.> >[jay at fbsdamd64a /cm3/bin]$ ./Juno> >****** runtime error:*=3D> = >>** Exception "IPError.FatalError" not in RAISES li=3D3D> >st*** file "../s= >rc/=3D> >common/IPError.m3"=3D3D2C line 27***> >Abort trap: 6 (core dumped)= >[jay at fbsdam=3D> >d64a /cm3/bin]$> >IP.m3:> >=3D3D20> >PROCEDURE GetHostAddr= >(): Address =3D3D3D V=3D> >AR hname: ARRAY [0..255] OF CHAR=3D3D3B =3D3D> >= > BEGIN LOCK mu DO IF Unix.getho=3D> >stname(ADR(hname[0])=3D3D2C BYTESIZE(h= >na=3D3D> >me)) # 0 THEN IPError.Die ()=3D3D=3D> >3B END=3D3D3B VAR h :=3D3D= >3D Unetdb.g=3D3D> >ethostbyname(ADR(hname[0]))=3D3D3B BEG=3D> >IN IF h =3D3= >D3D NIL THEN IPError.Die()=3D3D> >=3D3D3B END=3D3D3B RETURN GetAddress(=3D>= > >h)=3D3D3B END=3D3D3B END=3D3D3B END GetHos=3D3D> >tAddr=3D3D3B> >PROCEDUR= >E GetAddress=3D> > (ent: Unetdb.struct_hostent_star): Address =3D3D3D VAR u= >a=3D3D> >: Uin.struct_=3D> >in_addr=3D3D3B BEGIN <* ASSERT ent.h_length <= >=3D3D3D BYTESIZE(Addr=3D3D> >ess) *>=3D> > ua :=3D3D3D LOOPHOLE(ent.h_addr_= >list=3D3D2C UNTRACED =3D3D> >REF UNTRACED REF Ui=3D> >n.struct_in_addr)^^= >=3D3D3B RETURN LOOPHOLE(ua.s_addr=3D3D2C A=3D3D> >ddress)=3D3D3B=3D> > END = >GetAddress=3D3D3B> >=3D3D20> >gethostbyname is failing.> >=3D3D20> >Analogo= >u=3D> >s C code also fails:> >=3D3D20> >[jay at fbsdamd64a /cm3/bin]$ cat ~/5.= >c#include=3D> > #include #i=3D3D> >nclude #incl= >ude type=3D> >def struct hostent hostent_t=3D3D3B> >=3D3D20> >int = >main(){ char hostname[200]=3D> >=3D3D3B hostent_t* h=3D3D3B int i=3D3D3B> >= > i =3D3D3D gethostname(hostname=3D3D2C 200=3D> >)=3D3D3B assert(i =3D3D3D= >=3D3D3D 0)=3D3D3B printf("hostna=3D3D> >me: %s\n"=3D3D2C hostn=3D> >ame)=3D= >3D3B h =3D3D3D gethostbyname(hostname)=3D3D3B herror("foo")=3D3D3B=3D3D> > = >pri=3D> >ntf("%p %d %d\n"=3D3D2C h=3D3D2C errno=3D3D2C h_errno)=3D3D3B asse= >rt(h)=3D3D3B return=3D> > 0=3D3D3B}> >=3D3D20> >herror says "unknown host".= >> >Stack is:> > at ../src/run=3D> >time/ex_frame/RTExFrame.m3:58#13 0x00000= >00801a7f2b3 in RTH=3D3D> >ooks__Raise=3D> > (M3_AJWxb1_ex=3D3D3DError acces= >sing memory address 0x8000ffffd278: =3D3D> >Bad=3D> > address.) at ../src/r= >untime/common/RTHooks.m3:79#14 0x000000080169c8=3D3D> >=3D> >d3 in IPError_= >_Die () at ../src/common/IPError.m3:27#15 0x0000000801698a3e =3D> >=3D3D> >= >in IP__GetHostAddr (M3_BCxjPn__result=3D3D3DError accessing memory addr=3D>= > >ess 0x80=3D3D> >00ffffd338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x0= >0000=3D> >008012133d0=3D3D> > in XSharedMem__SameHost (M3_AQuuui_trsl=3D3D3= >DError accessi=3D> >ng memory address 0=3D3D> >x8000ffffd4d8: Bad address.)= > at ../src/xvbt/XShare=3D> >dMem.m3:96#17 0x000000=3D3D> >0801212ab7 in XSh= >aredMem__InitXClient (M3_AQuuu=3D> >i_v=3D3D3DError accessing memory=3D3D> = >> address 0x8000ffffd648: Bad address.) =3D> >at ../src/xvbt/XSharedMem.m3:= >29#1=3D3D> >8 0x0000000801211819 in XExtensions_=3D> >_InitXClient (M3_AQuu= >ui_xclient=3D3D3DError=3D3D> > accessing memory address 0x=3D> >8000ffffd7f= >8: Bad address.) at ../src/xvbt/X=3D3D> >Extensions.m3:14#19 0x000=3D> >000= >08012467a4 in XClientF__Connect (M3_Bd56fi_inst=3D3D> >=3D3D3D0x1879b=3D3D2= >C M=3D> >3_AQuuui_trsl=3D3D3D0x6) at ../src/xvbt/XClientF.m3:583---Typ=3D3D= >> >e =3D> > to continue=3D3D2C or q to quit---(More stack = >frames follow=3D3D> >..=3D> >.)(gdb)> >(* return TRUE if server and client = >are on same host *)PROCEDURE =3D> >SameHost (=3D3D> >trsl: XClient.T): BOOL= >EAN =3D3D3D VAR display :=3D3D3D DisplayH=3D> >=3D3D> >ost(trsl)=3D3D3B dis= >playAddr: IP.Address=3D3D3B BEGIN IF display =3D3D3D NI=3D> >L THE=3D3D> >N= > RETURN TRUE=3D3D3B END=3D3D3B> > TRY IF NOT IP.GetHostByName(displ=3D> >ay= >=3D3D2C displayAddr) THEN RETURN FA=3D3D> >LSE=3D3D3B END=3D3D3B RETURN dis= >playAd=3D> >dr =3D3D3D IP.GetHostAddr()=3D3D3B EXCEPT =3D3D> >| IP.Error = >=3D3D3D> RETURN FALSE=3D> >=3D3D3B END=3D3D3B END SameHost=3D3D3B> >=3D3D20= >> >Thoughts?> >=3D3D20> >Perhaps my n=3D> >etwork isn't setup well=3D3D2C l= >ike I should add the local machine =3D3D> >to /=3D> >etc/hosts.I think this= > can be made to fail gracefully though.It seems l=3D3D>=3D> > >ike it has n= >othing to do with AMD64_FREEBSD=3D3D2C but could have to do wit=3D> >h Fr= >=3D3D> >eeBSD.> >=3D3D20> >Seems like SocketPosix has nearly the exact same= >=3D> > code but appearsmore forgi=3D3D> >ving.. IOError instead of Fatal?> = >>=3D3D20> =3D> >>SocketPosix.m3:> >=3D3D20> >PROCEDURE GetHostAddr (): Addr= >ess RAISES {OSErro=3D> >r.E} =3D3D3D VAR host : AR=3D3D> >RAY [0..255] OF C= >HAR=3D3D3B info : Unetdb.struc=3D> >t_hostent_star=3D3D3B ua : U=3D3D> >in.= >struct_in_addr=3D3D3B BEGIN IF Unix.gethos=3D> >tname (ADR (host[0])=3D3D2C= > BYTESI=3D3D> >ZE (host)) # 0 THEN IOError (Unexpect=3D> >ed)=3D3D3B END=3D= >3D3B> > info :=3D3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3D3B =3D> >IF = >info =3D3D3D NIL TH=3D3D> >EN IOError (Unexpected)=3D3D3B END=3D3D3B <* ASS= >ERT i=3D> >nfo.h_length <=3D3D3D BYTESIZE =3D3D> >(Address) *>> > ua :=3D3D= >3D LOOPHOLE(info.=3D> >h_addr_list=3D3D2C UNTRACED REF UNT=3D3D> >RACED REF= > Uin.struct_in_addr)^^=3D3D3B=3D> > RETURN LOOPHOLE (ua.s_addr=3D3D2C Addre= >ss=3D3D> >)=3D3D3B END GetHostAddr=3D3D3B> =3D> >>=3D3D20> >=3D3D20> >It is= > again disappointing to see such code duplication.> >=3D> >=3D3D20> >=3D3D2= >0> >I guess SameHost can duplicate the logic to predict the err=3D> >or sta= >te and ret=3D3D> >urn false upon error?> >Duplicating the logic for a t=3D>= > >hird time. :(> >=3D3D20> > - Jay=3D3D> >> >--_9e67232c-a064-417d-879e-227= >a77e31=3D> >0f9_> >Content-Type: text/html=3D3B charset=3D3D"iso-8859-1"> >= >Content-Transfer=3D> >-Encoding: quoted-printable> >> >> >> >tyle>> >.hmmessage P> =3D> >>{> >margin:0px=3D3D3B> >padding:0px> >}> >body= >.hmmessage> >{> >font-size: 10=3D> >pt=3D3D3B> >font-family:Verdana> >}> ><= >/style>> >> > >mmessage'>> >Hi. Unix network= > programming question..
> >
AMD64_FREEBS=3D> >D:
> >
$DISPLAY i= >s set to point back to Cygwin host.
It works for =3D> >PPC_LINUX=3D3D> >= >.
> >
[jay at fbsdamd64a /cm3/bin]$ ./Juno
> >
***<=3D> >BR>*** ru= >ntime error:
*** =3D3D3B =3D3D3B =3D3D3B Exception "IPE=3D> = >>=3D3D> >rror.FatalError" not in RAISES list
*** =3D3D3B =3D3D3B= > =3D> >=3D3D3B file "..=3D3D> >/src/common/IPError.m3"=3D3D2C line 27R>***
> >
A=3D> >bort trap: 6 (core dumped)
[jay at fbsdamd64a /cm3/b= >in]$
> >
IP.m3: >R>> > =3D3D3B
> >PROCEDURE GetHostAddr(= >): Address =3D3D3D
 =3D3D3B =3D> >VAR hname: ARRAY [0..255] =3D3D> O= >F CHAR=3D3D3B
 =3D3D3B BEGIN
 =3D3D=3D> >3B =3D3D3B = >=3D3D3B LOCK mu DO
&nbs=3D3D> >p=3D3D3B =3D3D3B =3D3D3B&n=3D> >b= >sp=3D3D3B =3D3D3B IF Unix.gethostname(ADR(hname[0])=3D3D2C B=3D3D> >YTE= >SIZE(hn=3D> >ame)) # 0 THEN
 =3D3D3B =3D3D3B =3D3D3B =3D= >3D3B =3D3D3B =3D> >=3D3D> >=3D3D3B =3D3D3B IPError.Die ()=3D3D3= >B
 =3D3D3B =3D3D3B =3D3D3B=3D> > =3D3D3B =3D3D3B E= >=3D3D> >ND=3D3D3B
 =3D3D3B =3D3D3B =3D3D3B =3D> >=3D3D3B= > =3D3D3B VAR h :=3D3D3D Unetdb.gethost=3D3D> >byname(ADR(hname[0]))=3D3= >D3B=3D> > BEGIN
 =3D3D3B =3D3D3B =3D3D3B =3D3D3B =3D= >3D3B&=3D3D> >nbsp=3D3D3=3D> >B =3D3D3B IF h =3D3D3D NIL THEN IPError.Di= >e()=3D3D3B END=3D3D3B
 =3D3D3B&n=3D> >bsp=3D3D> >=3D3D3B =3D3D3B= > =3D3D3B =3D3D3B =3D3D3B =3D3D3B RETURN Get=3D> >Address(h)= >=3D3D3B
&nbs=3D3D> >p=3D3D3B =3D3D3B =3D3D3B =3D3D3B =3D= >3D3B=3D> > END=3D3D3B
 =3D3D3B =3D3D3B =3D3D3B END=3D3D> >= >=3D3D3B
 =3D3D3B EN=3D> >D GetHostAddr=3D3D3B
> >
PROCEDURE Ge= >tAddress (ent: Unetdb.struct_hoste=3D> >nt_star): Address =3D3D3D
=3D3D>= > > =3D3D3B VAR ua: Uin.struct_in_addr=3D3D3B=3D> >
 =3D3D3B BEGI= >N
 =3D3D3B =3D3D> >=3D3D3B =3D3D3B <=3D3D3B* ASSE=3D> >RT = >ent.h_length <=3D3D3B=3D3D3D BYTESIZE(Address) *>=3D3D3B=3D3D> >
&nb= >sp=3D3D=3D> >3B =3D3D3B =3D3D3B ua :=3D3D3D LOOPHOLE(ent.h_addr_lis= >t=3D3D2C
 =3D3D>=3D> > >=3D3D3B =3D3D3B =3D3D3B =3D3D3B&= >nbsp=3D3D3B =3D3D3B =3D3D3B =3D3D=3D> >3B =3D3D3B =3D3D= >3B=3D3D> > =3D3D3B =3D3D3B =3D3D3B =3D3D3B =3D> >=3D3D3= >B =3D3D3B =3D3D3B =3D3D3B =3D3D3B UN=3D3D> >TRACED REF UNTR= >ACED R=3D> >EF Uin.struct_in_addr)^^=3D3D3B
 =3D3D3B =3D3D3B&nbs= >p=3D3D> >=3D3D3B RETUR=3D> >N LOOPHOLE(ua.s_addr=3D3D2C Address)=3D3D3B
= > =3D3D3B END GetAddress=3D3D3B<=3D> >=3D3D> >BR>> > =3D3D3B
> >g= >ethostbyname is failing.
> >
 =3D3D3B=3D> >
> >Analogous C cod= >e also fails:
> > =3D3D3B
> >
[jay at fbsdamd=3D> >64a /cm3/bin]$= > cat ~/5.c
#include <=3D3D3Bassert.h>=3D3D3B >R>#inc=3D> >lu= >de <=3D3D3Bnetdb.h>=3D3D3B
#include <=3D3D3Bstdio.h>=3D3D3B
#= >includ=3D> >e =3D3D> ><=3D3D3Berrno.h>=3D3D3B
typedef struct hostent= > hostent_t=3D3D3B >>> > =3D3D3B
> >int main()
{
 = >=3D3D3Bchar hostname[200]=3D3D3B >R> =3D3D3Bhostent_t* h=3D3D3B= >=3D3D> >
 =3D3D3Bint i=3D3D3B
> > =3D3D3=3D> >Bi =3D3D3D geth= >ostname(hostname=3D3D2C 200)=3D3D3B
 =3D3D3Bassert(i =3D3D3D=3D3D=3D= >> >3D 0)=3D3D> >=3D3D3B
 =3D3D3Bprintf("hostname: %s\n"=3D3D2C hostn= >ame)=3D3D3B >R> =3D3D3Bh =3D3D3D get=3D3D> >hostbyname(hostname)= >=3D3D3B
 =3D3D3Bherror(=3D> >"foo")=3D3D3B
 =3D3D3Bprintf("%p= > %=3D3D> >d %d\n"=3D3D2C h=3D3D2C errno=3D3D2C h=3D> >_errno)=3D3D3B
&nb= >sp=3D3D3Bassert(h)=3D3D3B
 =3D3D3Bret=3D3D> >urn 0=3D3D3B >R>}= >
> > =3D3D3B
> >herror says "unknown host".
> >
Stack is:<= >=3D> >BR>> > =3D3D3B =3D3D3B =3D3D3B at ../src/runtime/ex_frame= >/RTExFrame.m=3D> >3:58
#13 =3D3D> >0x0000000801a7f2b3 in RTHooks__Raise = >(M3_AJWxb1_ex=3D3D3DEr=3D> >ror accessing memory=3D3D> > ad
dress 0x8000= >ffffd278: Bad address.
) >> =3D3D3B =3D3D3B =3D3D3B = >=3D3D> >at ../src/runtime/common/RTHooks.m3:7=3D> >9
#14 0x000000080169c= >8d3 in IPError=3D3D> >__Die () at ../src/common/IPErr=3D> >or.m3:27
#15 = >0x0000000801698a3e in IP__Ge=3D3D> >tHostAddr (M3_BCxjPn__res=3D> ult=3D3D3= >DError accessing mem
ory address 0x8000fff=3D3D> >fd338: Bad addres=3D> = >>s.
)
 =3D3D3B =3D3D3B =3D3D3B at ../src/POSIX/IP.m3:=3D3= >D> >82 >>#16 0x00000008012133d0 in XSharedMem__SameHost (M3_AQuuui_t= >rsl=3D3D3DErro=3D3D=3D> >> >r accessing m
emory address 0x8000ffffd4d8: = >Bad address.
)
&nbs=3D> >p=3D3D> >=3D3D3B =3D3D3B =3D3D3B at = >../src/xvbt/XSharedMem.m3:96
#17 0x0=3D> >000000801212a=3D3D> >b7 in XSh= >aredMem__InitXClient (M3_AQuuui_v=3D3D3DError acc=3D> >essing m
emory ad= >d=3D3D> >ress 0x8000ffffd648: Bad address.
)
 =3D> >=3D3D3B = >=3D3D3B =3D3D3B at ../sr=3D3D> >c/xvbt/XSharedMem.m3:29
#18 0x00=3D>= > >00000801211819 in XExtensions__InitXClie=3D3D> >nt (M3_AQuuui_xclient=3D3= >D3DErr=3D> >or acce
ssing memory address 0x8000ffffd7f8: =3D3D> >Bad add= >ress.
)
=3D> > =3D3D3B =3D3D3B =3D3D3B at ../src/xvbt/XEx= >tensions.m3=3D3D> >:14
#1=3D> >9 0x00000008012467a4 in XClientF__Connect= > (M3_Bd56fi_inst=3D3D3D0x1879=3D3D> >b=3D> >=3D3D2C
 =3D3D3B =3D= >3D3B =3D3D3B M3_AQuuui_trsl=3D3D3D0x6) at ../src/x=3D> >vbt/XClie=3D3D>= > >ntF.m3:583
---Type <=3D3D3Breturn>=3D3D3B to continue=3D3D2=3D> >C= > or q <=3D3D3Breturn&g=3D3D> >t=3D3D3B to quit---
(More stack frames f= >ollow=3D> >...)
(gdb)
> >
(* return TRUE if server and client are = >on same hos=3D> >t *)
PROCEDURE Sa=3D3D> >meHost (trsl: XClient.T): BOOL= >EAN =3D3D3D
 =3D> >=3D3D3B VAR
 =3D3D3B =3D3D3B&n=3D3D> >= >bsp=3D3D3B display =3D3D3B =3D3D=3D> >3B =3D3D3B =3D3D3B&nb= >sp=3D3D3B =3D3D3B =3D3D3B =3D3D> >=3D3D3B =3D> >=3D3D3B&nbs= >p=3D3D3B =3D3D3B =3D3D3B =3D3D3B =3D3D3B =3D3D3B = >=3D3D3B=3D> :=3D3D3D Di=3D3D> >splayHost(trsl)=3D3D3B
 =3D3D3B = >=3D3D3B =3D3D3B disp=3D> >layAddr: IP.Address=3D3D3B >R> = >=3D3D3B BEGIN
 =3D3D3B =3D3D3B&=3D> >nbsp=3D3D3B IF display =3D3= >D3D NIL THEN RETURN=3D3D> > TRUE=3D3D3B END=3D3D3B
> >&=3D> >nbsp=3D3D3B= > =3D3D3B =3D3D3B TRY
 =3D3D3B =3D3D3B =3D3D3B = >=3D3D=3D> >3B =3D3D3B IF=3D3D> > NOT IP.GetHostByName(display=3D3D2C di= >splayAddr) THEN R=3D> >ETURN FALSE=3D3D3B END=3D3D3B >R> =3D3D3= >B =3D3D3B =3D3D3B =3D3D3B=3D> > =3D3D3B RETURN displayAddr = >=3D3D3D IP.GetHos=3D3D> >tAddr()=3D3D3B
 =3D3D=3D> >3B =3D3D3B&n= >bsp=3D3D3B EXCEPT
 =3D3D3B =3D3D3B =3D3D3B |=3D3D> > IP.=3D>= > >Error =3D3D3D>=3D3D3B RETURN FALSE=3D3D3B
 =3D3D3B =3D3D3B&n= >bsp=3D3D3B END=3D> >=3D3D3B
&=3D3D> >nbsp=3D3D3B END SameHost=3D3D3B
= >> > =3D3D3B
> >Thoughts=3D> >?
> > =3D3D3B
> >
Perhaps = >my network isn't setup well=3D3D2C like =3D> >I should add the local mach= >=3D3D> >ine to /etc/hosts.
I think this can be =3D> >made to fail gracef= >ully though. >R>It seems like it has nothing to do=3D> > with AMD64= >_FREEBSD=3D3D2C but could have t=3D3D> >o do with FreeBSD.
> > >>= > =3D3D3B
> >Seems like SocketPosix has nearly the exact same code bu= >t=3D> > appears
more f=3D3D> >orgiving.. IOError instead of Fatal?
> = >> =3D3D=3D> >3B
> >
SocketPosix.m3:
> > =3D3D3B
> >
= >PROCEDURE GetHostAd=3D> >dr (): Address
 =3D3D3B RAISES {OSError.E} = >=3D3D3D >> =3D3D3B V=3D> >AR
 =3D3D3B =3D3D3B = >=3D3D3B host : ARRAY [0..255] OF CHAR=3D3D3B<=3D3D=3D> >> >BR> =3D3D3B&= >nbsp=3D3D3B =3D3D3B info : Unetdb.struct_hostent_star=3D3D3B=3D> >
&= >nbsp=3D3D> >=3D3D3B =3D3D3B =3D3D3B ua =3D3D3B =3D3D3B : Ui= >n.struc=3D> >t_in_addr=3D3D3B
 =3D3D3B =3D3D> >BEGIN
 =3D3D3B= > =3D3D3B =3D3D3B =3D> >IF Unix.gethostname (ADR (host[0])=3D3D2C BY= >T=3D3D> >ESIZE (host)) # 0 THEN
=3D> > =3D3D3B =3D3D3B =3D3D= >3B =3D3D3B =3D3D3B IOError =3D3D> >(Unexpecte=3D> >d)=3D3D3B
&nb= >sp=3D3D3B =3D3D3B =3D3D3B END=3D3D3B
> > =3D3D3B =3D3D= >=3D> >3B =3D3D3B info :=3D3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3= >D3B<=3D3D> >BR=3D> >> =3D3D3B =3D3D3B =3D3D3B IF info =3D3D3D N= >IL THEN IOError (Unexpected)=3D> >=3D3D3B EN=3D3D> >D=3D3D3B
 =3D3D3= >B =3D3D3B =3D3D3B <=3D3D3B* ASSERT inf=3D> >o.h_length <=3D3D3B= >=3D3D3D BYT=3D3D> >ESIZE (Address) *>=3D3D3B
> > =3D3D3=3D> >B&nbs= >p=3D3D3B =3D3D3B ua :=3D3D3D LOOPHOLE(info.h_addr_list=3D3D2C
 = >=3D3D3=3D> >B&n=3D3D> >bsp=3D3D3B =3D3D3B =3D3D3B =3D3D3B = >=3D3D3B =3D3D3B =3D3D=3D> >3B =3D3D3B =3D3D3B =3D3D> >= >=3D3D3B =3D3D3B =3D3D3B =3D3D3B =3D> >=3D3D3B =3D3D3B&n= >bsp=3D3D3B =3D3D3B UNTRACED REF UN=3D3D> >TRACED REF Uin.str=3D> >uct_i= >n_addr)^^=3D3D3B
 =3D3D3B =3D3D3B =3D3D3B RETURN LOOP=3D3D> = >>HOLE=3D> > (ua.s_addr=3D3D2C Address)=3D3D3B
 =3D3D3B END GetHostAd= >dr=3D3D3B
> >&nb=3D> >sp=3D3D3B
> > =3D3D3B
> >It is again dis= >appointing to see such code d=3D> >uplication.
> > =3D3D3B
> >&nb= >sp=3D3D3B
> >I guess =3D3D3BSameHo=3D> >st can duplicate the logic t= >o predict the error state =3D3D> >and return fals=3D> >e =3D3D3Bupon er= >ror?
> >Duplicating the logic for a third time. :(
=3D> >> > =3D3= >D3B
> >
 =3D3D3B- Jay

> >=3D3D> >> >--=3D> >= >_9e67232c-a064-417d-879e-227a77e310f9_--=3D> >> >--_b00371fe-730b-4981-9051= >-a874361296d7_> >Content-Type: text/html=3B charset=3D"iso-8859-1"> >Conten= >t-Transfer-Encoding: quoted-printable> >> >> >> >> >> >ass=3D3D'hmmessage'>> >Do you know the right way?
> > =3D3B
> >PP= >C_LINUX "just worked"=3D2C and I can check Solaris and Darwin.
> > = >=3D3B
> >I don't want to edit /etc/hosts -- I use DHCP.
> >Though DHC= >P has been bothering me -- only for some of my machines do names =3D> >reso= >lve=3D2C so I end using IP addresses=3D2C which change sometimes=3D2C and I= > l=3D> >oop over them running ssh to all of them and "see what I get"=3D2C = >not ideal.=3D> >
> > =3D3B
> > =3D3B- Jay


>=3D3B= > To: jay.krell at cornell.edu
>=3D3B Date: S=3D> >un=3D2C 11 Jan 2009 08:= >02:18 -0800
>=3D3B From: mika at async.caltech.edu
=3D> >>=3D3B CC: = >m3devel at elegosoft.com
>=3D3B Subject: Re: [M3devel] Juno (X) =3D> >net= >working problem on AMD64_FREEBSD
>=3D3B
>=3D3B This is a screwy = >t=3D> >hing in Modula-3. A bug I would call it.
>=3D3B
>=3D3B I'= >ve noticed =3D> >a lot of networking M3 programs don't work right unless>>=3D3B the retur=3D> >n value of Unix's "hostname" maps to a real IP add= >ress via
>=3D3B gethos=3D> >tbyname. I accomplish it in practice by ad= >ding my hostname
>=3D3B to /et=3D> >c/hosts.
>=3D3B
>=3D3B = >This is obviously not the right way to fix it=3D> >...
>=3D3B
>= >=3D3B Mika
>=3D3B
>=3D3B Jay writes:
>=3D3B &=3D> >gt=3D3B-= >-_9e67232c-a064-417d-879e-227a77e310f9_
>=3D3B >=3D3BContent-Type:= >=3D> > text/plain=3D3B charset=3D3D"iso-8859-1"
>=3D3B >=3D3BContent= >-Transfer-Enco=3D> >ding: quoted-printable
>=3D3B >=3D3B
>=3D3B= > >=3D3B
>=3D3B >=3D3BHi=3D> >. Unix network programming question..= >
>=3D3B >=3D3BAMD64_FREEBSD:
>=3D> >=3D3B >=3D3B$DISPLAY is s= >et to point back to Cygwin host.It works for PPC_LIN=3D> >UX.
>=3D3B &= >gt=3D3B[jay at fbsdamd64a /cm3/bin]$ ./Juno
>=3D3B >=3D3B*****=3D> >* r= >untime error:*** Exception "IPError.FatalError" not in RAISES li=3D3D
&= >=3D> >gt=3D3B >=3D3Bst*** file "../src/common/IPError.m3"=3D3D2C line 27*= >**
>=3D3B=3D> > >=3D3BAbort trap: 6 (core dumped)[jay at fbsdamd64a /cm= >3/bin]$
>=3D3B >=3D> >=3D3BIP.m3:
>=3D3B >=3D3B=3D3D20
>= >=3D3B >=3D3BPROCEDURE GetHostAddr(): Ad=3D> >dress =3D3D3D VAR hname: ARR= >AY [0..255] OF CHAR=3D3D3B =3D3D
>=3D3B >=3D3B BEG=3D> >IN LOCK mu D= >O IF Unix.gethostname(ADR(hname[0])=3D3D2C BYTESIZE(hna=3D3D
>=3D> >= >=3D3B >=3D3Bme)) # 0 THEN IPError.Die ()=3D3D3B END=3D3D3B VAR h :=3D3D3D= > Unetdb.g=3D> >=3D3D
>=3D3B >=3D3Bethostbyname(ADR(hname[0]))=3D3D3B= > BEGIN IF h =3D3D3D NIL T=3D> >HEN IPError.Die()=3D3D
>=3D3B >=3D3B= >=3D3D3B END=3D3D3B RETURN GetAddress(h)=3D3D=3D> >3B END=3D3D3B END=3D3D3B = >END GetHos=3D3D
>=3D3B >=3D3BtAddr=3D3D3B
>=3D3B >=3D> >=3D3B= >PROCEDURE GetAddress (ent: Unetdb.struct_hostent_star): Address =3D3D3D VA= >=3D> >R ua=3D3D
>=3D3B >=3D3B: Uin.struct_in_addr=3D3D3B BEGIN <= >=3D3B* ASSERT ent.=3D> >h_length <=3D3B=3D3D3D BYTESIZE(Addr=3D3D
>= >=3D3B >=3D3Bess) *>=3D3B ua :=3D3D3=3D> >D LOOPHOLE(ent.h_addr_list=3D3= >D2C UNTRACED =3D3D
>=3D3B >=3D3BREF UNTRACED R=3D> >EF Uin.struct_in= >_addr)^^=3D3D3B RETURN LOOPHOLE(ua.s_addr=3D3D2C A=3D3D
>=3D3B=3D> > &= >gt=3D3Bddress)=3D3D3B END GetAddress=3D3D3B
>=3D3B >=3D3B=3D3D20
= >>=3D3B >=3D> >=3D3Bgethostbyname is failing.
>=3D3B >=3D3B=3D3D2= >0
>=3D3B >=3D3BAnalogou=3D> >s C code also fails:
>=3D3B >=3D= >3B=3D3D20
>=3D3B >=3D3B[jay at fbsdamd64a =3D> >/cm3/bin]$ cat ~/5.c#in= >clude <=3D3Bassert.h>=3D3B#include <=3D3Bnetdb.h>=3D> >=3D3B#i=3D3D= >
>=3D3B >=3D3Bnclude <=3D3Bstdio.h>=3D3B#include <=3D3Berrno.h= >&g=3D> >t=3D3Btypedef struct hostent hostent_t=3D3D3B
>=3D3B >=3D3B= >=3D3D20
>=3D3B &=3D> >gt=3D3Bint main(){ char hostname[200]=3D3D3B hos= >tent_t* h=3D3D3B int i=3D3D3B
&g=3D> >t=3D3B >=3D3B i =3D3D3D gethostn= >ame(hostname=3D3D2C 200)=3D3D3B assert(i =3D3D3D=3D3D3D=3D> > 0)=3D3D3B pri= >ntf("hostna=3D3D
>=3D3B >=3D3Bme: %s\n"=3D3D2C hostname)=3D3D3B h = >=3D> >=3D3D3D gethostbyname(hostname)=3D3D3B herror("foo")=3D3D3B=3D3D
&= >gt=3D3B >=3D3B p=3D> >rintf("%p %d %d\n"=3D3D2C h=3D3D2C errno=3D3D2C h_e= >rrno)=3D3D3B assert(h)=3D3D3B retu=3D> >rn 0=3D3D3B}
>=3D3B >=3D3B= >=3D3D20
>=3D3B >=3D3Bherror says "unknown host"=3D> >.
>=3D3B &= >gt=3D3BStack is:
>=3D3B >=3D3B at ../src/runtime/ex_frame/RTE=3D> >x= >Frame.m3:58#13 0x0000000801a7f2b3 in RTH=3D3D
>=3D3B >=3D3Books__Rai= >se (M=3D> >3_AJWxb1_ex=3D3D3DError accessing memory address 0x8000ffffd278:= > =3D3D
>=3D> >=3D3B >=3D3BBad address.) at ../src/runtime/common/RTH= >ooks.m3:79#14 0x0000000=3D> >80169c8=3D3D
>=3D3B >=3D3Bd3 in IPError= >__Die () at ../src/common/IPError.m=3D> >3:27#15 0x0000000801698a3e =3D3DR>>=3D3B >=3D3Bin IP__GetHostAddr (M3_BCxjP=3D> >n__result=3D3D3DError = >accessing memory address 0x80=3D3D
>=3D3B >=3D3B00ffff=3D> >d338: Ba= >d address.) at ../src/POSIX/IP.m3:82#16 0x00000008012133d0=3D3D
&g=3D> >= >t=3D3B >=3D3B in XSharedMem__SameHost (M3_AQuuui_trsl=3D3D3DError accessi= >ng mem=3D> >ory address 0=3D3D
>=3D3B >=3D3Bx8000ffffd4d8: Bad addre= >ss.) at ../src/xvb=3D> >t/XSharedMem.m3:96#17 0x000000=3D3D
>=3D3B >= >=3D3B0801212ab7 in XSharedMem_=3D> >_InitXClient (M3_AQuuui_v=3D3D3DError a= >ccessing memory=3D3D
>=3D3B >=3D3B ad=3D> >dress 0x8000ffffd648: Bad= > address.) at ../src/xvbt/XSharedMem.m3:29#1=3D3D >>>=3D3B >=3D3= >B8 0x0000000801211819 in XExtensions__InitXClient (M3_AQuuui_x=3D> >client= >=3D3D3DError=3D3D
>=3D3B >=3D3B accessing memory address 0x8000ffffd= >7f=3D> >8: Bad address.) at ../src/xvbt/X=3D3D
>=3D3B >=3D3BExtensio= >ns.m3:14#19 0x=3D> >00000008012467a4 in XClientF__Connect (M3_Bd56fi_inst= >=3D3D
>=3D3B >=3D3B=3D> >=3D3D3D0x1879b=3D3D2C M3_AQuuui_trsl=3D3D3D= >0x6) at ../src/xvbt/XClientF.m3:583---=3D> >Typ=3D3D
>=3D3B >=3D3Be = ><=3D3Breturn>=3D3B to continue=3D3D2C or q <=3D3Bret=3D> >urn>=3D3B= > to quit---(More stack frames follow=3D3D
>=3D3B >=3D3B...)(gdb)<=3D= >> >BR>>=3D3B >=3D3B(* return TRUE if server and client are on same host= > *)PROC=3D> >EDURE SameHost (=3D3D
>=3D3B >=3D3Btrsl: XClient.T): BO= >OLEAN =3D3D3D VAR dis=3D> >play :=3D3D3D DisplayH=3D3D
>=3D3B >=3D3B= >ost(trsl)=3D3D3B displayAddr: IP.Addr=3D> >ess=3D3D3B BEGIN IF display =3D3= >D3D NIL THE=3D3D
>=3D3B >=3D3BN RETURN TRUE=3D3D=3D> >3B END=3D3D3B<= >BR>>=3D3B >=3D3B TRY IF NOT IP.GetHostByName(display=3D3D2C displ=3D> >= >ayAddr) THEN RETURN FA=3D3D
>=3D3B >=3D3BLSE=3D3D3B END=3D3D3B RETUR= >N displayA=3D> >ddr =3D3D3D IP.GetHostAddr()=3D3D3B EXCEPT =3D3D
>=3D3= >B >=3D3B| IP.Error =3D3D3D=3D> >>=3D3B RETURN FALSE=3D3D3B END=3D3D3B E= >ND SameHost=3D3D3B
>=3D3B >=3D3B=3D3D20 >R>>=3D3B >=3D3BTh= >oughts?
>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3BPerhaps my n=3D> >e= >twork isn't setup well=3D3D2C like I should add the local machine =3D3D
= >>=3D> >=3D3B >=3D3Bto /etc/hosts.I think this can be made to fail grace= >fully though.=3D> >It seems l=3D3D
>=3D3B >=3D3Bike it has nothing t= >o do with AMD64_FREEBSD=3D> >=3D3D2C but could have to do with Fr=3D3D
&= >gt=3D3B >=3D3BeeBSD.
>=3D3B >=3D> >=3D3B=3D3D20
>=3D3B >=3D= >3BSeems like SocketPosix has nearly the exact same c=3D> >ode but appearsmo= >re forgi=3D3D
>=3D3B >=3D3Bving.. IOError instead of Fata=3D> >l?>>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3BSocketPosix.m3:
>=3D3B &= >gt=3D3B=3D> >=3D3D20
>=3D3B >=3D3BPROCEDURE GetHostAddr (): Address = >RAISES {OSError.E} =3D> >=3D3D3D VAR host : AR=3D3D
>=3D3B >=3D3BRAY= > [0..255] OF CHAR=3D3D3B info : Une=3D> >tdb.struct_hostent_star=3D3D3B ua = >: U=3D3D
>=3D3B >=3D3Bin.struct_in_addr=3D3D=3D> >3B BEGIN IF Unix.g= >ethostname (ADR (host[0])=3D3D2C BYTESI=3D3D
>=3D3B >=3D3B=3D> >ZE (= >host)) # 0 THEN IOError (Unexpected)=3D3D3B END=3D3D3B
>=3D3B >=3D3B= > inf=3D> >o :=3D3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3D3B IF info = >=3D3D3D NIL TH=3D3D<=3D> >BR>>=3D3B >=3D3BEN IOError (Unexpected)=3D3D3= >B END=3D3D3B <=3D3B* ASSERT info.h=3D> >_length <=3D3B=3D3D3D BYTESIZE = >=3D3D
>=3D3B >=3D3B(Address) *>=3D3B
>=3D> >=3D3B >=3D3B ua= > :=3D3D3D LOOPHOLE(info.h_addr_list=3D3D2C UNTRACED REF UNT=3D3D
=3D> >&= >gt=3D3B >=3D3BRACED REF Uin.struct_in_addr)^^=3D3D3B RETURN LOOPHOLE (ua.= >s_add=3D> >r=3D3D2C Address=3D3D
>=3D3B >=3D3B)=3D3D3B END GetHostAd= >dr=3D3D3B
>=3D3B >=3D> >=3D3B=3D3D20
>=3D3B >=3D3B=3D3D20
= >>=3D3B >=3D3BIt is again disappointing to=3D> > see such code duplicati= >on.
>=3D3B >=3D3B=3D3D20
>=3D3B >=3D3B=3D3D20
=3D> >>=3D= >3B >=3D3BI guess SameHost can duplicate the logic to predict the error = >=3D> >state and ret=3D3D
>=3D3B >=3D3Burn false upon error?
>= >=3D3B >=3D3BDupl=3D> >icating the logic for a third time. :(
>=3D3B = >>=3D3B=3D3D20
>=3D3B >=3D> >=3D3B - Jay=3D3D
>=3D3B >=3D3B<= >BR>>=3D3B >=3D3B--_9e67232c-a064-417d-879e-22=3D> >7a77e310f9_
>= >=3D3B >=3D3BContent-Type: text/html=3D3B charset=3D3D"iso-8859-=3D> >1"R>>=3D3B >=3D3BContent-Transfer-Encoding: quoted-printable
>=3D3B = >&g=3D> >t=3D3B
>=3D3B >=3D3B<=3D3Bhtml>=3D3B
>=3D3B >=3D3= >B<=3D3Bhead>=3D3B
&=3D> >gt=3D3B >=3D3B<=3D3Bstyle>=3D3B
&g= >t=3D3B >=3D3B.hmmessage P
>=3D3B >=3D3B=3D> >{
>=3D3B >=3D3= >Bmargin:0px=3D3D3B
>=3D3B >=3D3Bpadding:0px
>=3D3B >=3D> >=3D= >3B}
>=3D3B >=3D3Bbody.hmmessage
>=3D3B >=3D3B{
>=3D3B &g= >t=3D3Bfont-=3D> >size: 10pt=3D3D3B
>=3D3B >=3D3Bfont-family:Verdana<= >BR>>=3D3B >=3D3B}
&g=3D> >t=3D3B >=3D3B<=3D3B/style>=3D3B
&= >gt=3D3B >=3D3B<=3D3B/head>=3D3B
>=3D3B &=3D> >gt=3D3B<=3D3Bbod= >y class=3D3D3D'hmmessage'>=3D3B
>=3D3B >=3D3BHi. Unix networ=3D> >= >k programming question..<=3D3BBR>=3D3B
>=3D3B >=3D3B<=3D3BBR&g= >t=3D3BAMD64_=3D> >FREEBSD:<=3D3BBR>=3D3B
>=3D3B >=3D3B<=3D3BBR= >>=3D3B$DISPLAY is set to poi=3D> >nt back to Cygwin host.<=3D3BBR>=3D= >3BIt works for PPC_LINUX=3D3D
>=3D3B &g=3D> >t=3D3B.<=3D3BBR>=3D3B= >
>=3D3B >=3D3B<=3D3BBR>=3D3B[jay at fbsdamd64a /cm3/bin]=3D> >$ ./J= >uno<=3D3BBR>=3D3B
>=3D3B >=3D3B<=3D3BBR>=3D3B***<=3D3BBR&g= >t=3D3B*** r=3D> >untime error:<=3D3BBR>=3D3B***&=3D3Bnbsp=3D3D3B&= >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D> >=3D3D3B Exception "IPE=3D3D
>=3D3B = >>=3D3Brror.FatalError" not in RAISES list=3D> ><=3D3BBR>=3D3B***&= >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B file "..=3D> >=3D3= >D
>=3D3B >=3D3B/src/common/IPError.m3"=3D3D2C line 27<=3D3BBR>= >=3D3B***&l=3D> >t=3D3BBR>=3D3B
>=3D3B >=3D3B<=3D3BBR>=3D3BAbor= >t trap: 6 (core dumped)<=3D> >=3D3BBR>=3D3B[jay at fbsdamd64a /cm3/bin]$&l= >t=3D3BBR>=3D3B
>=3D3B >=3D3B<=3D3BB=3D> >R>=3D3BIP.m3:<=3D3B= >BR>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B<=3D> = >>BR>>=3D3B >=3D3BPROCEDURE GetHostAddr(): Address =3D3D3D<=3D3BBR>= >=3D3B&=3D3B=3D> >nbsp=3D3D3B VAR hname: ARRAY [0..255] =3D3D
>=3D3B= > OF CHAR=3D3D3B<=3D3BBR>=3D> >=3D3B&=3D3Bnbsp=3D3D3B BEGIN<=3D3BBR= >>=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D> >=3D3Bnbsp=3D3D3B = >LOCK mu DO<=3D3BBR>=3D3B&=3D3Bnbs=3D3D
>=3D3B >=3D3Bp=3D3D3B&= >a=3D> >mp=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bn= >bsp=3D3D3B IF Unix.geth=3D> >ostname(ADR(hname[0])=3D3D2C B=3D3D
>=3D3= >B >=3D3BYTESIZE(hname)) # 0 THEN<=3D> >=3D3BBR>=3D3B&=3D3Bnbsp=3D3= >D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B=3D> >&= >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D
>=3D3B >=3D3B=3D3D3B&=3D3Bnbsp= >=3D3D3B IPErro=3D> >r.Die ()=3D3D3B<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B&a= >mp=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B=3D> >&=3D3Bnbsp=3D3D3B&=3D3Bnb= >sp=3D3D3B E=3D3D
>=3D3B >=3D3BND=3D3D3B<=3D3BBR>=3D3B=3D> >&= >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3= >B&=3D3Bnbsp=3D> >=3D3D3B VAR h :=3D3D3D Unetdb.gethost=3D3D
>=3D3B = >>=3D3Bbyname(ADR(hname[0]))=3D> >=3D3D3B BEGIN<=3D3BBR>=3D3B&=3D3B= >nbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&a=3D> >mp=3D3Bnbsp=3D3D= >3B&=3D3Bnbsp=3D3D3B&=3D3B=3D3D
>=3D3B >=3D3Bnbsp=3D3D3B&=3D= >3Bnb=3D> >sp=3D3D3B IF h =3D3D3D NIL THEN IPError.Die()=3D3D3B END=3D3D3B&l= >t=3D3BBR>=3D3B&=3D> >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D
>=3D3B &g= >t=3D3B=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D> >=3D3D3B&=3D3Bnbsp=3D= >3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B RETURN GetAddress(h)=3D> >=3D3= >D3B<=3D3BBR>=3D3B&=3D3Bnbs=3D3D
>=3D3B >=3D3Bp=3D3D3B&=3D3= >Bnbsp=3D3D3B&=3D> >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3= >D3B END=3D3D3B<=3D3BBR>=3D3B&=3D3Bn=3D> >bsp=3D3D3B&=3D3Bnbsp=3D3= >D3B&=3D3Bnbsp=3D3D3B END=3D3D
>=3D3B >=3D3B=3D3D3B<=3D3B=3D> >B= >R>=3D3B&=3D3Bnbsp=3D3D3B END GetHostAddr=3D3D3B<=3D3BBR>=3D3B
&= >gt=3D3B >=3D> >=3D3B<=3D3BBR>=3D3BPROCEDURE GetAddress (ent: Unetdb.s= >truct_hostent_star): Ad=3D> >dress =3D3D3D<=3D3BBR>=3D3B=3D3D
>=3D= >3B >=3D3B&=3D3Bnbsp=3D3D3B VAR ua: Uin.s=3D> >truct_in_addr=3D3D3B<= >=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B BEGIN<=3D3BBR>=3D3B&=3D3B=3D> >n= >bsp=3D3D3B&=3D3Bnbsp=3D3D
>=3D3B >=3D3B=3D3D3B&=3D3Bnbsp=3D3D3= >B &=3D3Blt=3D3D3=3D> >B* ASSERT ent.h_length &=3D3Blt=3D3D3B=3D3D3D B= >YTESIZE(Address) *&=3D3Bgt=3D3D3=3D> >B=3D3D
>=3D3B >=3D3B<=3D3= >BBR>=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bn=3D> >bsp=3D3D= >3B ua :=3D3D3D LOOPHOLE(ent.h_addr_list=3D3D2C<=3D3BBR>=3D3B&=3D3Bnb= >sp=3D> >=3D3D
>=3D3B >=3D3B=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp= >=3D3D3B&=3D3Bnbsp=3D3D3B&a=3D> >mp=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&a= >mp=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D> >=3D3D3B&=3D3Bnb= >sp=3D3D3B=3D3D
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B= >&a=3D> >mp=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3B= >nbsp=3D3D3B&=3D3Bnbsp=3D> >=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D= >3B UN=3D3D
>=3D3B >=3D3BTRACED REF UNTR=3D> ACED REF Uin.struct_in_a= >ddr)^^=3D3D3B<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbs=3D> >p=3D3D= >3B&=3D3Bnbsp=3D3D
>=3D3B >=3D3B=3D3D3B RETURN LOOPHOLE(ua.s_addr= >=3D3D2C A=3D> >ddress)=3D3D3B<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B END Get= >Address=3D3D3B<=3D3B=3D3D
=3D> >>=3D3B >=3D3BBR>=3D3B
>=3D3= >B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
>=3D> >=3D3B >=3D3B= >gethostbyname is failing.<=3D3BBR>=3D3B
>=3D3B >=3D3B<=3D3BBR&= >=3D> >gt=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
>=3D3B >=3D3BAna= >logous C code also f=3D> >ails:<=3D3BBR>=3D3B
>=3D3B >=3D3B&= >=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
>=3D> >=3D3B >=3D3B<=3D3BBR>= >=3D3B[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c<=3D3BBR>=3D3B#=3D> >include &= >amp=3D3Blt=3D3D3Bassert.h&=3D3Bgt=3D3D3B<=3D3BB=3D3D
>=3D3B >= >=3D3BR>=3D> >=3D3B#include &=3D3Blt=3D3D3Bnetdb.h&=3D3Bgt=3D3D3B<= >=3D3BBR>=3D3B#include &=3D> >=3D3Blt=3D3D3Bstdio.h&=3D3Bgt=3D3D3B&l= >t=3D3BBR>=3D3B#include =3D3D
>=3D3B >=3D3B&=3D> >amp=3D3Blt=3D3D3B= >errno.h&=3D3Bgt=3D3D3B<=3D3BBR>=3D3Btypedef struct hostent host=3D> = >>ent_t=3D3D3B<=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<= >=3D3BBR>=3D3B
=3D> >>=3D3B >=3D3Bint main()<=3D3BBR>=3D3B{<= >=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3Bchar ho=3D> >stname[200]=3D3D3B<=3D3BB= >R>=3D3B&=3D3Bnbsp=3D3D3Bhostent_t* h=3D3D3B=3D3D
>=3D> >=3D3B >= >=3D3B<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3Bint i=3D3D3B<=3D3BBR>=3D3BR>>=3D3B =3D> >>=3D3B&=3D3Bnbsp=3D3D3Bi =3D3D3D gethostname(hostname= >=3D3D2C 200)=3D3D3B<=3D3BBR&g=3D> >t=3D3B&=3D3Bnbsp=3D3D3Bassert(i =3D= >3D3D=3D3D3D 0)=3D3D
>=3D3B >=3D3B=3D3D3B<=3D3BBR=3D> >>=3D3B&= >=3D3Bnbsp=3D3D3Bprintf("hostname: %s\n"=3D3D2C hostname)=3D3D3B<=3D3BBR&g= >=3D> >t=3D3B&=3D3Bnbsp=3D3D3Bh =3D3D3D get=3D3D
>=3D3B >=3D3Bhost= >byname(hostname)=3D3D3=3D> >B<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3Bherror("= >foo")=3D3D3B<=3D3BBR>=3D3B&=3D3Bnbsp=3D> >=3D3D3Bprintf("%p %=3D3DR>>=3D3B >=3D3Bd %d\n"=3D3D2C h=3D3D2C errno=3D3D2C h_errno=3D> >)=3D3D= >3B<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3Bassert(h)=3D3D3B<=3D3BBR>=3D3B&= >amp=3D3Bnbsp=3D> >=3D3D3Bret=3D3D
>=3D3B >=3D3Burn 0=3D3D3B<=3D3BB= >R>=3D3B}<=3D3BBR>=3D3B
>=3D> >=3D3B >=3D3B&=3D3Bnbsp=3D3D3B= ><=3D3BBR>=3D3B
>=3D3B >=3D3Bherror says "unkno=3D> >wn host".<= >=3D3BBR>=3D3B
>=3D3B >=3D3B<=3D3BBR>=3D3BStack is:<=3D3BBR&g= >t=3D> >=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&a= >mp=3D3Bnbsp=3D3D3B at ../=3D> >src/runtime/ex_frame/RTExFrame.m3:58<=3D3B= >BR>=3D3B#13 =3D3D
>=3D3B >=3D3B0=3D> >x0000000801a7f2b3 in RTHooks= >__Raise (M3_AJWxb1_ex=3D3D3DError accessing memor=3D> >y=3D3D
>=3D3B &= >gt=3D3B ad<=3D3BBR>=3D3Bdress 0x8000ffffd278: Bad address.<=3D> >=3D3= >BBR>=3D3B)<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&= >=3D3Bnbsp=3D3D3B =3D> >=3D3D
>=3D3B >=3D3Bat ../src/runtime/common/R= >THooks.m3:79<=3D3BBR>=3D3B#14=3D> > 0x000000080169c8d3 in IPError=3D3D<= >BR>>=3D3B >=3D3B__Die () at ../src/common=3D> >/IPError.m3:27<=3D3BBR= >>=3D3B#15 0x0000000801698a3e in IP__Ge=3D3D
>=3D3B &=3D> >gt=3D3BtHo= >stAddr (M3_BCxjPn__result=3D3D3DError accessing mem<=3D3BBR>=3D3Bory = >=3D> >address 0x8000fff=3D3D
>=3D3B >=3D3Bfd338: Bad address.<=3D3= >BBR>=3D3B)<=3D> >=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3= >B&=3D3Bnbsp=3D3D3B at ../src/POSIX=3D> >/IP.m3:=3D3D
>=3D3B >=3D3= >B82<=3D3BBR>=3D3B#16 0x00000008012133d0 in XShare=3D> >dMem__SameHost (= >M3_AQuuui_trsl=3D3D3DErro=3D3D
>=3D3B >=3D3Br accessing m<=3D> >= >=3D3BBR>=3D3Bemory address 0x8000ffffd4d8: Bad address.<=3D3BBR>=3D3B= >)<=3D3BB=3D> >R>=3D3B&=3D3Bnbsp=3D3D
>=3D3B >=3D3B=3D3D3B&= >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B=3D> > at ../src/xvbt/XSharedMem.m3:96&= >lt=3D3BBR>=3D3B#17 0x0000000801212a=3D3D
&g=3D> >t=3D3B >=3D3Bb7 in = >XSharedMem__InitXClient (M3_AQuuui_v=3D3D3DError accessing m=3D> ><=3D3BB= >R>=3D3Bemory add=3D3D
>=3D3B >=3D3Bress 0x8000ffffd648: Bad addres= >s=3D> >.<=3D3BBR>=3D3B)<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bn= >bsp=3D3D3B&=3D3Bnbsp=3D> >=3D3D3B at ../sr=3D3D
>=3D3B >=3D3Bc/xv= >bt/XSharedMem.m3:29<=3D3BBR>=3D3B#18 =3D> >0x0000000801211819 in XExten= >sions__InitXClie=3D3D
>=3D3B >=3D3Bnt (M3_AQuu=3D> >ui_xclient=3D3D3= >DError acce<=3D3BBR>=3D3Bssing memory address 0x8000ffffd7f8:=3D> > =3D= >3D
>=3D3B >=3D3BBad address.<=3D3BBR>=3D3B)<=3D3BBR>=3D3B&am= >p=3D3Bnbsp=3D> >=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B at ../src/x= >vbt/XExtensions.m3=3D3D
&=3D> >gt=3D3B >=3D3B:14<=3D3BBR>=3D3B#19 = >0x00000008012467a4 in XClientF__Connect (M=3D> >3_Bd56fi_inst=3D3D3D0x1879= >=3D3D
>=3D3B >=3D3Bb=3D3D2C<=3D3BBR>=3D3B&=3D3Bnbsp=3D> >=3D3= >D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B M3_AQuuui_trsl=3D3D3D0x6) at ..= >/src/xvb=3D> >t/XClie=3D3D
>=3D3B >=3D3BntF.m3:583<=3D3BBR>=3D3B= >---Type &=3D3Blt=3D3D3Bre=3D> >turn&=3D3Bgt=3D3D3B to continue=3D3D2C= > or q &=3D3Blt=3D3D3Breturn&=3D3Bg=3D3D >>>=3D3B >=3D3Bt= >=3D3D3B to quit---<=3D3BBR>=3D3B(More stack frames follow...)&=3D> >lt= >=3D3BBR>=3D3B(gdb)<=3D3BBR>=3D3B
>=3D3B >=3D3B<=3D3BBR>=3D= >3B(* return TR=3D> >UE if server and client are on same host *)<=3D3BBR&g= >t=3D3BPROCEDURE Sa=3D3D >>>=3D3B >=3D3BmeHost (trsl: XClient.T):= > BOOLEAN =3D3D3D<=3D3BBR>=3D3B&=3D3Bn=3D> >bsp=3D3D3B VAR<=3D3BBR&= >gt=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bn=3D3D
&g=3D> >t= >=3D3B >=3D3Bbsp=3D3D3B display&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&am= >p=3D3Bnbsp=3D3D3B=3D> >&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbs= >p=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D> >=3D3D
>=3D3B >=3D3B= >=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&a=3D> >= >mp=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3= >D3B&=3D3Bnbsp=3D> >=3D3D3B :=3D3D3D Di=3D3D
>=3D3B >=3D3BsplayHos= >t(trsl)=3D3D3B<=3D3BBR>=3D3B&=3D> >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3= >D3B&=3D3Bnbsp=3D3D3B displayAddr: IP.Address=3D3D3B&l=3D> >t=3D3BB=3D3D<= >BR>>=3D3B >=3D3BR>=3D3B&=3D3Bnbsp=3D3D3B BEGIN<=3D3BBR>=3D3B&a= >mp=3D3B=3D> >nbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B IF display= > =3D3D3D NIL THEN RETURN=3D> >=3D3D
>=3D3B >=3D3B TRUE=3D3D3B END=3D= >3D3B<=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D> >=3D3Bnbsp=3D3D3B&= >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B TRY<=3D3BBR>=3D3B&=3D3Bnbsp=3D>= > >=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&= >=3D3Bnbsp=3D3D3B IF=3D3D=3D> >
>=3D3B >=3D3B NOT IP.GetHostByName(di= >splay=3D3D2C displayAddr) THEN RETUR=3D> >N FALSE=3D3D3B END=3D3D3B<=3D3B= >B=3D3D
>=3D3B >=3D3BR>=3D3B&=3D3Bnbsp=3D3D3B&=3D> >=3D3Bnbsp= >=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B RETURN = >display=3D> >Addr =3D3D3D IP.GetHos=3D3D
>=3D3B >=3D3BtAddr()=3D3D3B= ><=3D3BBR>=3D3B&=3D3Bnb=3D> >sp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnb= >sp=3D3D3B EXCEPT<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3=3D> >B&=3D3Bnbsp= >=3D3D3B&=3D3Bnbsp=3D3D3B |=3D3D
>=3D3B >=3D3B IP.Error =3D3D3D&am= >p=3D> >=3D3Bgt=3D3D3B RETURN FALSE=3D3D3B<=3D3BBR>=3D3B&=3D3Bnbsp=3D= >3D3B&=3D3Bnbsp=3D3D3B&=3D> >amp=3D3Bnbsp=3D3D3B END=3D3D3B<=3D3BBR>= >=3D3B&=3D3B=3D3D
>=3D3B >=3D3Bnbsp=3D3D3B =3D> >END SameHost=3D3D= >3B<=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>= >=3D> >=3D3B
>=3D3B >=3D3BThoughts?<=3D3BBR>=3D3B
>=3D3B >= >=3D3B&=3D3Bnbsp=3D3D3=3D> >B<=3D3BBR>=3D3B
>=3D3B >=3D3B<= >=3D3BBR>=3D3BPerhaps my network isn't setu=3D> >p well=3D3D2C like I shou= >ld add the local mach=3D3D
>=3D3B >=3D3Bine to /etc=3D> >/hosts.<= >=3D3BBR>=3D3BI think this can be made to fail gracefully though.<=3D> >= >=3D3BB=3D3D
>=3D3B >=3D3BR>=3D3BIt seems like it has nothing to do= > with AMD6=3D> >4_FREEBSD=3D3D2C but could have t=3D3D
>=3D3B >=3D3B= >o do with FreeBSD.<=3D3B=3D> >BR>=3D3B
>=3D3B >=3D3B<=3D3BBR&g= >t=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
&g=3D> >t=3D3B >=3D3BSeem= >s like SocketPosix has nearly the exact same code but appear=3D> >s<=3D3B= >BR>=3D3Bmore f=3D3D
>=3D3B >=3D3Borgiving.. IOError instead of Fat= >a=3D> >l?<=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3= >BBR>=3D3B
>=3D3B &=3D> >gt=3D3B<=3D3BBR>=3D3BSocketPosix.m3:<= >=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D3Bnbs=3D> >p=3D3D3B<=3D3BBR>= >=3D3B
>=3D3B >=3D3B<=3D3BBR>=3D3BPROCEDURE GetHostAddr ()=3D> >:= > Address<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B RAISES {OSError.E} =3D3D3D&l= >t=3D3BBR=3D3D=3D> >
>=3D3B >=3D3B>=3D3B&=3D3Bnbsp=3D3D3B VAR<= >=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B&a=3D> >mp=3D3Bnbsp=3D3D3B&=3D3Bnbsp= >=3D3D3B host : ARRAY [0..255] OF CHAR=3D3D3B<=3D3B=3D3D<=3D> >BR>>=3D3B= > >=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D= >3D3B in=3D> >fo : Unetdb.struct_hostent_star=3D3D3B<=3D3BBR>=3D3B&= >=3D3Bnbsp=3D3D
>=3D3B =3D> >>=3D3B=3D3D3B&=3D3Bnbsp=3D3D3B&=3D= >3Bnbsp=3D3D3B ua&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D> >=3D3D3B : Uin.struct= >_in_addr=3D3D3B<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B =3D3D
>=3D3B=3D>= > > >=3D3BBEGIN<=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&= >amp=3D3Bnbsp=3D3D3B =3D> >IF Unix.gethostname (ADR (host[0])=3D3D2C BYT=3D3= >D
>=3D3B >=3D3BESIZE (host)=3D> >) # 0 THEN<=3D3BBR>=3D3B&=3D= >3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&am=3D> >p=3D3Bnbsp=3D= >3D3B&=3D3Bnbsp=3D3D3B IOError =3D3D
>=3D3B >=3D3B(Unexpected)=3D3= >D3B=3D> ><=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3= >Bnbsp=3D3D3B END=3D3D3B<=3D> >=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D= >3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3=3D> >B info :=3D3D3D U= >netdb.gethostbyname (ADR (host[0]))=3D3D3B<=3D3B=3D3D
>=3D3B =3D> >&= >gt=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D= >3B IF info =3D3D3=3D> >D NIL THEN IOError (Unexpected)=3D3D3B EN=3D3D
&g= >t=3D3B >=3D3BD=3D3D3B<=3D3BBR&g=3D> >t=3D3B&=3D3Bnbsp=3D3D3B&=3D3= >Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B &=3D3Blt=3D3D3B* ASSERT=3D> > info.h_le= >ngth &=3D3Blt=3D3D3B=3D3D3D BYT=3D3D
>=3D3B >=3D3BESIZE (Address)= > *=3D> >&=3D3Bgt=3D3D3B<=3D3BBR>=3D3B
>=3D3B >=3D3B&=3D3Bn= >bsp=3D3D3B&=3D3Bnbsp=3D3D=3D> >3B&=3D3Bnbsp=3D3D3B ua :=3D3D3D LOOPHO= >LE(info.h_addr_list=3D3D2C<=3D3BBR>=3D3B&a=3D> >mp=3D3Bnbsp=3D3D3B&= >=3D3Bn=3D3D
>=3D3B >=3D3Bbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnb= >=3D> >sp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B= >&=3D3Bnbsp=3D3D3B&=3D> >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3B= >nbsp=3D3D
>=3D3B >=3D3B=3D3D3B&=3D3Bnbsp=3D> >=3D3D3B&=3D3Bnbs= >p=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&=3D= >> >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B UNTRACED REF UN=3D3D
>=3D3B &g= >t=3D3BTRACED REF =3D> >Uin.struct_in_addr)^^=3D3D3B<=3D3BBR>=3D3B&= >=3D3Bnbsp=3D3D3B&=3D3Bnbsp=3D3D3B&am=3D> >p=3D3Bnbsp=3D3D3B RETURN LOOP= >=3D3D
>=3D3B >=3D3BHOLE (ua.s_addr=3D3D2C Address)=3D> >=3D3D3B<= >=3D3BBR>=3D3B&=3D3Bnbsp=3D3D3B END GetHostAddr=3D3D3B<=3D3BBR>=3D3= >B
&=3D> >gt=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
>= >=3D3B >=3D3B&=3D3Bnbsp=3D3D3B=3D> ><=3D3BBR>=3D3B
>=3D3B >= >=3D3BIt is again disappointing to see such code d=3D> >uplication.<=3D3BB= >R>=3D3B
>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B= > >>>=3D3B >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
>=3D3B >= >=3D3BI guess&=3D3B=3D> >nbsp=3D3D3BSameHost can duplicate the logic to p= >redict the error state =3D3D >>>=3D3B >=3D3Band return false&= >=3D3Bnbsp=3D3D3Bupon error?<=3D3BBR>=3D3B
=3D> >>=3D3B >=3D3BDup= >licating the logic for a third time. :(<=3D3BBR>=3D3B
&g=3D> >t=3D3B= > >=3D3B&=3D3Bnbsp=3D3D3B<=3D3BBR>=3D3B
>=3D3B >=3D3B<=3D3= >BBR>=3D3B&am=3D> >p=3D3Bnbsp=3D3D3B- Jay<=3D3BBR>=3D3B<=3D3BBR>= >=3D3B<=3D3B/body>=3D3B
>=3D3B &=3D> >gt=3D3B<=3D3B/html>=3D3B= >=3D3D
>=3D3B >=3D3B
>=3D3B >=3D3B--_9e67232c-a064=3D> >-417d-= >879e-227a77e310f9_--

> >=3D> >> >--_b00371fe-730b-4981= >-9051-a874361296d7_--= > >--_b0c10337-0e1c-414e-aae5-e611dcd4be8a_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >PPC_LINUX not PPC_DARWIN.
>I think.
>And at one point AMD64_LINUX (same machine as AMD64_FREEBSD=2C multiboot).<= >BR>I think I tested I386_OPENBSD Juno too and it worked=2C
I don't remem= >ber. Oh=2C but that was in a VM=2C so different networking setup.
>
This is Trestle startup=2C seeing if there might
be shared memory av= >ailable between the X client and server.
>
If $DISPLAY is set=2C to specify the server=2C it wants to compare
t= >hat against "current"=2C the client.
You know=2C if I set DISPLAY=3D:0.0= > or localhost:0.0=2C don't penalize perf=2C
but if it really is remote= >=2C then do penalize perf.
>
/Something/ like that.
>I hardly read the code..
>
 =3B- Jay

>=3B To: jay.krell at cornell.edu
>=3B Date: M= >on=2C 12 Jan 2009 01:06:30 -0800
>=3B From: mika at async.caltech.edu
= >>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] Juno (X) = >networking problem on AMD64_FREEBSD
>=3B
>=3B Jay=2C
>=3B <= >BR>>=3B I think the problem here is actually in the caller. Why does a>>=3B caller need "GetHostAddr()"? It is probably doing this for the
&= >gt=3B purpose of calling listen() or some such thing. What the caller
&g= >t=3B probably *really* wants is INADDR_ANY=2C and not the IP address of
= >>=3B some arbitrarily chosen interface on the host.
>=3B
>=3B = >I'm guessing it works on the Mac because the Mac libraries do
>=3B som= >ething complicated when you ask for the host's name (i.e.=2C they
>=3B= > somehow generate a hostname that always maps to the IP address of
>= >=3B an interface on the computer).
>=3B
>=3B Mika
>=3B
= >>=3B Jay writes:
>=3B >=3B--_b00371fe-730b-4981-9051-a874361296d7_= >
>=3B >=3BContent-Type: text/plain=3B charset=3D"iso-8859-1"
>= >=3B >=3BContent-Transfer-Encoding: quoted-printable
>=3B >=3B
&= >gt=3B >=3B
>=3B >=3BDo you know the right way?
>=3B >=3B=3D= >20
>=3B >=3BPPC_LINUX "just worked"=3D2C and I can check Solaris and= > Darwin.
>=3B >=3B=3D20
>=3B >=3BI don't want to edit /etc/ho= >sts -- I use DHCP.
>=3B >=3BThough DHCP has been bothering me -- onl= >y for some of my machines do names =3D
>=3B >=3Bresolve=3D2C so I en= >d using IP addresses=3D2C which change sometimes=3D2C and I l=3D
>=3B = >>=3Boop over them running ssh to all of them and "see what I get"=3D2C no= >t ideal.
>=3B >=3B=3D20
>=3B >=3B - Jay>=3B To: jay.krell at c= >ornell.edu>=3B Date: Sun=3D2C 11 Jan 2009 08:02:18 -0800>=3B=3D
>= >=3B >=3B From: mika at async.caltech.edu>=3B CC: m3devel at elegosoft.com>= >=3B Subject: Re: [M3d=3D
>=3B >=3Bevel] Juno (X) networking problem = >on AMD64_FREEBSD>=3B >=3B This is a screwy thin=3D
>=3B >=3Bg in= > Modula-3. A bug I would call it.>=3B >=3B I've noticed a lot of networ= >king M=3D
>=3B >=3B3 programs don't work right unless>=3B the retu= >rn value of Unix's "hostname" m=3D
>=3B >=3Baps to a real IP address= > via>=3B gethostbyname. I accomplish it in practice by=3D
>=3B >= >=3B adding my hostname>=3B to /etc/hosts.>=3B >=3B This is obviously = >not the right way =3D
>=3B >=3Bto fix it... >=3B >=3B Mika>=3B= > >=3B Jay writes:>=3B >=3B--_9e67232c-a064-417d-879e-227a77e31=3D
= >>=3B >=3B0f9_>=3B >=3BContent-Type: text/plain=3D3B charset=3D3D"is= >o-8859-1">=3B >=3BContent-Transfe=3D
>=3B >=3Br-Encoding: quoted= >-printable>=3B >=3B>=3B >=3B>=3B >=3BHi. Unix network programmi= >ng question.=3D
>=3B >=3B.>=3B >=3BAMD64_FREEBSD:>=3B >=3B$D= >ISPLAY is set to point back to Cygwin host.It works =3D
>=3B >=3Bfor= > PPC_LINUX.>=3B >=3B[jay at fbsdamd64a /cm3/bin]$ ./Juno>=3B >=3B*****= >* runtime error:*=3D
>=3B >=3B** Exception "IPError.FatalError" not = >in RAISES li=3D3D>=3B >=3Bst*** file "../src/=3D
>=3B >=3Bcommon= >/IPError.m3"=3D3D2C line 27***>=3B >=3BAbort trap: 6 (core dumped)[jay@= >fbsdam=3D
>=3B >=3Bd64a /cm3/bin]$>=3B >=3BIP.m3:>=3B >=3B= >=3D3D20>=3B >=3BPROCEDURE GetHostAddr(): Address =3D3D3D V=3D
>=3B= > >=3BAR hname: ARRAY [0..255] OF CHAR=3D3D3B =3D3D>=3B >=3B BEGIN LOC= >K mu DO IF Unix.getho=3D
>=3B >=3Bstname(ADR(hname[0])=3D3D2C BYTESI= >ZE(hna=3D3D>=3B >=3Bme)) # 0 THEN IPError.Die ()=3D3D=3D
>=3B >= >=3B3B END=3D3D3B VAR h :=3D3D3D Unetdb.g=3D3D>=3B >=3Bethostbyname(ADR(= >hname[0]))=3D3D3B BEG=3D
>=3B >=3BIN IF h =3D3D3D NIL THEN IPError.D= >ie()=3D3D>=3B >=3B=3D3D3B END=3D3D3B RETURN GetAddress(=3D
>=3B &g= >t=3Bh)=3D3D3B END=3D3D3B END=3D3D3B END GetHos=3D3D>=3B >=3BtAddr=3D3D3= >B>=3B >=3BPROCEDURE GetAddress=3D
>=3B >=3B (ent: Unetdb.struct_= >hostent_star): Address =3D3D3D VAR ua=3D3D>=3B >=3B: Uin.struct_=3D
= >>=3B >=3Bin_addr=3D3D3B BEGIN <=3B* ASSERT ent.h_length <=3B=3D3D3D= > BYTESIZE(Addr=3D3D>=3B >=3Bess) *>=3B=3D
>=3B >=3B ua :=3D3D3= >D LOOPHOLE(ent.h_addr_list=3D3D2C UNTRACED =3D3D>=3B >=3BREF UNTRACED R= >EF Ui=3D
>=3B >=3Bn.struct_in_addr)^^=3D3D3B RETURN LOOPHOLE(ua.s_ad= >dr=3D3D2C A=3D3D>=3B >=3Bddress)=3D3D3B=3D
>=3B >=3B END GetAddr= >ess=3D3D3B>=3B >=3B=3D3D20>=3B >=3Bgethostbyname is failing.>=3B = >>=3B=3D3D20>=3B >=3BAnalogou=3D
>=3B >=3Bs C code also fails:&= >gt=3B >=3B=3D3D20>=3B >=3B[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c#includ= >e=3D
>=3B >=3B <=3Bassert.h>=3B#include <=3Bnetdb.h>=3B#i=3D= >3D>=3B >=3Bnclude <=3Bstdio.h>=3B#include <=3Berrno.h>=3Btype= >=3D
>=3B >=3Bdef struct hostent hostent_t=3D3D3B>=3B >=3B=3D3D20= >>=3B >=3Bint main(){ char hostname[200]=3D
>=3B >=3B=3D3D3B host= >ent_t* h=3D3D3B int i=3D3D3B>=3B >=3B i =3D3D3D gethostname(hostname=3D= >3D2C 200=3D
>=3B >=3B)=3D3D3B assert(i =3D3D3D=3D3D3D 0)=3D3D3B prin= >tf("hostna=3D3D>=3B >=3Bme: %s\n"=3D3D2C hostn=3D
>=3B >=3Bame)= >=3D3D3B h =3D3D3D gethostbyname(hostname)=3D3D3B herror("foo")=3D3D3B=3D3D&= >gt=3B >=3B pri=3D
>=3B >=3Bntf("%p %d %d\n"=3D3D2C h=3D3D2C errno= >=3D3D2C h_errno)=3D3D3B assert(h)=3D3D3B return=3D
>=3B >=3B 0=3D3D3= >B}>=3B >=3B=3D3D20>=3B >=3Bherror says "unknown host".>=3B >=3B= >Stack is:>=3B >=3B at ../src/run=3D
>=3B >=3Btime/ex_frame/RTExF= >rame.m3:58#13 0x0000000801a7f2b3 in RTH=3D3D>=3B >=3Books__Raise=3D
= >>=3B >=3B (M3_AJWxb1_ex=3D3D3DError accessing memory address 0x8000ffff= >d278: =3D3D>=3B >=3BBad=3D
>=3B >=3B address.) at ../src/runtime= >/common/RTHooks.m3:79#14 0x000000080169c8=3D3D>=3B >=3B=3D
>=3B &g= >t=3Bd3 in IPError__Die () at ../src/common/IPError.m3:27#15 0x0000000801698= >a3e =3D
>=3B >=3B=3D3D>=3B >=3Bin IP__GetHostAddr (M3_BCxjPn__re= >sult=3D3D3DError accessing memory addr=3D
>=3B >=3Bess 0x80=3D3D>= >=3B >=3B00ffffd338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x00000=3D<= >BR>>=3B >=3B008012133d0=3D3D>=3B >=3B in XSharedMem__SameHost (M3_A= >Quuui_trsl=3D3D3DError accessi=3D
>=3B >=3Bng memory address 0=3D3D&= >gt=3B >=3Bx8000ffffd4d8: Bad address.) at ../src/xvbt/XShare=3D
>=3B= > >=3BdMem.m3:96#17 0x000000=3D3D>=3B >=3B0801212ab7 in XSharedMem__In= >itXClient (M3_AQuuu=3D
>=3B >=3Bi_v=3D3D3DError accessing memory=3D3= >D>=3B >=3B address 0x8000ffffd648: Bad address.) =3D
>=3B >=3Bat= > ../src/xvbt/XSharedMem.m3:29#1=3D3D>=3B >=3B8 0x0000000801211819 in XE= >xtensions_=3D
>=3B >=3B_InitXClient (M3_AQuuui_xclient=3D3D3DError= >=3D3D>=3B >=3B accessing memory address 0x=3D
>=3B >=3B8000ffffd= >7f8: Bad address.) at ../src/xvbt/X=3D3D>=3B >=3BExtensions.m3:14#19 0x= >000=3D
>=3B >=3B00008012467a4 in XClientF__Connect (M3_Bd56fi_inst= >=3D3D>=3B >=3B=3D3D3D0x1879b=3D3D2C M=3D
>=3B >=3B3_AQuuui_trsl= >=3D3D3D0x6) at ../src/xvbt/XClientF.m3:583---Typ=3D3D>=3B >=3Be <=3Br= >eturn>=3B=3D
>=3B >=3B to continue=3D3D2C or q <=3Breturn>=3B = >to quit---(More stack frames follow=3D3D>=3B >=3B..=3D
>=3B >=3B= >.)(gdb)>=3B >=3B(* return TRUE if server and client are on same host *)= >PROCEDURE =3D
>=3B >=3BSameHost (=3D3D>=3B >=3Btrsl: XClient.T):= > BOOLEAN =3D3D3D VAR display :=3D3D3D DisplayH=3D
>=3B >=3B=3D3D>= >=3B >=3Bost(trsl)=3D3D3B displayAddr: IP.Address=3D3D3B BEGIN IF display = >=3D3D3D NI=3D
>=3B >=3BL THE=3D3D>=3B >=3BN RETURN TRUE=3D3D3B E= >ND=3D3D3B>=3B >=3B TRY IF NOT IP.GetHostByName(displ=3D
>=3B >= >=3Bay=3D3D2C displayAddr) THEN RETURN FA=3D3D>=3B >=3BLSE=3D3D3B END=3D= >3D3B RETURN displayAd=3D
>=3B >=3Bdr =3D3D3D IP.GetHostAddr()=3D3D3B= > EXCEPT =3D3D>=3B >=3B| IP.Error =3D3D3D>=3B RETURN FALSE=3D
>= >=3B >=3B=3D3D3B END=3D3D3B END SameHost=3D3D3B>=3B >=3B=3D3D20>=3B = >>=3BThoughts?>=3B >=3B=3D3D20>=3B >=3BPerhaps my n=3D
>=3B &= >gt=3Betwork isn't setup well=3D3D2C like I should add the local machine =3D= >3D>=3B >=3Bto /=3D
>=3B >=3Betc/hosts.I think this can be made t= >o fail gracefully though.It seems l=3D3D>=3B=3D
>=3B >=3B >=3Bik= >e it has nothing to do with AMD64_FREEBSD=3D3D2C but could have to do wit= >=3D
>=3B >=3Bh Fr=3D3D>=3B >=3BeeBSD.>=3B >=3B=3D3D20>=3B = >>=3BSeems like SocketPosix has nearly the exact same=3D
>=3B >=3B = >code but appearsmore forgi=3D3D>=3B >=3Bving.. IOError instead of Fatal= >?>=3B >=3B=3D3D20>=3B =3D
>=3B >=3B>=3BSocketPosix.m3:>=3B= > >=3B=3D3D20>=3B >=3BPROCEDURE GetHostAddr (): Address RAISES {OSErro= >=3D
>=3B >=3Br.E} =3D3D3D VAR host : AR=3D3D>=3B >=3BRAY [0..255= >] OF CHAR=3D3D3B info : Unetdb.struc=3D
>=3B >=3Bt_hostent_star=3D3D= >3B ua : U=3D3D>=3B >=3Bin.struct_in_addr=3D3D3B BEGIN IF Unix.gethos=3D= >
>=3B >=3Btname (ADR (host[0])=3D3D2C BYTESI=3D3D>=3B >=3BZE (ho= >st)) # 0 THEN IOError (Unexpect=3D
>=3B >=3Bed)=3D3D3B END=3D3D3B>= >=3B >=3B info :=3D3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3D3B =3D>>=3B >=3BIF info =3D3D3D NIL TH=3D3D>=3B >=3BEN IOError (Unexpecte= >d)=3D3D3B END=3D3D3B <=3B* ASSERT i=3D
>=3B >=3Bnfo.h_length <= >=3B=3D3D3D BYTESIZE =3D3D>=3B >=3B(Address) *>=3B>=3B >=3B ua := >=3D3D3D LOOPHOLE(info.=3D
>=3B >=3Bh_addr_list=3D3D2C UNTRACED REF U= >NT=3D3D>=3B >=3BRACED REF Uin.struct_in_addr)^^=3D3D3B=3D
>=3B >= >=3B RETURN LOOPHOLE (ua.s_addr=3D3D2C Address=3D3D>=3B >=3B)=3D3D3B END= > GetHostAddr=3D3D3B>=3B =3D
>=3B >=3B>=3B=3D3D20>=3B >=3B=3D= >3D20>=3B >=3BIt is again disappointing to see such code duplication.>= >=3B >=3B=3D
>=3B >=3B=3D3D20>=3B >=3B=3D3D20>=3B >=3BI gue= >ss SameHost can duplicate the logic to predict the err=3D
>=3B >=3Bo= >r state and ret=3D3D>=3B >=3Burn false upon error?>=3B >=3BDuplicat= >ing the logic for a t=3D
>=3B >=3Bhird time. :(>=3B >=3B=3D3D20&= >gt=3B >=3B - Jay=3D3D>=3B >=3B>=3B >=3B--_9e67232c-a064-417d-879e= >-227a77e31=3D
>=3B >=3B0f9_>=3B >=3BContent-Type: text/html=3D3B= > charset=3D3D"iso-8859-1">=3B >=3BContent-Transfer=3D
>=3B >=3B-= >Encoding: quoted-printable>=3B >=3B>=3B >=3B<=3Bhtml>=3B>=3B = >>=3B<=3Bhead>=3B>=3B >=3B<=3Bstyle>=3B>=3B >=3B.hmmessage= > P>=3B =3D
>=3B >=3B>=3B{>=3B >=3Bmargin:0px=3D3D3B>=3B &g= >t=3Bpadding:0px>=3B >=3B}>=3B >=3Bbody.hmmessage>=3B >=3B{>= >=3B >=3Bfont-size: 10=3D
>=3B >=3Bpt=3D3D3B>=3B >=3Bfont-famil= >y:Verdana>=3B >=3B}>=3B >=3B<=3B/style>=3B>=3B >=3B<=3B/h= >ead>=3B>=3B >=3B<=3Bbody class=3D3D3D'h=3D
>=3B >=3Bmmessage= >'>=3B>=3B >=3BHi. Unix network programming question..<=3BBR>=3B&g= >t=3B >=3B<=3BBR>=3BAMD64_FREEBS=3D
>=3B >=3BD:<=3BBR>=3B&g= >t=3B >=3B<=3BBR>=3B$DISPLAY is set to point back to Cygwin host.<= >=3BBR>=3BIt works for =3D
>=3B >=3BPPC_LINUX=3D3D>=3B >=3B.<= >=3BBR>=3B>=3B >=3B<=3BBR>=3B[jay at fbsdamd64a /cm3/bin]$ ./Juno<= >=3BBR>=3B>=3B >=3B<=3BBR>=3B***<=3B=3D
>=3B >=3BBR>=3B= >*** runtime error:<=3BBR>=3B***&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&= >=3Bnbsp=3D3D3B Exception "IPE=3D
>=3B >=3B=3D3D>=3B >=3Brror.Fat= >alError" not in RAISES list<=3BBR>=3B***&=3Bnbsp=3D3D3B&=3Bnbsp= >=3D3D3B&=3Bnbsp=3D
>=3B >=3B=3D3D3B file "..=3D3D>=3B >=3B/sr= >c/common/IPError.m3"=3D3D2C line 27<=3BBR>=3B***<=3BBR>=3B>=3B &g= >t=3B<=3BBR>=3BA=3D
>=3B >=3Bbort trap: 6 (core dumped)<=3BBR&g= >t=3B[jay at fbsdamd64a /cm3/bin]$<=3BBR>=3B>=3B >=3B<=3BBR>=3BIP.m= >3:<=3BB=3D
>=3B >=3BR>=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR= >>=3B>=3B >=3BPROCEDURE GetHostAddr(): Address =3D3D3D<=3BBR>=3B&a= >mp=3Bnbsp=3D3D3B =3D
>=3B >=3BVAR hname: ARRAY [0..255] =3D3D>=3B = >OF CHAR=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B BEGIN<=3BBR>=3B&=3Bnb= >sp=3D3D=3D
>=3B >=3B3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B LOCK mu D= >O<=3BBR>=3B&=3Bnbs=3D3D>=3B >=3Bp=3D3D3B&=3Bnbsp=3D3D3B&= >=3Bnbsp=3D3D3B&=3Bn=3D
>=3B >=3Bbsp=3D3D3B&=3Bnbsp=3D3D3B IF U= >nix.gethostname(ADR(hname[0])=3D3D2C B=3D3D>=3B >=3BYTESIZE(hn=3D
&g= >t=3B >=3Bame)) # 0 THEN<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B= >&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D
>= >=3B >=3B=3D3D>=3B >=3B=3D3D3B&=3Bnbsp=3D3D3B IPError.Die ()=3D3D3B= ><=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B=3D
= >>=3B >=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B E=3D3D>=3B >=3BND=3D3= >D3B<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&= >=3Bnbsp=3D
>=3B >=3B=3D3D3B&=3Bnbsp=3D3D3B VAR h :=3D3D3D Unetdb.= >gethost=3D3D>=3B >=3Bbyname(ADR(hname[0]))=3D3D3B=3D
>=3B >=3B B= >EGIN<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&am= >p=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3B=3D3D>=3B >=3Bnbsp=3D3D3=3D
= >>=3B >=3BB&=3Bnbsp=3D3D3B IF h =3D3D3D NIL THEN IPError.Die()=3D3D3B= > END=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bn=3D
>=3B >=3Bbsp= >=3D3D>=3B >=3B=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D= >3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B RETURN Get=3D
>=3B >=3BAddr= >ess(h)=3D3D3B<=3BBR>=3B&=3Bnbs=3D3D>=3B >=3Bp=3D3D3B&=3Bnbsp= >=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B=3D
>=3B = >>=3B END=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bn= >bsp=3D3D3B END=3D3D>=3B >=3B=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B EN= >=3D
>=3B >=3BD GetHostAddr=3D3D3B<=3BBR>=3B>=3B >=3B<=3BBR= >>=3BPROCEDURE GetAddress (ent: Unetdb.struct_hoste=3D
>=3B >=3Bnt_= >star): Address =3D3D3D<=3BBR>=3B=3D3D>=3B >=3B&=3Bnbsp=3D3D3B VA= >R ua: Uin.struct_in_addr=3D3D3B=3D
>=3B >=3B<=3BBR>=3B&=3Bnbs= >p=3D3D3B BEGIN<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D>=3B >=3B= >=3D3D3B&=3Bnbsp=3D3D3B &=3Blt=3D3D3B* ASSE=3D
>=3B >=3BRT ent.= >h_length &=3Blt=3D3D3B=3D3D3D BYTESIZE(Address) *&=3Bgt=3D3D3B=3D3D&g= >t=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3D=3D
>=3B >=3B3B&=3Bnbsp= >=3D3D3B&=3Bnbsp=3D3D3B ua :=3D3D3D LOOPHOLE(ent.h_addr_list=3D3D2C<=3B= >BR>=3B&=3Bnbsp=3D3D>=3B=3D
>=3B >=3B >=3B=3D3D3B&=3Bnbsp= >=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D= >3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D=3D
>=3B >=3B3B&=3Bnbsp=3D3= >D3B&=3Bnbsp=3D3D3B=3D3D>=3B >=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B= >&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D
>=3B >=3B=3D3D3B&= >amp=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B UN= >=3D3D>=3B >=3BTRACED REF UNTRACED R=3D
>=3B >=3BEF Uin.struct_in= >_addr)^^=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbs= >p=3D3D>=3B >=3B=3D3D3B RETUR=3D
>=3B >=3BN LOOPHOLE(ua.s_addr=3D= >3D2C Address)=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B END GetAddress=3D3D3B&= >lt=3B=3D
>=3B >=3B=3D3D>=3B >=3BBR>=3B>=3B >=3B&=3Bnbsp= >=3D3D3B<=3BBR>=3B>=3B >=3Bgethostbyname is failing.<=3BBR>=3B&g= >t=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3D3B=3D
>=3B >=3B<=3BBR>= >=3B>=3B >=3BAnalogous C code also fails:<=3BBR>=3B>=3B >=3B&= >=3Bnbsp=3D3D3B<=3BBR>=3B>=3B >=3B<=3BBR>=3B[jay at fbsdamd=3D
&= >gt=3B >=3B64a /cm3/bin]$ cat ~/5.c<=3BBR>=3B#include &=3Blt=3D3D3B= >assert.h&=3Bgt=3D3D3B<=3BB=3D3D>=3B >=3BR>=3B#inc=3D
>=3B &= >gt=3Blude &=3Blt=3D3D3Bnetdb.h&=3Bgt=3D3D3B<=3BBR>=3B#include &am= >p=3Blt=3D3D3Bstdio.h&=3Bgt=3D3D3B<=3BBR>=3B#includ=3D
>=3B >= >=3Be =3D3D>=3B >=3B&=3Blt=3D3D3Berrno.h&=3Bgt=3D3D3B<=3BBR>= >=3Btypedef struct hostent hostent_t=3D3D3B<=3BBR=3D
>=3B >=3B>= >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B>=3B >=3Bint main()<= >=3BBR>=3B{<=3BBR>=3B&=3Bnbsp=3D3D3Bchar hostname[200]=3D3D3B<=3B= >B=3D
>=3B >=3BR>=3B&=3Bnbsp=3D3D3Bhostent_t* h=3D3D3B=3D3D>= >=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3D3Bint i=3D3D3B<=3BBR>=3B>=3B = >>=3B&=3Bnbsp=3D3D3=3D
>=3B >=3BBi =3D3D3D gethostname(hostname= >=3D3D2C 200)=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3Bassert(i =3D3D3D=3D3D=3D= >
>=3B >=3B3D 0)=3D3D>=3B >=3B=3D3D3B<=3BBR>=3B&=3Bnbsp=3D= >3D3Bprintf("hostname: %s\n"=3D3D2C hostname)=3D3D3B<=3BB=3D
>=3B >= >=3BR>=3B&=3Bnbsp=3D3D3Bh =3D3D3D get=3D3D>=3B >=3Bhostbyname(hostn= >ame)=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3Bherror(=3D
>=3B >=3B"foo"= >)=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3Bprintf("%p %=3D3D>=3B >=3Bd %d\= >n"=3D3D2C h=3D3D2C errno=3D3D2C h=3D
>=3B >=3B_errno)=3D3D3B<=3BBR= >>=3B&=3Bnbsp=3D3D3Bassert(h)=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3Bret= >=3D3D>=3B >=3Burn 0=3D3D3B<=3BB=3D
>=3B >=3BR>=3B}<=3BBR&g= >t=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B>=3B >=3Bherror says "= >unknown host".<=3BBR>=3B>=3B >=3B<=3BBR>=3BStack is:<=3B=3DR>>=3B >=3BBR>=3B>=3B >=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&am= >p=3Bnbsp=3D3D3B at ../src/runtime/ex_frame/RTExFrame.m=3D
>=3B >=3B3= >:58<=3BBR>=3B#13 =3D3D>=3B >=3B0x0000000801a7f2b3 in RTHooks__Raise= > (M3_AJWxb1_ex=3D3D3DEr=3D
>=3B >=3Bror accessing memory=3D3D>=3B = >>=3B ad<=3BBR>=3Bdress 0x8000ffffd278: Bad address.<=3BBR>=3B)<= >=3BBR=3D
>=3B >=3B>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bn= >bsp=3D3D3B =3D3D>=3B >=3Bat ../src/runtime/common/RTHooks.m3:7=3D
&g= >t=3B >=3B9<=3BBR>=3B#14 0x000000080169c8d3 in IPError=3D3D>=3B >= >=3B__Die () at ../src/common/IPErr=3D
>=3B >=3Bor.m3:27<=3BBR>= >=3B#15 0x0000000801698a3e in IP__Ge=3D3D>=3B >=3BtHostAddr (M3_BCxjPn__= >res=3D
>=3B ult=3D3D3DError accessing mem<=3BBR>=3Bory address 0x8= >000fff=3D3D>=3B >=3Bfd338: Bad addres=3D
>=3B >=3Bs.<=3BBR>= >=3B)<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B at= > ../src/POSIX/IP.m3:=3D3D>=3B >=3B82<=3BBR=3D
>=3B >=3B>=3B#= >16 0x00000008012133d0 in XSharedMem__SameHost (M3_AQuuui_trsl=3D3D3DErro=3D= >3D=3D
>=3B >=3B>=3B >=3Br accessing m<=3BBR>=3Bemory address= > 0x8000ffffd4d8: Bad address.<=3BBR>=3B)<=3BBR>=3B&=3Bnbs=3D
= >>=3B >=3Bp=3D3D>=3B >=3B=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B= > at ../src/xvbt/XSharedMem.m3:96<=3BBR>=3B#17 0x0=3D
>=3B >=3B00= >0000801212a=3D3D>=3B >=3Bb7 in XSharedMem__InitXClient (M3_AQuuui_v=3D3= >D3DError acc=3D
>=3B >=3Bessing m<=3BBR>=3Bemory add=3D3D>=3B = >>=3Bress 0x8000ffffd648: Bad address.<=3BBR>=3B)<=3BBR>=3B&=3B= >nbsp=3D
>=3B >=3B=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B at ../s= >r=3D3D>=3B >=3Bc/xvbt/XSharedMem.m3:29<=3BBR>=3B#18 0x00=3D
>= >=3B >=3B00000801211819 in XExtensions__InitXClie=3D3D>=3B >=3Bnt (M3_= >AQuuui_xclient=3D3D3DErr=3D
>=3B >=3Bor acce<=3BBR>=3Bssing memo= >ry address 0x8000ffffd7f8: =3D3D>=3B >=3BBad address.<=3BBR>=3B)<= >=3BBR>=3B=3D
>=3B >=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bn= >bsp=3D3D3B at ../src/xvbt/XExtensions.m3=3D3D>=3B >=3B:14<=3BBR>=3B= >#1=3D
>=3B >=3B9 0x00000008012467a4 in XClientF__Connect (M3_Bd56fi_= >inst=3D3D3D0x1879=3D3D>=3B >=3Bb=3D
>=3B >=3B=3D3D2C<=3BBR>= >=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B M3_AQuuui_trsl=3D= >3D3D0x6) at ../src/x=3D
>=3B >=3Bvbt/XClie=3D3D>=3B >=3BntF.m3:5= >83<=3BBR>=3B---Type &=3Blt=3D3D3Breturn&=3Bgt=3D3D3B to continue= >=3D3D2=3D
>=3B >=3BC or q &=3Blt=3D3D3Breturn&=3Bg=3D3D>=3B = >>=3Bt=3D3D3B to quit---<=3BBR>=3B(More stack frames follow=3D
>= >=3B >=3B...)<=3BBR>=3B(gdb)<=3BBR>=3B>=3B >=3B<=3BBR>=3B(= >* return TRUE if server and client are on same hos=3D
>=3B >=3Bt *)&= >lt=3BBR>=3BPROCEDURE Sa=3D3D>=3B >=3BmeHost (trsl: XClient.T): BOOLEA= >N =3D3D3D<=3BBR>=3B&=3Bnbsp=3D
>=3B >=3B=3D3D3B VAR<=3BBR&g= >t=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bn=3D3D>=3B >=3Bbsp=3D3D3= >B display&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D=3D
>=3B >=3B3B&=3Bnbs= >p=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp= >=3D3D3B&=3Bnbsp=3D3D>=3B >=3B=3D3D3B&=3Bnbsp=3D
>=3B >=3B= >=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D= >3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B=3D
>=3B := >=3D3D3D Di=3D3D>=3B >=3BsplayHost(trsl)=3D3D3B<=3BBR>=3B&=3Bnbsp= >=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B disp=3D
>=3B >=3BlayAddr= >: IP.Address=3D3D3B<=3BB=3D3D>=3B >=3BR>=3B&=3Bnbsp=3D3D3B BEGIN= ><=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3B=3D
>=3B >= >=3Bnbsp=3D3D3B IF display =3D3D3D NIL THEN RETURN=3D3D>=3B >=3B TRUE=3D= >3D3B END=3D3D3B<=3BBR>=3B>=3B >=3B&=3B=3D
>=3B >=3Bnbsp= >=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B TRY<=3BBR>=3B&=3Bnbsp=3D= >3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D=3D
>=3B >= >=3B3B&=3Bnbsp=3D3D3B IF=3D3D>=3B >=3B NOT IP.GetHostByName(display= >=3D3D2C displayAddr) THEN R=3D
>=3B >=3BETURN FALSE=3D3D3B END=3D3D3= >B<=3BB=3D3D>=3B >=3BR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&= >=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B=3D
>=3B >=3B&=3Bnbsp=3D3D3B RETU= >RN displayAddr =3D3D3D IP.GetHos=3D3D>=3B >=3BtAddr()=3D3D3B<=3BBR>= >=3B&=3Bnbsp=3D3D=3D
>=3B >=3B3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D= >3B EXCEPT<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D= >3B |=3D3D>=3B >=3B IP.=3D
>=3B >=3BError =3D3D3D&=3Bgt=3D3D3B= > RETURN FALSE=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&= >=3Bnbsp=3D3D3B END=3D
>=3B >=3B=3D3D3B<=3BBR>=3B&=3B=3D3D>= >=3B >=3Bnbsp=3D3D3B END SameHost=3D3D3B<=3BBR>=3B>=3B >=3B&=3B= >nbsp=3D3D3B<=3BBR>=3B>=3B >=3BThoughts=3D
>=3B >=3B?<=3BBR= >>=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B>=3B >=3B<=3BBR>= >=3BPerhaps my network isn't setup well=3D3D2C like =3D
>=3B >=3BI sh= >ould add the local mach=3D3D>=3B >=3Bine to /etc/hosts.<=3BBR>=3BI = >think this can be =3D
>=3B >=3Bmade to fail gracefully though.<=3B= >B=3D3D>=3B >=3BR>=3BIt seems like it has nothing to do=3D
>=3B &= >gt=3B with AMD64_FREEBSD=3D3D2C but could have t=3D3D>=3B >=3Bo do with= > FreeBSD.<=3BBR>=3B>=3B >=3B<=3BBR=3D
>=3B >=3B>=3B&= >=3Bnbsp=3D3D3B<=3BBR>=3B>=3B >=3BSeems like SocketPosix has nearly = >the exact same code but=3D
>=3B >=3B appears<=3BBR>=3Bmore f=3D3= >D>=3B >=3Borgiving.. IOError instead of Fatal?<=3BBR>=3B>=3B >= >=3B&=3Bnbsp=3D3D=3D
>=3B >=3B3B<=3BBR>=3B>=3B >=3B<=3BB= >R>=3BSocketPosix.m3:<=3BBR>=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR= >>=3B>=3B >=3B<=3BBR>=3BPROCEDURE GetHostAd=3D
>=3B >=3Bdr = >(): Address<=3BBR>=3B&=3Bnbsp=3D3D3B RAISES {OSError.E} =3D3D3D<= >=3BBR=3D3D>=3B >=3B>=3B&=3Bnbsp=3D3D3B V=3D
>=3B >=3BAR<= >=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B host : AR= >RAY [0..255] OF CHAR=3D3D3B<=3B=3D3D=3D
>=3B >=3B>=3B >=3BBR&g= >t=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B info : Unetdb.st= >ruct_hostent_star=3D3D3B=3D
>=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3D&= >gt=3B >=3B=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B ua&=3Bnbsp=3D3D3= >B&=3Bnbsp=3D3D3B : Uin.struc=3D
>=3B >=3Bt_in_addr=3D3D3B<=3BBR= >>=3B&=3Bnbsp=3D3D3B =3D3D>=3B >=3BBEGIN<=3BBR>=3B&=3Bnbsp= >=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B =3D
>=3B >=3BIF Unix.get= >hostname (ADR (host[0])=3D3D2C BYT=3D3D>=3B >=3BESIZE (host)) # 0 THEN&= >lt=3BBR>=3B=3D
>=3B >=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&= >=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B IOError =3D3D>=3B >= >=3B(Unexpecte=3D
>=3B >=3Bd)=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B&= >amp=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B END=3D3D3B<=3BBR>=3B>=3B >=3B&a= >mp=3Bnbsp=3D3D3B&=3Bnbsp=3D3D=3D
>=3B >=3B3B&=3Bnbsp=3D3D3B in= >fo :=3D3D3D Unetdb.gethostbyname (ADR (host[0]))=3D3D3B<=3B=3D3D>=3B &g= >t=3BBR=3D
>=3B >=3B>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3B= >nbsp=3D3D3B IF info =3D3D3D NIL THEN IOError (Unexpected)=3D
>=3B >= >=3B=3D3D3B EN=3D3D>=3B >=3BD=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B&= >=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B &=3Blt=3D3D3B* ASSERT inf=3D
>=3B = >>=3Bo.h_length &=3Blt=3D3D3B=3D3D3D BYT=3D3D>=3B >=3BESIZE (Addres= >s) *&=3Bgt=3D3D3B<=3BBR>=3B>=3B >=3B&=3Bnbsp=3D3D3=3D
>= >=3B >=3BB&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B ua :=3D3D3D LOOPHOLE(info.h= >_addr_list=3D3D2C<=3BBR>=3B&=3Bnbsp=3D3D3=3D
>=3B >=3BB&= >=3Bn=3D3D>=3B >=3Bbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3B= >nbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D=3D
>= >=3B >=3B3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D>=3B >= >=3B=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp= >=3D
>=3B >=3B=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B&=3Bnbsp= >=3D3D3B UNTRACED REF UN=3D3D>=3B >=3BTRACED REF Uin.str=3D
>=3B &g= >t=3Buct_in_addr)^^=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B&=3Bnbsp=3D3D3B= >&=3Bnbsp=3D3D3B RETURN LOOP=3D3D>=3B >=3BHOLE=3D
>=3B >=3B (u= >a.s_addr=3D3D2C Address)=3D3D3B<=3BBR>=3B&=3Bnbsp=3D3D3B END GetHost= >Addr=3D3D3B<=3BBR>=3B>=3B >=3B&=3Bnb=3D
>=3B >=3Bsp=3D3D3= >B<=3BBR>=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B>=3B >=3BIt= > is again disappointing to see such code d=3D
>=3B >=3Buplication.&l= >t=3BBR>=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>=3B>=3B >=3B&= >=3Bnbsp=3D3D3B<=3BBR>=3B>=3B >=3BI guess&=3Bnbsp=3D3D3BSameHo=3D= >
>=3B >=3Bst can duplicate the logic to predict the error state =3D3= >D>=3B >=3Band return fals=3D
>=3B >=3Be&=3Bnbsp=3D3D3Bupon er= >ror?<=3BBR>=3B>=3B >=3BDuplicating the logic for a third time. :(&l= >t=3BBR>=3B=3D
>=3B >=3B>=3B >=3B&=3Bnbsp=3D3D3B<=3BBR>= >=3B>=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3D3B- Jay<=3BBR>=3B<=3BBR= >>=3B<=3B/body>=3B>=3B >=3B<=3B/html>=3B=3D3D>=3B >=3B>= >=3B >=3B--=3D
>=3B >=3B_9e67232c-a064-417d-879e-227a77e310f9_--=3D= >
>=3B >=3B
>=3B >=3B--_b00371fe-730b-4981-9051-a874361296d7_<= >BR>>=3B >=3BContent-Type: text/html=3B charset=3D"iso-8859-1"
>=3B= > >=3BContent-Transfer-Encoding: quoted-printable
>=3B >=3B
>= >=3B >=3B<=3Bhtml>=3B
>=3B >=3B<=3Bhead>=3B
>=3B >= >=3B<=3Bstyle>=3B
>=3B >=3B.hmmessage P
>=3B >=3B{
>= >=3B >=3Bmargin:0px=3D3B
>=3B >=3Bpadding:0px
>=3B >=3B}
= >>=3B >=3Bbody.hmmessage
>=3B >=3B{
>=3B >=3Bfont-size: 10= >pt=3D3B
>=3B >=3Bfont-family:Verdana
>=3B >=3B}
>=3B >= >=3B<=3B/style>=3B
>=3B >=3B<=3B/head>=3B
>=3B >=3B<= >=3Bbody class=3D3D'hmmessage'>=3B
>=3B >=3BDo you know the right w= >ay?<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B = >>=3BPPC_LINUX "just worked"=3D2C and I can check Solaris and Darwin.<= >=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B= >I don't want to edit /etc/hosts -- I use DHCP.<=3BBR>=3B
>=3B >= >=3BThough DHCP has been bothering me -- only for some of my machines do nam= >es =3D
>=3B >=3Bresolve=3D2C so I end using IP addresses=3D2C which = >change sometimes=3D2C and I l=3D
>=3B >=3Boop over them running ssh = >to all of them and "see what I get"=3D2C not ideal.=3D
>=3B >=3B<= >=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B= >&=3Bnbsp=3D3B- Jay<=3BBR>=3B<=3BBR>=3B<=3BBR>=3B&=3Bgt=3D= >3B To: jay.krell at cornell.edu<=3BBR>=3B&=3Bgt=3D3B Date: S=3D
>= >=3B >=3Bun=3D2C 11 Jan 2009 08:02:18 -0800<=3BBR>=3B&=3Bgt=3D3B Fr= >om: mika at async.caltech.edu<=3BBR>=3B=3D
>=3B >=3B&=3Bgt=3D3B = >CC: m3devel at elegosoft.com<=3BBR>=3B&=3Bgt=3D3B Subject: Re: [M3devel= >] Juno (X) =3D
>=3B >=3Bnetworking problem on AMD64_FREEBSD<=3BBR&= >gt=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B This is a screwy t=3D
&= >gt=3B >=3Bhing in Modula-3. A bug I would call it.<=3BBR>=3B&=3Bgt= >=3D3B <=3BBR>=3B&=3Bgt=3D3B I've noticed =3D
>=3B >=3Ba lot o= >f networking M3 programs don't work right unless<=3BBR>=3B&=3Bgt=3D3= >B the retur=3D
>=3B >=3Bn value of Unix's "hostname" maps to a real = >IP address via<=3BBR>=3B&=3Bgt=3D3B gethos=3D
>=3B >=3Btbynam= >e. I accomplish it in practice by adding my hostname<=3BBR>=3B&=3Bgt= >=3D3B to /et=3D
>=3B >=3Bc/hosts.<=3BBR>=3B&=3Bgt=3D3B <=3B= >BR>=3B&=3Bgt=3D3B This is obviously not the right way to fix it=3D
= >>=3B >=3B... <=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B = >Mika<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Jay writes:&l= >t=3BBR>=3B&=3Bgt=3D3B &=3B=3D
>=3B >=3Bgt=3D3B--_9e67232c-a0= >64-417d-879e-227a77e310f9_<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BConten= >t-Type:=3D
>=3B >=3B text/plain=3D3B charset=3D3D"iso-8859-1"<=3BB= >R>=3B&=3Bgt=3D3B &=3Bgt=3D3BContent-Transfer-Enco=3D
>=3B >= >=3Bding: quoted-printable<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BB= >R>=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3BHi=3D
>=3B >=3B. Unix network programming question..<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3BAMD64_FREEBSD:<=3BBR>=3B&=3Bgt=3D>>=3B >=3B=3D3B &=3Bgt=3D3B$DISPLAY is set to point back to Cygwin h= >ost.It works for PPC_LIN=3D
>=3B >=3BUX.<=3BBR>=3B&=3Bgt=3D3B= > &=3Bgt=3D3B[jay at fbsdamd64a /cm3/bin]$ ./Juno<=3BBR>=3B&=3Bgt=3D3= >B &=3Bgt=3D3B*****=3D
>=3B >=3B* runtime error:*** Exception "IPE= >rror.FatalError" not in RAISES li=3D3D<=3BBR>=3B&=3B=3D
>=3B &g= >t=3Bgt=3D3B &=3Bgt=3D3Bst*** file "../src/common/IPError.m3"=3D3D2C line= > 27***<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >=3B &=3Bgt=3D3BAbort = >trap: 6 (core dumped)[jay at fbsdamd64a /cm3/bin]$<=3BBR>=3B&=3Bgt=3D3B= > &=3Bgt=3D
>=3B >=3B=3D3BIP.m3:<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BPROCEDURE GetHo= >stAddr(): Ad=3D
>=3B >=3Bdress =3D3D3D VAR hname: ARRAY [0..255] OF = >CHAR=3D3D3B =3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B BEG=3D
>= >=3B >=3BIN LOCK mu DO IF Unix.gethostname(ADR(hname[0])=3D3D2C BYTESIZE(h= >na=3D3D<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &=3Bgt=3D3Bme)) = ># 0 THEN IPError.Die ()=3D3D3B END=3D3D3B VAR h :=3D3D3D Unetdb.g=3D
>= >=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bethostbyname(ADR(= >hname[0]))=3D3D3B BEGIN IF h =3D3D3D NIL T=3D
>=3B >=3BHEN IPError.D= >ie()=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D3B END=3D3D3B RETU= >RN GetAddress(h)=3D3D=3D
>=3B >=3B3B END=3D3D3B END=3D3D3B END GetHo= >s=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BtAddr=3D3D3B<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3BPROCEDURE GetAddress (ent:= > Unetdb.struct_hostent_star): Address =3D3D3D VA=3D
>=3B >=3BR ua=3D= >3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B: Uin.struct_in_addr=3D3D3B BE= >GIN &=3Blt=3D3B* ASSERT ent.=3D
>=3B >=3Bh_length &=3Blt=3D3B= >=3D3D3D BYTESIZE(Addr=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bess) *= >&=3Bgt=3D3B ua :=3D3D3=3D
>=3B >=3BD LOOPHOLE(ent.h_addr_list=3D3= >D2C UNTRACED =3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BREF UNTRACED R= >=3D
>=3B >=3BEF Uin.struct_in_addr)^^=3D3D3B RETURN LOOPHOLE(ua.s_ad= >dr=3D3D2C A=3D3D<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >=3B &=3Bgt= >=3D3Bddress)=3D3D3B END GetAddress=3D3D3B<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B= >=3D3Bgethostbyname is failing.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B= >=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAnalogou=3D
>=3B >= >=3Bs C code also fails:<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20&l= >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B[jay at fbsdamd64a =3D
>=3B >= >=3B/cm3/bin]$ cat ~/5.c#include &=3Blt=3D3Bassert.h&=3Bgt=3D3B#includ= >e &=3Blt=3D3Bnetdb.h&=3Bgt=3D
>=3B >=3B=3D3B#i=3D3D<=3BBR>= >=3B&=3Bgt=3D3B &=3Bgt=3D3Bnclude &=3Blt=3D3Bstdio.h&=3Bgt=3D3B#= >include &=3Blt=3D3Berrno.h&=3Bg=3D
>=3B >=3Bt=3D3Btypedef stru= >ct hostent hostent_t=3D3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D= >20<=3BBR>=3B&=3Bgt=3D3B &=3B=3D
>=3B >=3Bgt=3D3Bint main()= >{ char hostname[200]=3D3D3B hostent_t* h=3D3D3B int i=3D3D3B<=3BBR>=3B&= >amp=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3B i =3D3D3D gethostname(host= >name=3D3D2C 200)=3D3D3B assert(i =3D3D3D=3D3D3D=3D
>=3B >=3B 0)=3D3D= >3B printf("hostna=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bme: %s\n"= >=3D3D2C hostname)=3D3D3B h =3D
>=3B >=3B=3D3D3D gethostbyname(hostna= >me)=3D3D3B herror("foo")=3D3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3B p=3D
>=3B >=3Brintf("%p %d %d\n"=3D3D2C h=3D3D2C errno=3D3D2C = >h_errno)=3D3D3B assert(h)=3D3D3B retu=3D
>=3B >=3Brn 0=3D3D3B}<=3B= >BR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &a= >mp=3Bgt=3D3Bherror says "unknown host"=3D
>=3B >=3B.<=3BBR>=3B&a= >mp=3Bgt=3D3B &=3Bgt=3D3BStack is:<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3B at ../src/runtime/ex_frame/RTE=3D
>=3B >=3BxFrame.m3:58#13 0x0= >000000801a7f2b3 in RTH=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Books_= >_Raise (M=3D
>=3B >=3B3_AJWxb1_ex=3D3D3DError accessing memory addre= >ss 0x8000ffffd278: =3D3D<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &a= >mp=3Bgt=3D3BBad address.) at ../src/runtime/common/RTHooks.m3:79#14 0x00000= >00=3D
>=3B >=3B80169c8=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3Bd3 in IPError__Die () at ../src/common/IPError.m=3D
>=3B >=3B3:27#= >15 0x0000000801698a3e =3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bin IP= >__GetHostAddr (M3_BCxjP=3D
>=3B >=3Bn__result=3D3D3DError accessing = >memory address 0x80=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B00ffff= >=3D
>=3B >=3Bd338: Bad address.) at ../src/POSIX/IP.m3:82#16 0x00000= >008012133d0=3D3D<=3BBR>=3B&=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt= >=3D3B in XSharedMem__SameHost (M3_AQuuui_trsl=3D3D3DError accessing mem=3D<= >BR>>=3B >=3Bory address 0=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3Bx8000ffffd4d8: Bad address.) at ../src/xvb=3D
>=3B >=3Bt/XSharedMe= >m.m3:96#17 0x000000=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B0801212a= >b7 in XSharedMem_=3D
>=3B >=3B_InitXClient (M3_AQuuui_v=3D3D3DError = >accessing memory=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B ad=3D
&= >gt=3B >=3Bdress 0x8000ffffd648: Bad address.) at ../src/xvbt/XSharedMem.m= >3:29#1=3D3D<=3BBR=3D
>=3B >=3B>=3B&=3Bgt=3D3B &=3Bgt=3D3B8= > 0x0000000801211819 in XExtensions__InitXClient (M3_AQuuui_x=3D
>=3B &= >gt=3Bclient=3D3D3DError=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B acc= >essing memory address 0x8000ffffd7f=3D
>=3B >=3B8: Bad address.) at = >../src/xvbt/X=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BExtensions.m3:= >14#19 0x=3D
>=3B >=3B00000008012467a4 in XClientF__Connect (M3_Bd56f= >i_inst=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D
>=3B >=3B= >=3D3D3D0x1879b=3D3D2C M3_AQuuui_trsl=3D3D3D0x6) at ../src/xvbt/XClientF.m3:= >583---=3D
>=3B >=3BTyp=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3Be &=3Blt=3D3Breturn&=3Bgt=3D3B to continue=3D3D2C or q &=3Blt=3D= >3Bret=3D
>=3B >=3Burn&=3Bgt=3D3B to quit---(More stack frames fol= >low=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B...)(gdb)<=3B=3D
&g= >t=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B(* return TRUE if server an= >d client are on same host *)PROC=3D
>=3B >=3BEDURE SameHost (=3D3D&l= >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Btrsl: XClient.T): BOOLEAN =3D3D3D = >VAR dis=3D
>=3B >=3Bplay :=3D3D3D DisplayH=3D3D<=3BBR>=3B&=3B= >gt=3D3B &=3Bgt=3D3Bost(trsl)=3D3D3B displayAddr: IP.Addr=3D
>=3B &g= >t=3Bess=3D3D3B BEGIN IF display =3D3D3D NIL THE=3D3D<=3BBR>=3B&=3Bgt= >=3D3B &=3Bgt=3D3BN RETURN TRUE=3D3D=3D
>=3B >=3B3B END=3D3D3B<= >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B TRY IF NOT IP.GetHostByName(displa= >y=3D3D2C displ=3D
>=3B >=3BayAddr) THEN RETURN FA=3D3D<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3BLSE=3D3D3B END=3D3D3B RETURN displayA=3D
&g= >t=3B >=3Bddr =3D3D3D IP.GetHostAddr()=3D3D3B EXCEPT =3D3D<=3BBR>=3B&a= >mp=3Bgt=3D3B &=3Bgt=3D3B| IP.Error =3D3D3D=3D
>=3B >=3B&=3Bgt= >=3D3B RETURN FALSE=3D3D3B END=3D3D3B END SameHost=3D3D3B<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BB=3D
>=3B >=3BR>=3B&=3Bgt= >=3D3B &=3Bgt=3D3BThoughts?<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D= >3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BPerhaps my n=3D
>=3B &g= >t=3Betwork isn't setup well=3D3D2C like I should add the local machine =3D3= >D<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &=3Bgt=3D3Bto /etc/hos= >ts.I think this can be made to fail gracefully though.=3D
>=3B >=3BI= >t seems l=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bike it has nothing= > to do with AMD64_FREEBSD=3D
>=3B >=3B=3D3D2C but could have to do w= >ith Fr=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BeeBSD.<=3BBR>=3B&= >amp=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B=3D3D20<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3BSeems like SocketPosix has nearly the exact same c= >=3D
>=3B >=3Bode but appearsmore forgi=3D3D<=3BBR>=3B&=3Bgt= >=3D3B &=3Bgt=3D3Bving.. IOError instead of Fata=3D
>=3B >=3Bl?<= >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B= > &=3Bgt=3D3BSocketPosix.m3:<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B= >=3D
>=3B >=3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BPROCE= >DURE GetHostAddr (): Address RAISES {OSError.E} =3D
>=3B >=3B=3D3D3D= > VAR host : AR=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BRAY [0..255] = >OF CHAR=3D3D3B info : Une=3D
>=3B >=3Btdb.struct_hostent_star=3D3D3B= > ua : U=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bin.struct_in_addr=3D= >3D=3D
>=3B >=3B3B BEGIN IF Unix.gethostname (ADR (host[0])=3D3D2C BY= >TESI=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D
>=3B >=3BZE = >(host)) # 0 THEN IOError (Unexpected)=3D3D3B END=3D3D3B<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B inf=3D
>=3B >=3Bo :=3D3D3D Unetdb.gethostb= >yname (ADR (host[0]))=3D3D3B IF info =3D3D3D NIL TH=3D3D<=3B=3D
>=3B= > >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BEN IOError (Unexpected)=3D3D3B = >END=3D3D3B &=3Blt=3D3B* ASSERT info.h=3D
>=3B >=3B_length &=3B= >lt=3D3B=3D3D3D BYTESIZE =3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B(Ad= >dress) *&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &= >=3Bgt=3D3B ua :=3D3D3D LOOPHOLE(info.h_addr_list=3D3D2C UNTRACED REF UNT=3D= >3D<=3BBR>=3B=3D
>=3B >=3B&=3Bgt=3D3B &=3Bgt=3D3BRACED REF = >Uin.struct_in_addr)^^=3D3D3B RETURN LOOPHOLE (ua.s_add=3D
>=3B >=3Br= >=3D3D2C Address=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B)=3D3D3B END= > GetHostAddr=3D3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D
>=3B >= >=3B=3D3B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR&g= >t=3B&=3Bgt=3D3B &=3Bgt=3D3BIt is again disappointing to=3D
>=3B = >>=3B see such code duplication.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3= >B=3D3D20<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR>=3B=3D= >
>=3B >=3B&=3Bgt=3D3B &=3Bgt=3D3BI guess SameHost can duplicat= >e the logic to predict the error =3D
>=3B >=3Bstate and ret=3D3D<= >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Burn false upon error?<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3BDupl=3D
>=3B >=3Bicating the logic for = >a third time. :(<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D20<=3BBR&= >gt=3B&=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B - Jay=3D3D<=3BBR&g= >t=3B&=3Bgt=3D3B &=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3= >B--_9e67232c-a064-417d-879e-22=3D
>=3B >=3B7a77e310f9_<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3BContent-Type: text/html=3D3B charset=3D3D"iso-= >8859-=3D
>=3B >=3B1"<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BConte= >nt-Transfer-Encoding: quoted-printable<=3BBR>=3B&=3Bgt=3D3B &=3Bg= >=3D
>=3B >=3Bt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Blt=3D3Bhtml&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Blt=3D3Bhead&=3Bgt=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3= >B &=3Bgt=3D3B&=3Blt=3D3Bstyle&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D= >3B &=3Bgt=3D3B.hmmessage P<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D= >
>=3B >=3B{<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bmargin:0px=3D3= >D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bpadding:0px<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D
>=3B >=3B=3D3B}<=3BBR>=3B&=3Bgt=3D3B = >&=3Bgt=3D3Bbody.hmmessage<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B{<= >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfont-=3D
>=3B >=3Bsize: 10pt= >=3D3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfont-family:Verdana<=3B= >BR>=3B&=3Bgt=3D3B &=3Bgt=3D3B}<=3BBR>=3B&=3Bg=3D
>=3B &= >gt=3Bt=3D3B &=3Bgt=3D3B&=3Blt=3D3B/style&=3Bgt=3D3B<=3BBR>=3B&= >amp=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3B/head&=3Bgt=3D3B<=3BBR>=3B= >&=3Bgt=3D3B &=3B=3D
>=3B >=3Bgt=3D3B&=3Blt=3D3Bbody class= >=3D3D3D'hmmessage'&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B= >Hi. Unix networ=3D
>=3B >=3Bk programming question..&=3Blt=3D3BBR= >&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3BBR&a= >mp=3Bgt=3D3BAMD64_=3D
>=3B >=3BFREEBSD:&=3Blt=3D3BBR&=3Bgt=3D3= >B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3BBR&=3Bgt=3D3B$= >DISPLAY is set to poi=3D
>=3B >=3Bnt back to Cygwin host.&=3Blt= >=3D3BBR&=3Bgt=3D3BIt works for PPC_LINUX=3D3D<=3BBR>=3B&=3Bgt=3D3= >B &=3Bg=3D
>=3B >=3Bt=3D3B.&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR= >>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3BBR&=3Bgt=3D3B[jay at fbsda= >md64a /cm3/bin]=3D
>=3B >=3B$ ./Juno&=3Blt=3D3BBR&=3Bgt=3D3B&l= >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3BBR&=3Bgt=3D3B***&= >amp=3Blt=3D3BBR&=3Bgt=3D3B*** r=3D
>=3B >=3Buntime error:&=3Bl= >t=3D3BBR&=3Bgt=3D3B***&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D= >3B&=3Bamp=3D3Bnbsp=3D
>=3B >=3B=3D3D3B Exception "IPE=3D3D<=3BB= >R>=3B&=3Bgt=3D3B &=3Bgt=3D3Brror.FatalError" not in RAISES list=3D<= >BR>>=3B >=3B&=3Blt=3D3BBR&=3Bgt=3D3B***&=3Bamp=3D3Bnbsp=3D3D3B= >&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B file "..=3D
>=3B = >>=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B/src/common/IPError.m= >3"=3D3D2C line 27&=3Blt=3D3BBR&=3Bgt=3D3B***&=3Bl=3D
>=3B >= >=3Bt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3B= >lt=3D3BBR&=3Bgt=3D3BAbort trap: 6 (core dumped)&=3Blt=3D
>=3B &g= >t=3B=3D3BBR&=3Bgt=3D3B[jay at fbsdamd64a /cm3/bin]$&=3Blt=3D3BBR&=3Bg= >t=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3BB=3D
>= >=3B >=3BR&=3Bgt=3D3BIP.m3:&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&= >=3Bgt=3D3B<=3B=3D
>=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BPR= >OCEDURE GetHostAddr(): Address =3D3D3D&=3Blt=3D3BBR&=3Bgt=3D3B&=3B= >amp=3D3B=3D
>=3B >=3Bnbsp=3D3D3B VAR hname: ARRAY [0..255] =3D3D<= >=3BBR>=3B&=3Bgt=3D3B OF CHAR=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D
>= >=3B >=3B=3D3B&=3Bamp=3D3Bnbsp=3D3D3B BEGIN&=3Blt=3D3BBR&=3Bgt=3D= >3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D
>= >=3B >=3B=3D3Bnbsp=3D3D3B LOCK mu DO&=3Blt=3D3BBR&=3Bgt=3D3B&=3Ba= >mp=3D3Bnbs=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bp=3D3D3B&=3Ba= >=3D
>=3B >=3Bmp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp= >=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B IF Unix.geth=3D
>=3B >=3B= >ostname(ADR(hname[0])=3D3D2C B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3BYTESIZE(hname)) # 0 THEN&=3Blt=3D
>=3B >=3B=3D3BBR&=3Bgt= >=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbs= >p=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B=3D
>=3B >=3B&=3Bamp=3D3Bnbsp= >=3D3D3B&=3Bamp=3D3Bnbsp=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B= >=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B IPErro=3D
>=3B >=3Br.Die ()=3D3D3B= >&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp= >=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B=3D
>=3B >=3B&=3Bamp=3D3Bnbsp=3D= >3D3B&=3Bamp=3D3Bnbsp=3D3D3B E=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3BND=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B=3D
>=3B >=3B&=3Bamp= >=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3B= >amp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D
>=3B >=3B=3D3D3B VAR h := >=3D3D3D Unetdb.gethost=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bbynam= >e(ADR(hname[0]))=3D
>=3B >=3B=3D3D3B BEGIN&=3Blt=3D3BBR&=3Bgt= >=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbs= >p=3D3D3B&=3Ba=3D
>=3B >=3Bmp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp= >=3D3D3B&=3Bamp=3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bnbsp= >=3D3D3B&=3Bamp=3D3Bnb=3D
>=3B >=3Bsp=3D3D3B IF h =3D3D3D NIL THEN= > IPError.Die()=3D3D3B END=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D= >
>=3B >=3B=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnb= >sp=3D
>=3B >=3B=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp= >=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B RETURN GetAddress(h)=3D
>=3B >=3B= >=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbs=3D3D<=3BBR>=3B&= >amp=3Bgt=3D3B &=3Bgt=3D3Bp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D= >
>=3B >=3B=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bn= >bsp=3D3D3B END=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bn=3D
&= >gt=3B >=3Bbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B = >END=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D3B&=3Blt=3D3B=3D= >
>=3B >=3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B END GetHostAddr= >=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D
>=3B >=3B=3D3B&=3Blt=3D3BBR&=3Bgt=3D3BPROCEDURE GetAddress= > (ent: Unetdb.struct_hostent_star): Ad=3D
>=3B >=3Bdress =3D3D3D&= >=3Blt=3D3BBR&=3Bgt=3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >amp=3Bamp=3D3Bnbsp=3D3D3B VAR ua: Uin.s=3D
>=3B >=3Btruct_in_addr=3D= >3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B BEGIN&=3Blt= >=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3B=3D
>=3B >=3Bnbsp=3D3D3B&=3Ba= >mp=3D3Bnbsp=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D3B&=3Bam= >p=3D3Bnbsp=3D3D3B &=3Bamp=3D3Blt=3D3D3=3D
>=3B >=3BB* ASSERT ent.= >h_length &=3Bamp=3D3Blt=3D3D3B=3D3D3D BYTESIZE(Address) *&=3Bamp=3D3B= >gt=3D3D3=3D
>=3B >=3BB=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D= >3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnb= >sp=3D3D3B&=3Bamp=3D3Bn=3D
>=3B >=3Bbsp=3D3D3B ua :=3D3D3D LOOPHOL= >E(ent.h_addr_list=3D3D2C&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp= >=3D
>=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D3B= >&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3= >D3B&=3Ba=3D
>=3B >=3Bmp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B= >&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D<= >BR>>=3B >=3B=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B=3D3D<=3BBR>=3B&=3B= >gt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&= >amp=3Ba=3D
>=3B >=3Bmp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D
&= >gt=3B >=3B=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B UN= >=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BTRACED REF UNTR=3D
>= >=3B ACED REF Uin.struct_in_addr)^^=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbs=3D
>=3B >=3Bp=3D3D3B&=3B= >amp=3D3Bnbsp=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D3B RETURN = >LOOPHOLE(ua.s_addr=3D3D2C A=3D
>=3B >=3Bddress)=3D3D3B&=3Blt=3D3B= >BR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B END GetAddress=3D3D3B&=3Blt= >=3D3B=3D3D<=3BBR>=3B=3D
>=3B >=3B&=3Bgt=3D3B &=3Bgt=3D3BBR= >&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbs= >p=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D
>=3B = >>=3B=3D3B &=3Bgt=3D3Bgethostbyname is failing.&=3Blt=3D3BBR&=3Bg= >t=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3BBR&=3B=3D= >
>=3B >=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&=3Bgt= >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BAnalogous C code also f=3D<= >BR>>=3B >=3Bails:&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt= >=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3= >B<=3BBR>=3B&=3Bgt=3D
>=3B >=3B=3D3B &=3Bgt=3D3B&=3Blt= >=3D3BBR&=3Bgt=3D3B[jay at fbsdamd64a /cm3/bin]$ cat ~/5.c&=3Blt=3D3BBR&a= >mp=3Bgt=3D3B#=3D
>=3B >=3Binclude &=3Bamp=3D3Blt=3D3D3Bassert.h&a= >mp=3Bamp=3D3Bgt=3D3D3B&=3Blt=3D3BB=3D3D<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3BR&=3Bgt=3D
>=3B >=3B=3D3B#include &=3Bamp=3D3Blt=3D3= >D3Bnetdb.h&=3Bamp=3D3Bgt=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B#include &a= >mp=3Bamp=3D
>=3B >=3B=3D3Blt=3D3D3Bstdio.h&=3Bamp=3D3Bgt=3D3D3B&a= >mp=3Blt=3D3BBR&=3Bgt=3D3B#include =3D3D<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B&=3B=3D
>=3B >=3Bamp=3D3Blt=3D3D3Berrno.h&=3Bamp=3D3= >Bgt=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3Btypedef struct hostent host=3D
&= >gt=3B >=3Bent_t=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3B= >gt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&=3Bgt= >=3D3B<=3BBR>=3B=3D
>=3B >=3B&=3Bgt=3D3B &=3Bgt=3D3Bint mai= >n()&=3Blt=3D3BBR&=3Bgt=3D3B{&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp= >=3D3Bnbsp=3D3D3Bchar ho=3D
>=3B >=3Bstname[200]=3D3D3B&=3Blt=3D3B= >BR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3Bhostent_t* h=3D3D3B=3D3D<=3BBR&= >gt=3B&=3Bgt=3D
>=3B >=3B=3D3B &=3Bgt=3D3B&=3Blt=3D3BBR&= >=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3Bint i=3D3D3B&=3Blt=3D3BBR&=3Bgt= >=3D3B<=3BBR>=3B&=3Bgt=3D3B =3D
>=3B >=3B&=3Bgt=3D3B&=3B= >amp=3D3Bnbsp=3D3D3Bi =3D3D3D gethostname(hostname=3D3D2C 200)=3D3D3B&=3B= >lt=3D3BBR&=3Bg=3D
>=3B >=3Bt=3D3B&=3Bamp=3D3Bnbsp=3D3D3Bassert= >(i =3D3D3D=3D3D3D 0)=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D3B= >&=3Blt=3D3BBR=3D
>=3B >=3B&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3= >Bprintf("hostname: %s\n"=3D3D2C hostname)=3D3D3B&=3Blt=3D3BBR&=3Bg=3D= >
>=3B >=3Bt=3D3B&=3Bamp=3D3Bnbsp=3D3D3Bh =3D3D3D get=3D3D<=3BBR= >>=3B&=3Bgt=3D3B &=3Bgt=3D3Bhostbyname(hostname)=3D3D3=3D
>=3B = >>=3BB&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3Bherror("foo"= >)=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D
>=3B >= >=3B=3D3D3Bprintf("%p %=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bd %d\= >n"=3D3D2C h=3D3D2C errno=3D3D2C h_errno=3D
>=3B >=3B)=3D3D3B&=3Bl= >t=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3Bassert(h)=3D3D3B&=3Blt= >=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D
>=3B >=3B=3D3D3Bret=3D3D= ><=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Burn 0=3D3D3B&=3Blt=3D3BBR&= >=3Bgt=3D3B}&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D
>= >=3B >=3B=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&am= >p=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bherror says "unkno=3D= >
>=3B >=3Bwn host".&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3BBR&=3Bgt=3D3BStack is:&=3Blt= >=3D3BBR&=3Bgt=3D
>=3B >=3B=3D3B<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D= >3Bnbsp=3D3D3B at ../=3D
>=3B >=3Bsrc/runtime/ex_frame/RTExFrame.m3:5= >8&=3Blt=3D3BBR&=3Bgt=3D3B#13 =3D3D<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B0=3D
>=3B >=3Bx0000000801a7f2b3 in RTHooks__Raise (M3_AJWx= >b1_ex=3D3D3DError accessing memor=3D
>=3B >=3By=3D3D<=3BBR>=3B&a= >mp=3Bgt=3D3B &=3Bgt=3D3B ad&=3Blt=3D3BBR&=3Bgt=3D3Bdress 0x8000fff= >fd278: Bad address.&=3Blt=3D
>=3B >=3B=3D3BBR&=3Bgt=3D3B)&= >=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3= >D3B&=3Bamp=3D3Bnbsp=3D3D3B =3D
>=3B >=3B=3D3D<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3Bat ../src/runtime/common/RTHooks.m3:79&=3Blt=3D= >3BBR&=3Bgt=3D3B#14=3D
>=3B >=3B 0x000000080169c8d3 in IPError=3D3= >D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B__Die () at ../src/common=3D>>=3B >=3B/IPError.m3:27&=3Blt=3D3BBR&=3Bgt=3D3B#15 0x00000008016= >98a3e in IP__Ge=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3B=3D
>=3B >= >=3Bgt=3D3BtHostAddr (M3_BCxjPn__result=3D3D3DError accessing mem&=3Blt= >=3D3BBR&=3Bgt=3D3Bory =3D
>=3B >=3Baddress 0x8000fff=3D3D<=3BBR= >>=3B&=3Bgt=3D3B &=3Bgt=3D3Bfd338: Bad address.&=3Blt=3D3BBR&= >=3Bgt=3D3B)&=3Blt=3D
>=3B >=3B=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3= >Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B at ../src/= >POSIX=3D
>=3B >=3B/IP.m3:=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3B82&=3Blt=3D3BBR&=3Bgt=3D3B#16 0x00000008012133d0 in XShare=3D>>=3B >=3BdMem__SameHost (M3_AQuuui_trsl=3D3D3DErro=3D3D<=3BBR>=3B&= >amp=3Bgt=3D3B &=3Bgt=3D3Br accessing m&=3Blt=3D
>=3B >=3B=3D3B= >BR&=3Bgt=3D3Bemory address 0x8000ffffd4d8: Bad address.&=3Blt=3D3BBR&= >amp=3Bgt=3D3B)&=3Blt=3D3BB=3D
>=3B >=3BR&=3Bgt=3D3B&=3Bamp= >=3D3Bnbsp=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3D3B&=3Bamp= >=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B=3D
>=3B >=3B at ../src/xv= >bt/XSharedMem.m3:96&=3Blt=3D3BBR&=3Bgt=3D3B#17 0x0000000801212a=3D3D&= >lt=3BBR>=3B&=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3Bb7 in XShared= >Mem__InitXClient (M3_AQuuui_v=3D3D3DError accessing m=3D
>=3B >=3B&a= >mp=3Blt=3D3BBR&=3Bgt=3D3Bemory add=3D3D<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3Bress 0x8000ffffd648: Bad address=3D
>=3B >=3B.&=3Blt=3D= >3BBR&=3Bgt=3D3B)&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B= >&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D
>=3B >=3B=3D3D3B at= > ../sr=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bc/xvbt/XSharedMem.m3:= >29&=3Blt=3D3BBR&=3Bgt=3D3B#18 =3D
>=3B >=3B0x0000000801211819 = >in XExtensions__InitXClie=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bnt= > (M3_AQuu=3D
>=3B >=3Bui_xclient=3D3D3DError acce&=3Blt=3D3BBR&am= >p=3Bgt=3D3Bssing memory address 0x8000ffffd7f8:=3D
>=3B >=3B =3D3D&l= >t=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BBad address.&=3Blt=3D3BBR&= >=3Bgt=3D3B)&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D
>=3B &= >gt=3B=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B at ../src/= >xvbt/XExtensions.m3=3D3D<=3BBR>=3B&=3B=3D
>=3B >=3Bgt=3D3B &a= >mp=3Bgt=3D3B:14&=3Blt=3D3BBR&=3Bgt=3D3B#19 0x00000008012467a4 in XCli= >entF__Connect (M=3D
>=3B >=3B3_Bd56fi_inst=3D3D3D0x1879=3D3D<=3BBR= >>=3B&=3Bgt=3D3B &=3Bgt=3D3Bb=3D3D2C&=3Blt=3D3BBR&=3Bgt=3D3B&a= >mp=3Bamp=3D3Bnbsp=3D
>=3B >=3B=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B M3_AQuuui_trsl=3D3D3D0x6) at ../src/xvb=3D
>=3B= > >=3Bt/XClie=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BntF.m3:583&am= >p=3Blt=3D3BBR&=3Bgt=3D3B---Type &=3Bamp=3D3Blt=3D3D3Bre=3D
>=3B = >>=3Bturn&=3Bamp=3D3Bgt=3D3D3B to continue=3D3D2C or q &=3Bamp=3D3Bl= >t=3D3D3Breturn&=3Bamp=3D3Bg=3D3D<=3BBR=3D
>=3B >=3B>=3B&= >=3Bgt=3D3B &=3Bgt=3D3Bt=3D3D3B to quit---&=3Blt=3D3BBR&=3Bgt=3D3B(= >More stack frames follow...)&=3B=3D
>=3B >=3Blt=3D3BBR&=3Bgt= >=3D3B(gdb)&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3B&=3Blt=3D3BBR&=3Bgt=3D3B(* return TR=3D
>=3B >=3BUE = >if server and client are on same host *)&=3Blt=3D3BBR&=3Bgt=3D3BPROCE= >DURE Sa=3D3D<=3BBR=3D
>=3B >=3B>=3B&=3Bgt=3D3B &=3Bgt=3D3B= >meHost (trsl: XClient.T): BOOLEAN =3D3D3D&=3Blt=3D3BBR&=3Bgt=3D3B&= >=3Bamp=3D3Bn=3D
>=3B >=3Bbsp=3D3D3B VAR&=3Blt=3D3BBR&=3Bgt=3D3= >B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bn=3D3D&= >lt=3BBR>=3B&=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3Bbsp=3D3D3B di= >splay&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbs= >p=3D3D3B=3D
>=3B >=3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp= >=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bn= >bsp=3D
>=3B >=3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=3D3= >D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp= >=3D3D3B&=3Ba=3D
>=3B >=3Bmp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D= >3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp= >=3D
>=3B >=3B=3D3D3B :=3D3D3D Di=3D3D<=3BBR>=3B&=3Bgt=3D3B &a= >mp=3Bgt=3D3BsplayHost(trsl)=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp= >=3D
>=3B >=3B=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D= >3Bnbsp=3D3D3B displayAddr: IP.Address=3D3D3B&=3Bl=3D
>=3B >=3Bt= >=3D3BB=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BR&=3Bgt=3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B BEGIN&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3B= >=3D
>=3B >=3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbs= >p=3D3D3B IF display =3D3D3D NIL THEN RETURN=3D
>=3B >=3B=3D3D<=3BB= >R>=3B&=3Bgt=3D3B &=3Bgt=3D3B TRUE=3D3D3B END=3D3D3B&=3Blt=3D3BBR= >&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D
&= >gt=3B >=3B=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp= >=3D3D3B TRY&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D
>=3B &= >gt=3B=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp= >=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B IF=3D3D=3D
>=3B >=3B<= >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B NOT IP.GetHostByName(display=3D3D2= >C displayAddr) THEN RETUR=3D
>=3B >=3BN FALSE=3D3D3B END=3D3D3B&= >=3Blt=3D3BB=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BR&=3Bgt=3D3B&= >amp=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D
>=3B >=3B=3D3Bnbsp=3D3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B = >RETURN display=3D
>=3B >=3BAddr =3D3D3D IP.GetHos=3D3D<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3BtAddr()=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&a= >mp=3Bamp=3D3Bnb=3D
>=3B >=3Bsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B EXCEPT&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bn= >bsp=3D3D3=3D
>=3B >=3BB&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp= >=3D3D3B |=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B IP.Error =3D3D3D&= >amp=3Bamp=3D
>=3B >=3B=3D3Bgt=3D3D3B RETURN FALSE=3D3D3B&=3Blt=3D= >3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&= >=3B=3D
>=3B >=3Bamp=3D3Bnbsp=3D3D3B END=3D3D3B&=3Blt=3D3BBR&= >=3Bgt=3D3B&=3Bamp=3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bnb= >sp=3D3D3B =3D
>=3B >=3BEND SameHost=3D3D3B&=3Blt=3D3BBR&=3Bgt= >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&= >amp=3Blt=3D3BBR&=3Bgt=3D
>=3B >=3B=3D3B<=3BBR>=3B&=3Bgt=3D= >3B &=3Bgt=3D3BThoughts?&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3=3D
>=3B >=3BB&= >=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Blt=3D3BBR&=3Bgt=3D3BPerhaps my network isn't setu=3D
>=3B >=3B= >p well=3D3D2C like I should add the local mach=3D3D<=3BBR>=3B&=3Bgt= >=3D3B &=3Bgt=3D3Bine to /etc=3D
>=3B >=3B/hosts.&=3Blt=3D3BBR&= >amp=3Bgt=3D3BI think this can be made to fail gracefully though.&=3Blt= >=3D
>=3B >=3B=3D3BB=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BR= >&=3Bgt=3D3BIt seems like it has nothing to do with AMD6=3D
>=3B >= >=3B4_FREEBSD=3D3D2C but could have t=3D3D<=3BBR>=3B&=3Bgt=3D3B &= >=3Bgt=3D3Bo do with FreeBSD.&=3Blt=3D3B=3D
>=3B >=3BBR&=3Bgt= >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3BBR&=3Bgt= >=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B= >&=3Bg=3D
>=3B >=3Bt=3D3B &=3Bgt=3D3BSeems like SocketPosix has= > nearly the exact same code but appear=3D
>=3B >=3Bs&=3Blt=3D3BBR= >&=3Bgt=3D3Bmore f=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Borgivin= >g.. IOError instead of Fata=3D
>=3B >=3Bl?&=3Blt=3D3BBR&=3Bgt= >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&= >amp=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3B=3D
>= >=3B >=3Bgt=3D3B&=3Blt=3D3BBR&=3Bgt=3D3BSocketPosix.m3:&=3Blt=3D3= >BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3B= >nbs=3D
>=3B >=3Bp=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3BBR&=3Bgt=3D3BPROCEDURE GetHos= >tAddr ()=3D
>=3B >=3B: Address&=3Blt=3D3BBR&=3Bgt=3D3B&=3Ba= >mp=3D3Bnbsp=3D3D3B RAISES {OSError.E} =3D3D3D&=3Blt=3D3BBR=3D3D=3D
&g= >t=3B >=3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bgt=3D3B&=3B= >amp=3D3Bnbsp=3D3D3B VAR&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D= >3D3B&=3Ba=3D
>=3B >=3Bmp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3= >B host : ARRAY [0..255] OF CHAR=3D3D3B&=3Blt=3D3B=3D3D<=3B=3D
>= >=3B >=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3BBR&=3Bgt=3D3B&=3Bamp= >=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B in=3D<= >BR>>=3B >=3Bfo : Unetdb.struct_hostent_star=3D3D3B&=3Blt=3D3BBR&= >=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D<=3BBR>=3B&=3Bgt=3D3B =3D
>= >=3B >=3B&=3Bgt=3D3B=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbs= >p=3D3D3B ua&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D
>=3B >= >=3B=3D3D3B : Uin.struct_in_addr=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3B= >amp=3D3Bnbsp=3D3D3B =3D3D<=3BBR>=3B&=3Bgt=3D3B=3D
>=3B >=3B &= >amp=3Bgt=3D3BBEGIN&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&= >amp=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B =3D
>=3B >=3BIF = >Unix.gethostname (ADR (host[0])=3D3D2C BYT=3D3D<=3BBR>=3B&=3Bgt=3D3B= > &=3Bgt=3D3BESIZE (host)=3D
>=3B >=3B) # 0 THEN&=3Blt=3D3BBR&a= >mp=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp= >=3D3Bnbsp=3D3D3B&=3Bam=3D
>=3B >=3Bp=3D3Bnbsp=3D3D3B&=3Bamp=3D= >3Bnbsp=3D3D3B IOError =3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B(Unex= >pected)=3D3D3B=3D
>=3B >=3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp= >=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B END=3D= >3D3B&=3Blt=3D
>=3B >=3B=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3B= >gt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&= >amp=3Bamp=3D3Bnbsp=3D3D3=3D
>=3B >=3BB info :=3D3D3D Unetdb.gethostb= >yname (ADR (host[0]))=3D3D3B&=3Blt=3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B= > =3D
>=3B >=3B&=3Bgt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D= >3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B IF info =3D3D3=3D>>=3B >=3BD NIL THEN IOError (Unexpected)=3D3D3B EN=3D3D<=3BBR>=3B&= >amp=3Bgt=3D3B &=3Bgt=3D3BD=3D3D3B&=3Blt=3D3BBR&=3Bg=3D
>=3B &= >gt=3Bt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp= >=3D3Bnbsp=3D3D3B &=3Bamp=3D3Blt=3D3D3B* ASSERT=3D
>=3B >=3B info.= >h_length &=3Bamp=3D3Blt=3D3D3B=3D3D3D BYT=3D3D<=3BBR>=3B&=3Bgt=3D= >3B &=3Bgt=3D3BESIZE (Address) *=3D
>=3B >=3B&=3Bamp=3D3Bgt=3D3= >D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3= >B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D=3D
>=3B >=3B3B&a= >mp=3Bamp=3D3Bnbsp=3D3D3B ua :=3D3D3D LOOPHOLE(info.h_addr_list=3D3D2C&= >=3Blt=3D3BBR&=3Bgt=3D3B&=3Ba=3D
>=3B >=3Bmp=3D3Bnbsp=3D3D3B&am= >p=3Bamp=3D3Bn=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3Bbsp=3D3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnb=3D
>=3B >=3Bsp=3D3D3B&=3B= >amp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D
>=3B >=3B=3D3Bnbsp=3D3D3B&=3B= >amp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D<=3BBR>=3B&=3Bgt=3D3B &am= >p=3Bgt=3D3B=3D3D3B&=3Bamp=3D3Bnbsp=3D
>=3B >=3B=3D3D3B&=3Bamp= >=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3B= >amp=3D3Bnbsp=3D3D3B&=3Bamp=3D
>=3B >=3B=3D3Bnbsp=3D3D3B&=3Bamp= >=3D3Bnbsp=3D3D3B UNTRACED REF UN=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3BTRACED REF =3D
>=3B >=3BUin.struct_in_addr)^^=3D3D3B&=3Blt= >=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Bamp=3D3Bnbsp=3D3D3B&a= >mp=3Bam=3D
>=3B >=3Bp=3D3Bnbsp=3D3D3B RETURN LOOP=3D3D<=3BBR>=3B= >&=3Bgt=3D3B &=3Bgt=3D3BHOLE (ua.s_addr=3D3D2C Address)=3D
>=3B &= >gt=3B=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B END Ge= >tHostAddr=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3B=3D
&= >gt=3B >=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BB= >R&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnb= >sp=3D3D3B=3D
>=3B >=3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&a= >mp=3Bgt=3D3B &=3Bgt=3D3BIt is again disappointing to see such code d=3D<= >BR>>=3B >=3Buplication.&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&= >=3Bgt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&=3Bg= >t=3D3B<=3BBR=3D
>=3B >=3B>=3B&=3Bgt=3D3B &=3Bgt=3D3B&= >=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bgt= >=3D3B &=3Bgt=3D3BI guess&=3Bamp=3D3B=3D
>=3B >=3Bnbsp=3D3D3BSa= >meHost can duplicate the logic to predict the error state =3D3D<=3BBR=3D<= >BR>>=3B >=3B>=3B&=3Bgt=3D3B &=3Bgt=3D3Band return false&=3Ba= >mp=3D3Bnbsp=3D3D3Bupon error?&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B= >=3D
>=3B >=3B&=3Bgt=3D3B &=3Bgt=3D3BDuplicating the logic for = >a third time. :(&=3Blt=3D3BBR&=3Bgt=3D3B<=3BBR>=3B&=3Bg=3D
= >>=3B >=3Bt=3D3B &=3Bgt=3D3B&=3Bamp=3D3Bnbsp=3D3D3B&=3Blt=3D3BB= >R&=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B&=3Blt=3D3BBR&= >amp=3Bgt=3D3B&=3Bam=3D
>=3B >=3Bp=3D3Bnbsp=3D3D3B- Jay&=3Blt= >=3D3BBR&=3Bgt=3D3B&=3Blt=3D3BBR&=3Bgt=3D3B&=3Blt=3D3B/body&= >=3Bgt=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3B=3D
>=3B >=3Bgt=3D3B&a= >mp=3Blt=3D3B/html&=3Bgt=3D3B=3D3D<=3BBR>=3B&=3Bgt=3D3B &=3Bgt= >=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B--_9e67232c-a064=3D
>= >=3B >=3B-417d-879e-227a77e310f9_--<=3BBR>=3B<=3BBR>=3B<=3B/body= >>=3B
>=3B >=3B<=3B/html>=3B=3D
>=3B >=3B
>=3B >= >=3B--_b00371fe-730b-4981-9051-a874361296d7_--

>= > >--_b0c10337-0e1c-414e-aae5-e611dcd4be8a_-- From jay.krell at cornell.edu Mon Jan 12 10:46:24 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 09:46:24 +0000 Subject: [M3devel] SPARC32_LINUX Message-ID: SPARC32_LINUX is looking pretty decent now. min and std archives at: http://modula3.elegosoft.com/cm3/uploaded-archives/ There is something funny I saw where generated OSConfig.i3 had extra stuff at the end. But I rebuilt and it went away. System builds itself, Juno, formsedit, mentor come up. After a while on the splash screen, making progress, Juno exits with: Fatal error: cannot open or create "Untitled.juno" in the current directory Hm. That might be a real problem. Maybe time to unclone the stat header.. I have write access and AMD64_FREEBSD worked ok. (Ok to have "32" in the processor name?) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 10:56:43 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 09:56:43 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: <200901120934.n0C9YOs8074851@camembert.async.caltech.edu> References: Your message of "Mon, 12 Jan 2009 08:47:17 GMT." <200901120934.n0C9YOs8074851@camembert.async.caltech.edu> Message-ID: Yes, generating the headers is viable. I thought I mentioned that a few times. They could be generated in any build "that can". i.e. a native build, that has a working C development system and checked against the checked in ones. So then porting is: copy the generator to new system, run it, copy results back, proceed Maybe a good compromise. Not good for "embedded systems", but heck, is there any such thing any longer? Doesn't everything have megs of RAM and gigs of persistant storage? :) You don't need Scheme. Just Quake + compiling and running C code. Assuming a native build system. I've done stuff in cross build systems like: typedef struct foo_t {int i; int j; } foo_t; extern const int xi = offsetof(foo_t, i); compile that, and read the value of xi out of the .obj file. The .obj file reader was written in Perl. :) (Python not available.) but to do that here, I'd have to support multiple .obj file formats. - Jay> To: jay.krell at cornell.edu> Date: Mon, 12 Jan 2009 01:34:24 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?> > > You present it as a true tragic Dilemma.> > But isn't there a Third Way---to wit, can't you "Ask the Computer"> to do the work for you?> > Generate the code somehow... Parsing the C headers is an obvious> way but there may be others that are simpler, such as writing a> Modula-3 program to generate the cloned M3 headers, sorry, interfaces.> > If I had to do this I would use my Scheme interpreter that's coded> in Modula-3 to write a Scheme program to generate the headers. This> program could pull whatever tricks are deemed necessary and suitable,> down to the point of generating and compiling and running C programs> as necessary (or parsing C code, or reading tea leaves). But the> end result would be a set of interfaces written in "Pure Modula-3".> The process of running the header generator would also have very> few dependencies on anything outside the M3 distribution.> > Mika> > Jay writes:> >--_6117a048-9185-4c03-badb-ef8f93402268_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >This is what you "have to" chose between.> >Header cloning or C code (and C headers).> >=20> >CONST or VAR (or functions?)> >=20> >I'm going to likely make the Uerror change tonight.> >You can still veto it (er=2C vote against it :) )> >=20> >Possibly some convuluted C (enum/#undef)=2C or splitting the Modula-3> >at boundaries that weren't previously believed "natural".> >(See how SetupHandlers is ~two lines in Modula-3 and the rest in C=3B> >this is partly out of ignorance. I don't know how to write those> >two lines in C=3B and laziness=2C I didn't look into how).> >=20> >=20> >=20> >Remember I'm still staying away from mainstream platforms=2C> >so the value isn't what it might appear to be=2C but it is "stage setting"=> >=2C> >and the show might go on. :)> >=20> >=20> >Also=2C the dilemna does get more difficult now=2C with the little C header=> > cloning that remains.> >=20> >For example=2C look at Upthreads.i3.> >Mainly=2C look at function prototypes.> >Constants and types are "known problems".> >Prototypes are gray. They actually tend to be portable.> >=20> >For example:> >=20> >TYPE pid_t =3D INTEGER=3B> ><*EXTERNAL "m3_getpid*> PROCEDURE getpid():pid_t=3B> >=20> >or leave it alone?> >getpid is probably the worst example.> >It is so very portable declared in Modula-3.> >But still=2C imagine pid_t might be 16bits or 32 or 64.> >Writing a wrapper is more portable -- as long as the pid isn't stuff into s=> >ome record that the system defines.> >=20> >=20> >Again=2C Upthreads.i3.> >Would you like to see it reduced=2C or left alone?> >Only deal with the types and initializers=2C or also the prototypes?> >You know=2C I could write a little portable layer=2C where all the types ar=> >e pointers=2C always null initialized.> >It would buy /some/ portability=2C and cost some.> >=20> >=20> >Do you like the sem_t change? Partly? Not at all?> >There is one sem_t in the system. So I moved it to be in C code.> >Or=2C as I had it before=2C declared as the max size/align of all the platf=> >orms -- getting that right is the same work as getting it right "the old wa=> >y"=2C except if you make a mistake=2C odds are still good of it being ok.> >=20> >=20> >Should the line be drawn at generating the remaining headers=2C rather than=> > eliminating them?> >Uerror.i3 is easily generated. Good enough?> >=20> >Upthread.i3's types can be generated generally as records with opaque array=> >s with the right size and alignment.> >=20> >Other stuff can be generated or at least checked.> >e.g. to check that getpid is declared correctly=2C you can assign it to a f=> >unction pointer and see if that compiles.> >=20> >Perf on Uerror arguably doesn't matter.> >Is it only error handling code?Or do sockets often go down "error" paths=2C=> > because they are slow and you are waiting for more data?> >=20> >Anyway=2C point is=2C I agree for sure this is valuable=2C but I might be h=> >itting the "tail" of the approach and should switch=2C I'm not sure. I keep=> > saying that though=2C and then press further.> >=20> >=20> > - Jay> >> >> >> >From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon=2C 12 Jan 200=> >9 19:24:50 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a=> > type's existance but not enough to instantiate it?> >> >> >Point taken. We live in a C universe and so need to interact. I do think => >your work with the headers is useful=2C and I want it to continue. Especia=> >lly in simplifying ports.> >> >> >On 12 Jan 2009=2C at 19:18=2C Jay wrote:> >> >I don't think a development system without C headers is interesting.. Is it=> > really? The transform I apply at times is wherever there is interaction wi=> >th C code that is described by system-dependent headers=2C or perhaps even => >fairly system-independent headers outside the Modula-3 tree=2C either write=> > wrapper functions for the functionality in the headers (e.g. stat=2C waitp=> >id)=2C which can be done in a system-independent way=2C or move the Modula-=> >3<->C transition higher=2C which is also usually system-independent=2C e.g.=> > ThreadPThreadC_SetupHandlers. It is either that or clone the headers=2C wh=> >ich seems like the worse evil. There is always going to be a Modula-3<->C t=> >ransition=2C it is just a matter of where it occurs. - Jay> >> >CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.e=> >duSubject: Re: [M3devel] declaring a type's existance but not enough to ins=> >tantiate it?Date: Mon=2C 12 Jan 2009 12:32:15 +1100> >> >> >Jay=2C I really think you are bending over backwards too far just to be abl=> >e to shoe-horn things into C. I *like* having the transpar of C header fil=> >es expressed in Modula-3=2C *particularly* for system calls=2C where you mi=> >ght even be trying to build on a system that does not have the C header fil=> >es installed=2C even though the libraries exist and can be linked to. Fund=> >amentally=2C I think anytime the Modula-3 code is made less transparent you=> > should think hard about what you are doing. The same with the change of c=> >onstants to variables.> >> >I am getting very nervous that the changes you are making are destroying th=> >e clarity of the Modula-3 run-time code.> >> >In this particular case=2C you are wanting to use a Modula-3 parameter pass=> >ing mechanism on something that is not declared in Modula-3. Seems kind of=> > dubious to me. Also=2C I really don't like the idea of accessing external=> > variables in C.> >> >-- Tony> >> >On 12 Jan 2009=2C at 11:55=2C Jay wrote:> >> >I considered ADDRESS.However I think it still doesn't satisfy. I want to be=> > able to do this: TYPE Foo_t =3D something=3B<* EXTERNAL *> VAR Foo1=2C Foo=> >2:Foo_t=3B<* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t)=> >=3B (* Modula-3=2C not external *)PROCEDURE x()=3DBEGIN UseFoo(Foo1)=3B U=> >seFoo(Foo2)=3BEND x=3B AND I want any use of:VAR Foo3:Foo3_t=3B (* Modula-3=> >=2C not external *)to error. This is sem_t and sigset_t in particular. Poss=> >ibly renaming is the thing.They used to be declared in Modula-3=2C system-d=> >ependently=2C butI moved them to portable C. I could remove the types entir=> >ely and change UseFoo to take an address=2Cand declare mask and ackSem to b=> >e integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END=3B That would sat=> >isfy but I thought it might be nicer to still provide the namedtypes to ref=> >er to the external variables. - Jay> >> >From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon=2C 12 Jan 200=> >9 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a=> > type's existance but not enough to instantiate it?What's wrong with using => >ADDRESS for references to opaque values? If sigset_t is never instantiated=> > in Modula-3=2C then why do you need it declared there?> >> >> >> >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=2C at 01:44=2C Jay wrote:> >> >Is there a way in Modula-3 to declare that a type exists=2C and there are <=> >*external*> instances of it=2C without "fully" declaring it=2C so that no M=> >odula-3 can instantiate it? I have done this for sigset_t and sem_t=2C but => >they could erroneously be instantiated by Modula-3 and I'd like to remove t=> >hat ability to mess up so easily. (* This type is not declared correctly. I=> >t is only instantiated in C code. *) sigset_t =3D RECORD END=3B(* This typ=> >e is not declared correctly. It is only instantiated in C code. *) sem_t => >=3D RECORD END=3BIn C I believe you can do this=2C like: typedef struct fo=> >o foo_t=3B extern foo_t foo=3B void UseFoo(foo_t*)=3B foo_t* GetFoo=> >(void)=3B Thanks=2C - Jay=> >> >--_6117a048-9185-4c03-badb-ef8f93402268_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >> >This is what you "have to" chose between.
> >Header cloning or C code (and C headers).
> > =3B
> >CONST or VAR (or functions?)
> > =3B
> >I'm going to likely make the Uerror change tonight.
> >You can still veto it (er=2C vote against it :) )
> > =3B
> >Possibly some convuluted C (enum/#undef)=2C or splitting the Modula-3
> >at boundaries that weren't previously believed "natural".
> >(See how SetupHandlers is ~two lines in Modula-3 and the rest in C=3B
> >this is partly out of ignorance. I don't know how to write those
> >two lines in C=3B and laziness=2C I didn't look into how).
> > =3B
> > =3B
> > =3B
> >Remember I'm still staying away from mainstream platforms=2C
> >so the value isn't what it might appear to be=2C but it is "stage setting"=> >=2C
> >and the show might go on. :)
> > =3B
> > =3B
> >Also=2C the dilemna does get more difficult now=2C with the little C header=> > cloning that remains.
> > =3B
> >For example=2C look at Upthreads.i3.
> >Mainly=2C look at function prototypes.
> >Constants and types are "known problems".
> >Prototypes are gray. They actually tend to be portable.
> > =3B
> >For example:
> > =3B
> >TYPE pid_t =3D INTEGER=3B
> ><=3B*EXTERNAL "m3_getpid*>=3B PROCEDURE getpid():pid_t=3B
> > =3B
> >or leave it alone?
> >getpid is probably the worst example.
> >It is so very portable declared in Modula-3.
> >But still=2C imagine pid_t might be 16bits or 32 or 64.
> >Writing a wrapper is more portable -- as long as the pid isn't stuff into s=> >ome record that the system defines.
> > =3B
> > =3B
> >Again=2C Upthreads.i3.
> >Would you like to see it reduced=2C or left alone?
> >Only deal with the types and initializers=2C or also the prototypes?
> >You know=2C I could write a little portable layer=2C where all the types ar=> >e pointers=2C always null initialized.
> >It would buy /some/ portability=2C and cost some.
> > =3B
> > =3B
> >Do you like the sem_t change? Partly? Not at all?
> >There is one sem_t in the system. So I moved it to be in C code.
> >Or=2C as I had it before=2C declared as the max size/align of all the platf=> >orms -- getting that right is the same work as getting it right "the old wa=> >y"=2C except if you make a mistake=2C odds are still good of it being ok. >R>> > =3B
> > =3B
> >Should the line be drawn at generating the remaining headers=2C rather than=> > eliminating them?
> >Uerror.i3 is easily generated. Good enough?
> > =3B
> >Upthread.i3's types can be generated generally as records with opaque array=> >s with the right size and alignment.
> > =3B
> >Other stuff can be generated or at least checked.
> >e.g. to check that getpid is declared correctly=2C you can assign it to a f=> >unction pointer and see if that compiles.
> > =3B
> >Perf on Uerror arguably doesn't matter.
> >Is it only error handling code?
Or do sockets often go down "error" path=> >s=2C because they are slow and you are waiting for more data?
> > =3B
> >Anyway=2C point is=2C I agree for sure this is valuable=2C but I might be h=> >itting the "tail" of the approach and should switch=2C I'm not sure. I keep=> > saying that though=2C and then press further.
> > =3B
> > =3B
> > =3B- Jay

> >> >
>
> >From: hosking at cs.purdue.edu
To: jay.krell at cornell.edu
Date: Mon=2C 12=> > Jan 2009 19:24:50 +1100
CC: m3devel at elegosoft.com
Subject: Re: [M3de=> >vel] declaring a type's existance but not enough to instantiate it?

=> >
> >
>12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-IND=> >ENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPS=> >E: separate">> >
>e=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B C=> >OLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-S=> >PACING: normal=3B BORDER-COLLAPSE: separate"> >pan style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: n=> >one=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B => >LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate"> >-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRAN=> >SFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: no=> >rmal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate"> >EC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B T=> >EXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-S=> >PACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate"> >class=3DEC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvet=> >ica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B=> > WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate=> >"> >x Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT=> >: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: => >separate"> >ONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEX=> >T-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-CO=> >LLAPSE: separate"> >0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0=> >)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B B=> >ORDER-COLLAPSE: separate">> >
Point taken.  =3BWe live in a C universe and so need to interact. => > =3BI do think your work with the headers is useful=2C and I want it to=> > continue.  =3BEspecially in simplifying ports.
> >

 >V>
> >
> >
On 12 Jan 2009=2C at 19:18=2C Jay wrote:

>erchange-newline>> >
> FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B T=> >EXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-=> >COLLAPSE: separate">> >
>>I don't think a development system without C headers is interesting.. Is i=> >t really?
 =3B
The transform I apply at times is wherever there i=> >s interaction with C code that is described by system-dependent headers=2C => >or perhaps even fairly system-independent headers outside the Modula-3 tree=> >=2C either write wrapper functions for the functionality in the headers (e.=> >g. stat=2C waitpid)=2C which =3Bcan be done in a system-independent way=> >=2C =3Bor move the Modula-3<=3B->=3BC transition higher=2C which is=> > also usually system-independent=2C e.g. ThreadPThreadC_SetupHandlers.
&=> >nbsp=3B
It is either that or clone the headers=2C which seems like the w=> >orse evil.
 =3B
There is always going to be a Modula-3<=3B->=> >=3BC transition=2C it is just a matter of where it occurs.
 =3B
&=> >nbsp=3B- Jay

> >
> >
CC: =3B >lto:m3devel at elegosoft.com">m3devel at elegosoft.com
From: >EC_Apple-converted-space> =3B >.edu">hosking at cs.purdue.edu
To: >e> =3Bjay.krell at cornell=> >.edu
Subject: Re: [M3devel] declaring a type's existance but not eno=> >ugh to instantiate it?
Date: Mon=2C 12 Jan 2009 12:32:15 +1100

>R>>
>T: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-=> >INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLL=> >APSE: separate">> >
>tyle=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=> >=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LET=> >TER-SPACING: normal=3B BORDER-COLLAPSE: separate"> >-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRAN=> >SFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: no=> >rmal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate"> >EC_EC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=> >=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WH=> >ITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate"><=> >SPAN class=3DEC_EC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12p=> >x Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT=> >: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: => >separate"> >=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=> >=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BO=> >RDER-COLLAPSE: separate"> >-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb=> >(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: n=> >ormal=3B BORDER-COLLAPSE: separate"> >yle=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B=> > COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER=> >-SPACING: normal=3B BORDER-COLLAPSE: separate"> >yle-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFO=> >RM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: norma=> >l=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate">> >
Jay=2C I really think you are bending over backwards too far just to b=> >e able to shoe-horn things into C.  =3BI *like* having the transpar of => >C header files expressed in Modula-3=2C *particularly* for system calls=2C => >where you might even be trying to build on a system that does not have the => >C header files installed=2C even though the libraries exist and can be link=> >ed to.  =3BFundamentally=2C I think anytime the Modula-3 code is made l=> >ess transparent you should think hard about what you are doing.  =3BThe=> > same with the change of constants to variables.
> >

> >
I am getting very nervous that the changes you are making are destroyi=> >ng the clarity of the Modula-3 run-time code.
> >

> >
In this particular case=2C you are wanting to use a Modula-3 parameter=> > passing mechanism on something that is not declared in Modula-3.  =3BS=> >eems kind of dubious to me.  =3BAlso=2C I really don't like the idea of=> > accessing external variables in C.
> >

> >
-- Tony
<=> >/DIV>

> >
> >
On 12 Jan 2009=2C at 11:55=2C Jay wrote:

>interchange-newline>> >
>=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=> >=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BO=> >RDER-COLLAPSE: separate">> >
>na">I considered ADDRESS.
However I think it still doesn't satisfy.
&=> >nbsp=3B
I want to be able to do this:
 =3B
TYPE =3BFoo_t => >=3D something=3B
<=3B* EXTERNAL *>=3B VAR Foo1=2C Foo2:Foo_t=3B
&=> >lt=3B* EXTERNAL *>=3B PROCEDURE =3BUseFoo(READONLY (* or VAR *) foo:F=> >oo_t)=3B
 =3B
(* Modula-3=2C not external *)
PROCEDURE x()=3D<=> >BR>BEGIN
 =3B UseFoo(Foo1)=3B
 =3B UseFoo(Foo2)=3B
END x=> >=3B
 =3B
AND I want any use of:
VAR Foo3:Foo3_t=3B (* Modula-3=> >=2C not external *)

to error. This is sem_t and sigset_t in particul=> >ar.
 =3B
Possibly renaming is the thing.
They used to be decla=> >red in Modula-3=2C system-dependently=2C but
I moved them to portable C.=> >
 =3B
I could remove the types entirely and change UseFoo to take=> > an address=2C
and declare mask and ackSem to be integers or I guess. >><=3B*EXTERNAL>=3B VAR ackSem =3B: RECORD END=3B
 =3B
Tha=> >t would satisfy but I thought it might be nicer to still provide the named<=> >BR>types to refer to the external variables.
 =3B
 =3B- Jay >R>
> >
> >
From: =3B >=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu
To: >ss=3DEC_EC_Apple-converted-space> =3B >@cornell.edu">jay.krell at cornell.edu
Date: Mon=2C 12 Jan 2009 11:13:0=> >0 +1100
CC: =3B >ref=3D"mailto:m3devel at elegosoft.com">m3devel at elegosoft.com
Subject: => >Re: [M3devel] declaring a type's existance but not enough to instantiate it=> >?

What's wrong with using ADDRESS for references to opaque values? &=> >nbsp=3BIf sigset_t is never instantiated in Modula-3=2C then why do you nee=> >d it declared there?
> >

> >
>FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TE=> >XT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-C=> >OLLAPSE: separate">> >
>n style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: non=> >e=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LE=> >TTER-SPACING: normal=3B BORDER-COLLAPSE: separate"> >pple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-=> >TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE=> >: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate"> >s=3DEC_EC_EC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helv=> >etica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=> >=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separ=> >ate"> >FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TE=> >XT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-C=> >OLLAPSE: separate"> >ACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=> >=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: nor=> >mal=3B BORDER-COLLAPSE: separate"> >tyle=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=> >=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LET=> >TER-SPACING: normal=3B BORDER-COLLAPSE: separate"> >ple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helvetica=3B TEXT-T=> >RANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=3B WHITE-SPACE:=> > normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separate"> >=3DEC_EC_EC_Apple-style-span style=3D"WORD-SPACING: 0px=3B FONT: 12px Helve=> >tica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0)=3B TEXT-INDENT: 0px=> >=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B BORDER-COLLAPSE: separ=> >ate">> >
>EC_EC_EC_Apple-style-span face=3D"Gill Sans"> >tyle-span style=3D"COLOR: rgb(0=2C0=2C255)=3B FONT-FAMILY: 'Gill Sans'"> >AN class=3DEC_EC_EC_Apple-style-span style=3D"COLOR: rgb(0=2C0=2C255)=3B FO=> >NT-FAMILY: 'Gill Sans'">Antony Hosking >ss=3DEC_EC_EC_Apple-style-span face=3D"Gill Sans"> >ple-style-span style=3D"FONT-FAMILY: 'Gill Sans'"> >ple-style-span style=3D"FONT-FAMILY: 'Gill Sans'"> >-converted-space> =3B|=> > =3B >=3D"FONT-FAMILY: 'Gill Sans'"> >=3D"FONT-FAMILY: 'Gill Sans'">Associate Professor >=3DEC_EC_EC_Apple-style-span style=3D"FONT-FAMILY: 'Gill Sans'"> >=3DEC_EC_EC_Apple-style-span style=3D"FONT-FAMILY: 'Gill Sans'"> =3B| C=> >omputer Science | Purdue University
> >
>ass=3DEC_EC_EC_Apple-style-span style=3D"FONT-FAMILY: GillSans-Light">305 N=> >. University Street | West Lafayette | IN 47907 | USA
> >
>00ff> >5)=3B FONT-FAMILY: 'Gill Sans'"> >le=3D"COLOR: rgb(0=2C0=2C255)=3B FONT-FAMILY: 'Gill Sans'">Office >PAN> >PAN class=3DEC_EC_EC_Apple-style-span style=3D"FONT-FAMILY: GillSans-Light"=> >> >ht"> =3B+1 765 494 6001 |&nbs=> >p=3B >e=3D"Gill Sans" color=3D#0000ff> >le=3D"COLOR: rgb(0=2C0=2C255)=3B FONT-FAMILY: 'Gill Sans'"> >_EC_EC_Apple-style-span style=3D"COLOR: rgb(0=2C0=2C255)=3B FONT-FAMILY: 'G=> >ill Sans'">Mobile >an face=3DGillSans-Light> >ONT-FAMILY: GillSans-Light"> >=3D"FONT-FAMILY: GillSans-Light">=> > =3B+1 765 427 5484
> >

>s=3DEC_EC_EC_khtml-block-placeholder>
 >AN>
>AN>

> >
> >
On 12 Jan 2009=2C at 01:44=2C Jay wrote:

>le-interchange-newline>> >
>0px=3B FONT: 12px Helvetica=3B TEXT-TRANSFORM: none=3B COLOR: rgb(0=2C0=2C0=> >)=3B TEXT-INDENT: 0px=3B WHITE-SPACE: normal=3B LETTER-SPACING: normal=3B B=> >ORDER-COLLAPSE: separate">> >
>rdana">Is there a way in Modula-3 to declare that =3Ba type exists=2C a=> >nd there are <=3B*external*>=3B instances of it=2C without "fully" decl=> >aring it=2C so that no Modula-3 can instantiate it?
 =3B
I have d=> >one this for sigset_t and sem_t=2C but they could erroneously be instantiat=> >ed by Modula-3 and I'd like to remove that ability to mess up so easily. >> =3B
(* This type is not declared correctly. It is only instantiate=> >d in C code. *)
 =3B sigset_t =3D RECORD END=3B

(* This type => >is not declared correctly. It is only instantiated in C code. *)
 => >=3B sem_t =3D RECORD END=3B

In C I believe you can do this=2C like:<=> >BR> =3B =3Btypedef struct foo foo_t=3B =3B >C_Apple-converted-space> =3B
 =3B =3Bextern foo_t foo=> >=3B =3B =3B
=> > =3B
 =3Bvoid UseFoo(foo_t*)=3B >erted-space> =3B
 =3B foo_t* GetFoo(void)=3B >=3DEC_EC_EC_Apple-converted-space> =3B
 =3B
Thanks=2C<=> >BR> =3B- Jay




<=> >/DIV>
=> >

>V>
> >=> >> >--_6117a048-9185-4c03-badb-ef8f93402268_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Jan 12 11:13:25 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 12 Jan 2009 02:13:25 -0800 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: Your message of "Mon, 12 Jan 2009 09:56:43 GMT." Message-ID: <200901121013.n0CADQE0075969@camembert.async.caltech.edu> I think you're misunderstanding me a bit. You don't need C either. I would use a Lisp-based language for the "top level" just because they are good at handling things like parse trees, if one gets to that. The objectives are: * A finished system in Pure Modula-3 (no executable C) * Make it as self-contained as possible You'd start by simply bundling the existing headers with m3bundle and printing them out. Then you'd find duplication (what you've been doing) and express that programmatically. Then you might find things that might conceivably change in the OS headers and use whatever tricks were necessary to figure them out automatically. Does this involve C? Maybe on some architecture it does, maybe on another it doesn't. On some it might not involve running C but merely parsing C headers. Perhaps the program is just hand-written and just a way of distilling all the duplication into one place where it can be clearly described and documented. Since this is a Modula-3 distribution, obviously the program I'm talking about is written in Modula-3, not in C or Perl or Python. Mika Jay writes: >--_2e194b09-14b6-4301-9116-a9e4d1e522b4_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Yes=2C generating the headers is viable. >I thought I mentioned that a few times. >They could be generated in any build "that can". i.e. a native build=2C th= >at has a working C development system and checked against the checked in o= >nes. > So then porting is: copy the generator to new system=2C run it=2C copy r= >esults back=2C proceed=20 > Maybe a good compromise. Not good for "embedded systems"=2C but heck=2C i= >s there any such thing any longer? Doesn't everything have megs of RAM and= > gigs of persistant storage? :) >You don't need Scheme. >Just Quake + compiling and running C code. >Assuming a native build system. >I've done stuff in cross build systems like: >typedef struct foo_t {int i=3B int j=3B } foo_t=3B >extern const int xi =3D offsetof(foo_t=2C i)=3B >=20 >compile that=2C and read the value of xi out of the .obj file. >=20 > The .obj file reader was written in Perl. :)=20 > (Python not available.) > but to do that here=2C I'd have to support multiple .obj file formats. >=20 > - Jay> To: jay.krell at cornell.edu> Date: Mon=2C 12 Jan 2009 01:34:24 -0800>= > From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3d= >evel] declaring a type's existance but not enough to instantiate it?> > > Y= >ou present it as a true tragic Dilemma.> > But isn't there a Third Way---to= > wit=2C can't you "Ask the Computer"> to do the work for you?> > Generate t= >he code somehow... Parsing the C headers is an obvious> way but there may b= >e others that are simpler=2C such as writing a> Modula-3 program to generat= >e the cloned M3 headers=2C sorry=2C interfaces.> > If I had to do this I wo= >uld use my Scheme interpreter that's coded> in Modula-3 to write a Scheme p= >rogram to generate the headers. This> program could pull whatever tricks ar= >e deemed necessary and suitable=2C> down to the point of generating and com= >piling and running C programs> as necessary (or parsing C code=2C or readin= >g tea leaves). But the> end result would be a set of interfaces written in = >"Pure Modula-3".> The process of running the header generator would also ha= >ve very> few dependencies on anything outside the M3 distribution.> > Mika>= > > Jay writes:> >--_6117a048-9185-4c03-badb-ef8f93402268_> >Content-Type: t= >ext/plain=3B charset=3D"iso-8859-1"> >Content-Transfer-Encoding: quoted-pri= >ntable> >> >> >This is what you "have to" chose between.> >Header cloning o= >r C code (and C headers).> >=3D20> >CONST or VAR (or functions?)> >=3D20> >= >I'm going to likely make the Uerror change tonight.> >You can still veto it= > (er=3D2C vote against it :) )> >=3D20> >Possibly some convuluted C (enum/#= >undef)=3D2C or splitting the Modula-3> >at boundaries that weren't previous= >ly believed "natural".> >(See how SetupHandlers is ~two lines in Modula-3 a= >nd the rest in C=3D3B> >this is partly out of ignorance. I don't know how t= >o write those> >two lines in C=3D3B and laziness=3D2C I didn't look into ho= >w).> >=3D20> >=3D20> >=3D20> >Remember I'm still staying away from mainstre= >am platforms=3D2C> >so the value isn't what it might appear to be=3D2C but = >it is "stage setting"=3D> >=3D2C> >and the show might go on. :)> >=3D20> >= >=3D20> >Also=3D2C the dilemna does get more difficult now=3D2C with the lit= >tle C header=3D> > cloning that remains.> >=3D20> >For example=3D2C look at= > Upthreads.i3.> >Mainly=3D2C look at function prototypes.> >Constants and t= >ypes are "known problems".> >Prototypes are gray. They actually tend to be = >portable.> >=3D20> >For example:> >=3D20> >TYPE pid_t =3D3D INTEGER=3D3B> >= ><*EXTERNAL "m3_getpid*> PROCEDURE getpid():pid_t=3D3B> >=3D20> >or leave it= > alone?> >getpid is probably the worst example.> >It is so very portable de= >clared in Modula-3.> >But still=3D2C imagine pid_t might be 16bits or 32 or= > 64.> >Writing a wrapper is more portable -- as long as the pid isn't stuff= > into s=3D> >ome record that the system defines.> >=3D20> >=3D20> >Again=3D= >2C Upthreads.i3.> >Would you like to see it reduced=3D2C or left alone?> >O= >nly deal with the types and initializers=3D2C or also the prototypes?> >You= > know=3D2C I could write a little portable layer=3D2C where all the types a= >r=3D> >e pointers=3D2C always null initialized.> >It would buy /some/ porta= >bility=3D2C and cost some.> >=3D20> >=3D20> >Do you like the sem_t change? = >Partly? Not at all?> >There is one sem_t in the system. So I moved it to be= > in C code.> >Or=3D2C as I had it before=3D2C declared as the max size/alig= >n of all the platf=3D> >orms -- getting that right is the same work as gett= >ing it right "the old wa=3D> >y"=3D2C except if you make a mistake=3D2C odd= >s are still good of it being ok.> >=3D20> >=3D20> >Should the line be drawn= > at generating the remaining headers=3D2C rather than=3D> > eliminating the= >m?> >Uerror.i3 is easily generated. Good enough?> >=3D20> >Upthread.i3's ty= >pes can be generated generally as records with opaque array=3D> >s with the= > right size and alignment.> >=3D20> >Other stuff can be generated or at lea= >st checked.> >e.g. to check that getpid is declared correctly=3D2C you can = >assign it to a f=3D> >unction pointer and see if that compiles.> >=3D20> >P= >erf on Uerror arguably doesn't matter.> >Is it only error handling code?Or = >do sockets often go down "error" paths=3D2C=3D> > because they are slow and= > you are waiting for more data?> >=3D20> >Anyway=3D2C point is=3D2C I agree= > for sure this is valuable=3D2C but I might be h=3D> >itting the "tail" of = >the approach and should switch=3D2C I'm not sure. I keep=3D> > saying that = >though=3D2C and then press further.> >=3D20> >=3D20> > - Jay> >> >> >> >Fro= >m: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon=3D2C 12 Jan 200= >=3D> >9 19:24:50 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] decla= >ring a=3D> > type's existance but not enough to instantiate it?> >> >> >Poi= >nt taken. We live in a C universe and so need to interact. I do think =3D> = >>your work with the headers is useful=3D2C and I want it to continue. Espec= >ia=3D> >lly in simplifying ports.> >> >> >On 12 Jan 2009=3D2C at 19:18=3D2C= > Jay wrote:> >> >I don't think a development system without C headers is in= >teresting.. Is it=3D> > really? The transform I apply at times is wherever = >there is interaction wi=3D> >th C code that is described by system-dependen= >t headers=3D2C or perhaps even =3D> >fairly system-independent headers outs= >ide the Modula-3 tree=3D2C either write=3D> > wrapper functions for the fun= >ctionality in the headers (e.g. stat=3D2C waitp=3D> >id)=3D2C which can be = >done in a system-independent way=3D2C or move the Modula-=3D> >3<->C transi= >tion higher=3D2C which is also usually system-independent=3D2C e.g.=3D> > T= >hreadPThreadC_SetupHandlers. It is either that or clone the headers=3D2C wh= >=3D> >ich seems like the worse evil. There is always going to be a Modula-3= ><->C t=3D> >ransition=3D2C it is just a matter of where it occurs. - Jay> >= >> >CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornel= >l.e=3D> >duSubject: Re: [M3devel] declaring a type's existance but not enou= >gh to ins=3D> >tantiate it?Date: Mon=3D2C 12 Jan 2009 12:32:15 +1100> >> >>= > >Jay=3D2C I really think you are bending over backwards too far just to be= > abl=3D> >e to shoe-horn things into C. I *like* having the transpar of C h= >eader fil=3D> >es expressed in Modula-3=3D2C *particularly* for system call= >s=3D2C where you mi=3D> >ght even be trying to build on a system that does = >not have the C header fil=3D> >es installed=3D2C even though the libraries = >exist and can be linked to. Fund=3D> >amentally=3D2C I think anytime the Mo= >dula-3 code is made less transparent you=3D> > should think hard about what= > you are doing. The same with the change of c=3D> >onstants to variables.> = >>> >I am getting very nervous that the changes you are making are destroyin= >g th=3D> >e clarity of the Modula-3 run-time code.> >> >In this particular = >case=3D2C you are wanting to use a Modula-3 parameter pass=3D> >ing mechani= >sm on something that is not declared in Modula-3. Seems kind of=3D> > dubio= >us to me. Also=3D2C I really don't like the idea of accessing external=3D> = >> variables in C.> >> >-- Tony> >> >On 12 Jan 2009=3D2C at 11:55=3D2C Jay w= >rote:> >> >I considered ADDRESS.However I think it still doesn't satisfy. I= > want to be=3D> > able to do this: TYPE Foo_t =3D3D something=3D3B<* EXTERN= >AL *> VAR Foo1=3D2C Foo=3D> >2:Foo_t=3D3B<* EXTERNAL *> PROCEDURE UseFoo(RE= >ADONLY (* or VAR *) foo:Foo_t)=3D> >=3D3B (* Modula-3=3D2C not external *)P= >ROCEDURE x()=3D3DBEGIN UseFoo(Foo1)=3D3B U=3D> >seFoo(Foo2)=3D3BEND x=3D3B = >AND I want any use of:VAR Foo3:Foo3_t=3D3B (* Modula-3=3D> >=3D2C not exter= >nal *)to error. This is sem_t and sigset_t in particular. Poss=3D> >ibly re= >naming is the thing.They used to be declared in Modula-3=3D2C system-d=3D> = >>ependently=3D2C butI moved them to portable C. I could remove the types en= >tir=3D> >ely and change UseFoo to take an address=3D2Cand declare mask and = >ackSem to b=3D> >e integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END= >=3D3B That would sat=3D> >isfy but I thought it might be nicer to still pro= >vide the namedtypes to ref=3D> >er to the external variables. - Jay> >> >Fr= >om: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon=3D2C 12 Jan 200= >=3D> >9 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] decla= >ring a=3D> > type's existance but not enough to instantiate it?What's wrong= > with using =3D> >ADDRESS for references to opaque values? If sigset_t is n= >ever instantiated=3D> > in Modula-3=3D2C then why do you need it declared t= >here?> >> >> >> >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 200= >9=3D2C at 01:44=3D2C Jay wrote:> >> >Is there a way in Modula-3 to declare = >that a type exists=3D2C and there are <=3D> >*external*> instances of it=3D= >2C without "fully" declaring it=3D2C so that no M=3D> >odula-3 can instanti= >ate it? I have done this for sigset_t and sem_t=3D2C but =3D> >they could e= >rroneously be instantiated by Modula-3 and I'd like to remove t=3D> >hat ab= >ility to mess up so easily. (* This type is not declared correctly. I=3D> >= >t is only instantiated in C code. *) sigset_t =3D3D RECORD END=3D3B(* This = >typ=3D> >e is not declared correctly. It is only instantiated in C code. *)= > sem_t =3D> >=3D3D RECORD END=3D3BIn C I believe you can do this=3D2C like:= > typedef struct fo=3D> >o foo_t=3D3B extern foo_t foo=3D3B void UseFoo(foo_= >t*)=3D3B foo_t* GetFoo=3D> >(void)=3D3B Thanks=3D2C - Jay=3D> >> >--_6117a0= >48-9185-4c03-badb-ef8f93402268_> >Content-Type: text/html=3B charset=3D"iso= >-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >= >> >> ><= >/head>> >> >This is what you "have to" chose be= >tween.
> >Header cloning or C code (and C headers).
> > =3D3B
= >> >CONST or VAR (or functions?)
> > =3D3B
> >I'm going to likely = >make the Uerror change tonight.
> >You can still veto it (er=3D2C vote a= >gainst it :) )
> > =3D3B
> >Possibly some convuluted C (enum/#und= >ef)=3D2C or splitting the Modula-3
> >at boundaries that weren't previou= >sly believed "natural".
> >(See how SetupHandlers is ~two lines in Modul= >a-3 and the rest in C=3D3B
> >this is partly out of ignorance. I don't k= >now how to write those
> >two lines in C=3D3B and laziness=3D2C I didn't= > look into how).
> > =3D3B
> > =3D3B
> > =3D3B
> >R= >emember I'm still staying away from mainstream platforms=3D2C
> >so the = >value isn't what it might appear to be=3D2C but it is "stage setting"=3D> >= >=3D2C
> >and the show might go on. :)
> > =3D3B
> > =3D3B<= >BR>> >Also=3D2C the dilemna does get more difficult now=3D2C with the littl= >e C header=3D> > cloning that remains.
> > =3D3B
> >For example= >=3D2C look at Upthreads.i3.
> >Mainly=3D2C look at function prototypes.<= >BR>> >Constants and types are "known problems".
> >Prototypes are gray. = >They actually tend to be portable.
> > =3D3B
> >For example:
>= > > =3D3B
> >TYPE pid_t =3D3D INTEGER=3D3B
> ><=3D3B*EXTERNAL "m= >3_getpid*>=3D3B PROCEDURE getpid():pid_t=3D3B
> > =3D3B
> >or l= >eave it alone?
> >getpid is probably the worst example.
> >It is so v= >ery portable declared in Modula-3.
> >But still=3D2C imagine pid_t might= > be 16bits or 32 or 64.
> >Writing a wrapper is more portable -- as long= > as the pid isn't stuff into s=3D> >ome record that the system defines.
= >> > =3D3B
> > =3D3B
> >Again=3D2C Upthreads.i3.
> >Would y= >ou like to see it reduced=3D2C or left alone?
> >Only deal with the type= >s and initializers=3D2C or also the prototypes?
> >You know=3D2C I could= > write a little portable layer=3D2C where all the types ar=3D> >e pointers= >=3D2C always null initialized.
> >It would buy /some/ portability=3D2C a= >nd cost some.
> > =3D3B
> > =3D3B
> >Do you like the sem_t= > change? Partly? Not at all?
> >There is one sem_t in the system. So I m= >oved it to be in C code.
> >Or=3D2C as I had it before=3D2C declared as = >the max size/align of all the platf=3D> >orms -- getting that right is the = >same work as getting it right "the old wa=3D> >y"=3D2C except if you make a= > mistake=3D2C odds are still good of it being ok. >R>> > =3D3B>> > =3D3B
> >Should the line be drawn at generating the remaining h= >eaders=3D2C rather than=3D> > eliminating them?
> >Uerror.i3 is easily g= >enerated. Good enough?
> > =3D3B
> >Upthread.i3's types can be ge= >nerated generally as records with opaque array=3D> >s with the right size a= >nd alignment.
> > =3D3B
> >Other stuff can be generated or at lea= >st checked.
> >e.g. to check that getpid is declared correctly=3D2C you = >can assign it to a f=3D> >unction pointer and see if that compiles.
> >&= >nbsp=3D3B
> >Perf on Uerror arguably doesn't matter.
> >Is it only er= >ror handling code?
Or do sockets often go down "error" path=3D> >s=3D2C = >because they are slow and you are waiting for more data?
> > =3D3BR>> >Anyway=3D2C point is=3D2C I agree for sure this is valuable=3D2C but I= > might be h=3D> >itting the "tail" of the approach and should switch=3D2C I= >'m not sure. I keep=3D> > saying that though=3D2C and then press further.R>> > =3D3B
> > =3D3B
> > =3D3B- Jay

> >> >
=3D3DstopSpelling>>
> >From: hosking at cs.purdue.edu
To: jay.krell at cor= >nell.edu
Date: Mon=3D2C 12=3D> > Jan 2009 19:24:50 +1100
CC: m3devel@= >elegosoft.com
Subject: Re: [M3de=3D> >vel] declaring a type's existance = >but not enough to instantiate it?

=3D> >
> >
EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: =3D> >12px Helv= >etica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-IN= >D=3D> >ENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B B= >ORDER-COLLAPS=3D> >E: separate">> >
<= >SPAN class=3D3DEC_Apple-style-span styl=3D> >e=3D3D"WORD-SPACING: 0px=3D3B = >FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B C=3D> >OLOR: rgb(0=3D2C= >0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-S=3D> >= >PACING: normal=3D3B BORDER-COLLAPSE: separate">le-s=3D> >pan style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B T= >EXT-TRANSFORM: n=3D> >one=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: = >0px=3D3B WHITE-SPACE: normal=3D3B =3D> >LETTER-SPACING: normal=3D3B BORDER-= >COLLAPSE: separate"> >-style-span style=3D3D"WO= >RD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRAN=3D> >SFORM: none= >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: no= >=3D> >rmal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate">N class=3D3D=3D> >EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FON= >T: 12px Helvetica=3D3B T=3D> >EXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0= >=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-S=3D> >PACE: normal=3D3B LETTER-SP= >ACING: normal=3D3B BORDER-COLLAPSE: separate"> >class=3D3DEC_Appl= >e-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvet=3D> >ica= >=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT:= > 0px=3D3B=3D> > WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER= >-COLLAPSE: separate=3D> >">ORD-SPACING: 0px=3D3B FONT: 12p=3D> >x Helvetica=3D3B TEXT-TRANSFORM: none= >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT=3D> >: 0px=3D3B WHITE-SPAC= >E: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: =3D> >separate"= >>> >ONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D= >2C0)=3D3B TEX=3D> >T-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACI= >NG: normal=3D3B BORDER-CO=3D> >LLAPSE: separate">tyle-span style=3D3D"WORD-SPACING: =3D> >0px=3D3B FONT: 12px Helvetica=3D3B= > TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0=3D> >)=3D3B TEXT-INDENT= >: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B B=3D> >ORDE= >R-COLLAPSE: separate">> >
Point taken.  =3D3BWe live in a C univers= >e and so need to interact. =3D> > =3D3BI do think your work with the he= >aders is useful=3D2C and I want it to=3D> > continue.  =3D3BEspecially = >in simplifying ports.
> >

SPAN> >V>
> >
> >
On 12 Ja= >n 2009=3D2C at 19:18=3D2C Jay wrote:

>e= >rchange-newline>> >
3D"WORD-SPACING: 0px=3D3B=3D> > FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: n= >one=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B T=3D> >EXT-INDENT: 0px=3D3B WHITE-S= >PACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-=3D> >COLLAPSE: separa= >te">> >
ILY: Verdana"=3D> >>I don't think a development system without C headers is= > interesting.. Is i=3D> >t really?
 =3D3B
The transform I apply a= >t times is wherever there i=3D> >s interaction with C code that is describe= >d by system-dependent headers=3D2C =3D> >or perhaps even fairly system-inde= >pendent headers outside the Modula-3 tree=3D> >=3D2C either write wrapper f= >unctions for the functionality in the headers (e.=3D> >g. stat=3D2C waitpid= >)=3D2C which =3D3Bcan be done in a system-independent way=3D> >=3D2C&nb= >sp=3D3Bor move the Modula-3<=3D3B->=3D3BC transition higher=3D2C which = >is=3D> > also usually system-independent=3D2C e.g. ThreadPThreadC_SetupHand= >lers.
&=3D> >nbsp=3D3B
It is either that or clone the headers=3D2C wh= >ich seems like the w=3D> >orse evil.
 =3D3B
There is always going= > to be a Modula-3<=3D3B->=3D> >=3D3BC transition=3D2C it is just a matt= >er of where it occurs.
 =3D3B
&=3D> >nbsp=3D3B- Jay

> > id=3D3DEC_stopSpelling>> >
CC:= > =3D3B >lto:m3devel at elegosoft.com">m3devel at e= >legosoft.com
From: >EC_Apple-converted-space>&nb= >sp=3D3B >.edu">hosking at cs.p= >urdue.edu
To: >e> =3D= >3Bjay.krell at cornell=3D> >= >.edu
Subject: Re: [M3devel] declaring a type's existance but not eno= >=3D> >ugh to instantiate it?
Date: Mon=3D2C 12 Jan 2009 12:32:15 +1100R>
>R>>
RD-SPACING: 0px=3D3B FON=3D> >T: 12px Helvetica=3D3B TEXT-TRANSFORM: none= >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-=3D> >INDENT: 0px=3D3B WHITE-SPAC= >E: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLL=3D> >APSE: separate"= >>> >
e-span s=3D> >tyle=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TE= >XT-TRANSFORM: none=3D> >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0= >px=3D3B WHITE-SPACE: normal=3D3B LET=3D> >TER-SPACING: normal=3D3B BORDER-C= >OLLAPSE: separate"> >-style-span style=3D3D"= >WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRAN=3D> >SFORM: none= >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: no= >=3D> >rmal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate">N class=3D3D=3D> >EC_EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B = >FONT: 12px Helvetica=3D> >=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C= >0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WH=3D> >ITE-SPACE: normal=3D3B LETTER-S= >PACING: normal=3D3B BORDER-COLLAPSE: separate"><=3D> >SPAN class=3D3DEC_EC_= >Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12p=3D> >x Helveti= >ca=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDEN= >T=3D> >: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORD= >ER-COLLAPSE: =3D> >separate">=3D3D"WORD-SPACING: 0px=3D> >=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM= >: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D> >=3D3B TEXT-INDENT: 0px=3D3B WHIT= >E-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BO=3D> >RDER-COLLAPSE: sep= >arate"> >-SPACING= >: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb= >=3D> >(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B L= >ETTER-SPACING: n=3D> >ormal=3D3B BORDER-COLLAPSE: separate">DEC_EC_Apple-style-span st=3D> >yle=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px = >Helvetica=3D3B TEXT-TRANSFORM: none=3D3B=3D> > COLOR: rgb(0=3D2C0=3D2C0)=3D= >3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER=3D> >-SPACING: nor= >mal=3D3B BORDER-COLLAPSE: separate"> >yle= >-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRAN= >SFO=3D> >RM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B= > WHITE-SPACE: norma=3D> >l=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE= >: separate">> >
Jay=3D2C I really think you are bending over backwards = >too far just to b=3D> >e able to shoe-horn things into C.  =3D3BI *like= >* having the transpar of =3D> >C header files expressed in Modula-3=3D2C *p= >articularly* for system calls=3D2C =3D> >where you might even be trying to = >build on a system that does not have the =3D> >C header files installed=3D2= >C even though the libraries exist and can be link=3D> >ed to.  =3D3BFun= >damentally=3D2C I think anytime the Modula-3 code is made l=3D> >ess transp= >arent you should think hard about what you are doing.  =3D3BThe=3D> > s= >ame with the change of constants to variables.
> >

> >IV>I am getting very nervous that the changes you are making are destroyi= >=3D> >ng the clarity of the Modula-3 run-time code.
> >

= >> >
In this particular case=3D2C you are wanting to use a Modula-3 para= >meter=3D> > passing mechanism on something that is not declared in Modula-3= >.  =3D3BS=3D> >eems kind of dubious to me.  =3D3BAlso=3D2C I really= > don't like the idea of=3D> > accessing external variables in C.
> >IV>
> >
-- Tony
><=3D> >/DIV>

> >
> >
On 12 Jan 2009= >=3D2C at 11:55=3D2C Jay wrote:

>interch= >ange-newline>> >
3D"WORD-SPACING: 0px=3D> >=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: n= >one=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D> >=3D3B TEXT-INDENT: 0px=3D3B WHITE-S= >PACE: normal=3D3B LETTER-SPACING: normal=3D3B BO=3D> >RDER-COLLAPSE: separa= >te">> >
FAMILY: Verda=3D> >na">I considered ADDRESS.
However I think it still do= >esn't satisfy.
&=3D> >nbsp=3D3B
I want to be able to do this:
&nbs= >p=3D3B
TYPE =3D3BFoo_t =3D> >=3D3D something=3D3B
<=3D3B* EXTER= >NAL *>=3D3B VAR Foo1=3D2C Foo2:Foo_t=3D3B
&=3D> >lt=3D3B* EXTERNAL *&g= >t=3D3B PROCEDURE =3D3BUseFoo(READONLY (* or VAR *) foo:F=3D> >oo_t)=3D3= >B
 =3D3B
(* Modula-3=3D2C not external *)
PROCEDURE x()=3D3D<= >=3D> >BR>BEGIN
 =3D3B UseFoo(Foo1)=3D3B
 =3D3B UseFoo(Foo2)= >=3D3B
END x=3D> >=3D3B
 =3D3B
AND I want any use of:
VAR Fo= >o3:Foo3_t=3D3B (* Modula-3=3D> >=3D2C not external *)

to error. This= > is sem_t and sigset_t in particul=3D> >ar.
 =3D3B
Possibly renam= >ing is the thing.
They used to be decla=3D> >red in Modula-3=3D2C system= >-dependently=3D2C but
I moved them to portable C.=3D> >
 =3D3B>I could remove the types entirely and change UseFoo to take=3D> > an addre= >ss=3D2C
and declare mask and ackSem to be integers or I guess. >>= ><=3D3B*EXTERNAL>=3D3B VAR ackSem =3D3B: RECORD END=3D3B
 =3D= >3B
Tha=3D> >t would satisfy but I thought it might be nicer to still pro= >vide the named<=3D> >BR>types to refer to the external variables.
 = >=3D3B
 =3D3B- Jay >R>
> >
> ><= >BR>From: =3D3Bf=3D> >=3D3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu
To:= > >ss=3D3DEC_EC_Apple-converted-space> =3D3B=3D3D"mailto:jay.krell=3D> >@cornell.edu">jay.krell at cornell.edu
Date= >: Mon=3D2C 12 Jan 2009 11:13:0=3D> >0 +1100
CC:le-converted-space> =3D3B >ref=3D3D"mailto:m3devel at elego= >soft.com">m3devel at elegosoft.com
Subject: =3D> >Re: [M3devel] declari= >ng a type's existance but not enough to instantiate it=3D> >?

What's= > wrong with using ADDRESS for references to opaque values? &=3D> >nbsp=3D3B= >If sigset_t is never instantiated in Modula-3=3D2C then why do you nee=3D> = >>d it declared there?
> >

> >
-style-span style=3D3D"WORD-SPACING: 0px=3D3B =3D> >FONT: 12px Helvetica=3D= >3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TE=3D> >XT-INDE= >NT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-C= >=3D> >OLLAPSE: separate">> >
ass=3D3DEC_EC_EC_Apple-style-spa=3D> >n style=3D3D"WORD-SPACING: 0px=3D3B F= >ONT: 12px Helvetica=3D3B TEXT-TRANSFORM: non=3D> >e=3D3B COLOR: rgb(0=3D2C0= >=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LE=3D> >TTER-SP= >ACING: normal=3D3B BORDER-COLLAPSE: separate">> >pple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica= >=3D3B TEXT-=3D> >TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-I= >NDENT: 0px=3D3B WHITE-SPACE=3D> >: normal=3D3B LETTER-SPACING: normal=3D3B = >BORDER-COLLAPSE: separate"> >s=3D3DEC_EC_EC_Apple-style-span = >style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helv=3D> >etica=3D3B TEXT-TRAN= >SFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D> >=3D3B= > WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: sepa= >r=3D> >ate">NG: 0px=3D3B =3D> >FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLO= >R: rgb(0=3D2C0=3D2C0)=3D3B TE=3D> >XT-INDENT: 0px=3D3B WHITE-SPACE: normal= >=3D3B LETTER-SPACING: normal=3D3B BORDER-C=3D> >OLLAPSE: separate">ass=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SP=3D> >ACING: 0px=3D3B F= >ONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D> >=3D2C0= >=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING:= > nor=3D> >mal=3D3B BORDER-COLLAPSE: separate">e-style-span s=3D> >tyle=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica= >=3D3B TEXT-TRANSFORM: none=3D> >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-I= >NDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LET=3D> >TER-SPACING: normal=3D3B = >BORDER-COLLAPSE: separate"> >ple-style-span = >style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-T=3D> >RAN= >SFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE= >-SPACE:=3D> > normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: sepa= >rate"> >=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SPACI= >NG: 0px=3D3B FONT: 12px Helve=3D> >tica=3D3B TEXT-TRANSFORM: none=3D3B COLO= >R: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D> >=3D3B WHITE-SPACE: normal= >=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separ=3D> >ate">> >
= >D=3D> >EC_EC_EC_Apple-style-span face=3D3D"Gill Sans">_EC_Apple-s=3D> >tyle-span style=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=3D3B FONT= >-FAMILY: 'Gill Sans'"> >AN class=3D3DEC_EC_EC_Apple-style-span style= >=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=3D3B FO=3D> >NT-FAMILY: 'Gill Sans'">Anto= >ny Hosking >ss=3D3DEC_EC_EC_Apple-= >style-span face=3D3D"Gill Sans"> >ple-style-= >span style=3D3D"FONT-FAMILY: 'Gill Sans'"> >= >ple-style-span style=3D3D"FONT-FAMILY: 'Gill Sans'">pple=3D> >-converted-space> =3D3B|nverted-space>=3D> > =3D3B_Apple-style-span style=3D> >=3D3D"FONT-FAMILY: 'Gill Sans'">3DEC_EC_EC_Apple-style-span style=3D> >=3D3D"FONT-FAMILY: 'Gill Sans'">Asso= >ciate Professor >=3D3DEC_EC_EC_Apple-style-spa= >n style=3D3D"FONT-FAMILY: 'Gill Sans'"> >=3D3DEC_EC_EC_Apple= >-style-span style=3D3D"FONT-FAMILY: 'Gill Sans'"> =3D3B| C=3D> >omputer= > Science | Purdue University
> >
=3D3DEC_EC_EC_Apple-style-span face=3D3DGillSans-Light> >ass=3D= >3DEC_EC_EC_Apple-style-span style=3D3D"FONT-FAMILY: GillSans-Light">305 N= >=3D> >. University Street | West Lafayette | IN 47907 | USADIV>> >
color=3D3D#00=3D> >00ff>D"COLOR: rgb(0=3D2C0=3D2C25=3D> >5)=3D3B FONT-FAMILY: 'Gill Sans'">ass=3D3DEC_EC_EC_Apple-style-span sty=3D> >le=3D3D"COLOR: rgb(0=3D2C0=3D2C2= >55)=3D3B FONT-FAMILY: 'Gill Sans'">Office >PAN>lass=3D3DEC_EC_EC_Apple-style-span face=3D3DGillSans-Light> >PAN clas= >s=3D3DEC_EC_EC_Apple-style-span style=3D3D"FONT-FAMILY: GillSans-Light"=3D>= > >>ns-Lig=3D> >ht"> =3D3B+1 765 494 6001 |erted-space>&nbs=3D> >p=3D3BEC_EC_Apple-style-span fac=3D> >e=3D3D"Gill Sans" color=3D3D#0000ff>lass=3D3DEC_EC_EC_Apple-style-span sty=3D> >le=3D3D"COLOR: rgb(0=3D2C0=3D2C= >255)=3D3B FONT-FAMILY: 'Gill Sans'"> >_EC_EC_Apple-st= >yle-span style=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=3D3B FONT-FAMILY: 'G=3D> >i= >ll Sans'">Mobilep=3D> >an face=3D3DGillSans-Light> style=3D3D"F=3D> >ONT-FAMILY: GillSans-Light">le-style-span style=3D> >=3D3D"FONT-FAMILY: GillSans-Light">DEC_EC_Apple-converted-space>=3D> > =3D3B+1 765 427 5484<= >/SPAN>
> >
=3D3DGillSans-Light>
>s=3D3DEC_EC_EC_khtml-block-placeholder>FONT>
>AN>
=3D3DEC_EC_EC_Apple-interchange-newline> >AN>
>> >
> >
On 12 Jan 2009=3D2C at 01:44=3D2C Jay wrote:

s=3D3DEC_EC_EC_App=3D> >le-interchange-newline>> >
=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SPACING: =3D> >0px=3D3B FONT= >: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0=3D= >> >)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: no= >rmal=3D3B B=3D> >ORDER-COLLAPSE: separate">> >
sage style=3D3D"FONT-SIZE: 10pt=3D3B FONT-FAMILY: Ve=3D> >rdana">Is there a= > way in Modula-3 to declare that =3D3Ba type exists=3D2C a=3D> >nd ther= >e are <=3D3B*external*>=3D3B instances of it=3D2C without "fully" decl= >=3D> >aring it=3D2C so that no Modula-3 can instantiate it?
 =3D3BR>I have d=3D> >one this for sigset_t and sem_t=3D2C but they could erroneo= >usly be instantiat=3D> >ed by Modula-3 and I'd like to remove that ability = >to mess up so easily. >> =3D3B
(* This type is not declared c= >orrectly. It is only instantiate=3D> >d in C code. *)
 =3D3B sigset_= >t =3D3D RECORD END=3D3B

(* This type =3D> >is not declared correctly= >. It is only instantiated in C code. *)
 =3D> >=3D3B sem_t =3D3D REC= >ORD END=3D3B

In C I believe you can do this=3D2C like:<=3D> >BR>&nbs= >p=3D3B =3D3Btypedef struct foo foo_t=3D3B =3D3BC_E=3D> >C_Apple-converted-space> =3D3B
 =3D3B =3D3Be= >xtern foo_t foo=3D> >=3D3B =3D3Bd-space> =3D3B
=3D> > =3D3B
 =3D3Bvoid UseFoo(foo_= >t*)=3D3B >erted-space> =3D3BAN>
 =3D3B foo_t* GetFoo(void)=3D3B >=3D3DEC_EC_EC_Ap= >ple-converted-space> =3D3B
 =3D3B
Thanks=3D2C<=3D> >BR= >> =3D3B- Jay




<= >=3D> >/DIV>
E>
=3D> >

<= >/BLOCKQUOTE> >V>
> >=3D> >> >--_6117a048-9185-4c03= >-badb-ef8f93402268_--= > >--_2e194b09-14b6-4301-9116-a9e4d1e522b4_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >Yes=2C generating the headers is viable.
>I thought I mentioned that a few times.
They could be generated in any build "that can".
 =3B i.e. a native = >build=2C that has a working C development system
 =3B and checked ag= >ainst the checked in ones.
> =3BSo then porting is:
 =3B copy the generator to new system= >=2C run it=2C copy results back=2C proceed
>
 =3BMaybe a good compromise.
 =3BNot good for "embedded sys= >tems"=2C but heck=2C is there any such thing
 =3B any longer? Doesn'= >t everything have megs of RAM and gigs of persistant storage? :)
>
You don't need =3BScheme.
>Just Quake =3B+ compiling and running C code.
>Assuming a native build system.
>I've done stuff in cross build systems like:
>typedef struct foo_t {int i=3B int j=3B } foo_t=3B
>extern const int xi =3D offsetof(foo_t=2C i)=3B
> =3B
>compile that=2C and read the value of xi out of the .obj file.
> =3B
> =3BThe .obj file reader was written in Perl. :)
> =3B (Python not available.)
> =3Bbut to do that here=2C I'd have to support multiple .obj file forma= >ts.
> =3B
> =3B- Jay

>=3B To: jay.krell at cornell.edu
>=3B Date: Mon= >=2C 12 Jan 2009 01:34:24 -0800
>=3B From: mika at async.caltech.edu
&g= >t=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] declaring a= > type's existance but not enough to instantiate it?
>=3B
>=3B R>>=3B You present it as a true tragic Dilemma.
>=3B
>=3B But = >isn't there a Third Way---to wit=2C can't you "Ask the Computer"
>=3B = >to do the work for you?
>=3B
>=3B Generate the code somehow... P= >arsing the C headers is an obvious
>=3B way but there may be others th= >at are simpler=2C such as writing a
>=3B Modula-3 program to generate = >the cloned M3 headers=2C sorry=2C interfaces.
>=3B
>=3B If I had= > to do this I would use my Scheme interpreter that's coded
>=3B in Mod= >ula-3 to write a Scheme program to generate the headers. This
>=3B pro= >gram could pull whatever tricks are deemed necessary and suitable=2C
>= >=3B down to the point of generating and compiling and running C programs>>=3B as necessary (or parsing C code=2C or reading tea leaves). But the<= >BR>>=3B end result would be a set of interfaces written in "Pure Modula-3= >".
>=3B The process of running the header generator would also have ve= >ry
>=3B few dependencies on anything outside the M3 distribution.
&= >gt=3B
>=3B Mika
>=3B
>=3B Jay writes:
>=3B >=3B--_6= >117a048-9185-4c03-badb-ef8f93402268_
>=3B >=3BContent-Type: text/pla= >in=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Encoding: quo= >ted-printable
>=3B >=3B
>=3B >=3B
>=3B >=3BThis is wha= >t you "have to" chose between.
>=3B >=3BHeader cloning or C code (an= >d C headers).
>=3B >=3B=3D20
>=3B >=3BCONST or VAR (or functi= >ons?)
>=3B >=3B=3D20
>=3B >=3BI'm going to likely make the Ue= >rror change tonight.
>=3B >=3BYou can still veto it (er=3D2C vote ag= >ainst it :) )
>=3B >=3B=3D20
>=3B >=3BPossibly some convulute= >d C (enum/#undef)=3D2C or splitting the Modula-3
>=3B >=3Bat boundar= >ies that weren't previously believed "natural".
>=3B >=3B(See how Se= >tupHandlers is ~two lines in Modula-3 and the rest in C=3D3B
>=3B >= >=3Bthis is partly out of ignorance. I don't know how to write those
>= >=3B >=3Btwo lines in C=3D3B and laziness=3D2C I didn't look into how).>>=3B >=3B=3D20
>=3B >=3B=3D20
>=3B >=3B=3D20
>=3B &= >gt=3BRemember I'm still staying away from mainstream platforms=3D2C
>= >=3B >=3Bso the value isn't what it might appear to be=3D2C but it is "sta= >ge setting"=3D
>=3B >=3B=3D2C
>=3B >=3Band the show might go = >on. :)
>=3B >=3B=3D20
>=3B >=3B=3D20
>=3B >=3BAlso=3D2= >C the dilemna does get more difficult now=3D2C with the little C header=3D<= >BR>>=3B >=3B cloning that remains.
>=3B >=3B=3D20
>=3B >= >=3BFor example=3D2C look at Upthreads.i3.
>=3B >=3BMainly=3D2C look = >at function prototypes.
>=3B >=3BConstants and types are "known prob= >lems".
>=3B >=3BPrototypes are gray. They actually tend to be portab= >le.
>=3B >=3B=3D20
>=3B >=3BFor example:
>=3B >=3B=3D2= >0
>=3B >=3BTYPE pid_t =3D3D INTEGER=3D3B
>=3B >=3B<=3B*EXTE= >RNAL "m3_getpid*>=3B PROCEDURE getpid():pid_t=3D3B
>=3B >=3B=3D20<= >BR>>=3B >=3Bor leave it alone?
>=3B >=3Bgetpid is probably the w= >orst example.
>=3B >=3BIt is so very portable declared in Modula-3.<= >BR>>=3B >=3BBut still=3D2C imagine pid_t might be 16bits or 32 or 64.R>>=3B >=3BWriting a wrapper is more portable -- as long as the pid isn= >'t stuff into s=3D
>=3B >=3Bome record that the system defines.
&= >gt=3B >=3B=3D20
>=3B >=3B=3D20
>=3B >=3BAgain=3D2C Upthread= >s.i3.
>=3B >=3BWould you like to see it reduced=3D2C or left alone?<= >BR>>=3B >=3BOnly deal with the types and initializers=3D2C or also the = >prototypes?
>=3B >=3BYou know=3D2C I could write a little portable l= >ayer=3D2C where all the types ar=3D
>=3B >=3Be pointers=3D2C always = >null initialized.
>=3B >=3BIt would buy /some/ portability=3D2C and = >cost some.
>=3B >=3B=3D20
>=3B >=3B=3D20
>=3B >=3BDo y= >ou like the sem_t change? Partly? Not at all?
>=3B >=3BThere is one = >sem_t in the system. So I moved it to be in C code.
>=3B >=3BOr=3D2C= > as I had it before=3D2C declared as the max size/align of all the platf=3D= >
>=3B >=3Borms -- getting that right is the same work as getting it = >right "the old wa=3D
>=3B >=3By"=3D2C except if you make a mistake= >=3D2C odds are still good of it being ok.
>=3B >=3B=3D20
>=3B &= >gt=3B=3D20
>=3B >=3BShould the line be drawn at generating the remai= >ning headers=3D2C rather than=3D
>=3B >=3B eliminating them?
>= >=3B >=3BUerror.i3 is easily generated. Good enough?
>=3B >=3B=3D20= >
>=3B >=3BUpthread.i3's types can be generated generally as records = >with opaque array=3D
>=3B >=3Bs with the right size and alignment.R>>=3B >=3B=3D20
>=3B >=3BOther stuff can be generated or at lea= >st checked.
>=3B >=3Be.g. to check that getpid is declared correctly= >=3D2C you can assign it to a f=3D
>=3B >=3Bunction pointer and see i= >f that compiles.
>=3B >=3B=3D20
>=3B >=3BPerf on Uerror argua= >bly doesn't matter.
>=3B >=3BIs it only error handling code?Or do so= >ckets often go down "error" paths=3D2C=3D
>=3B >=3B because they are= > slow and you are waiting for more data?
>=3B >=3B=3D20
>=3B &g= >t=3BAnyway=3D2C point is=3D2C I agree for sure this is valuable=3D2C but I = >might be h=3D
>=3B >=3Bitting the "tail" of the approach and should = >switch=3D2C I'm not sure. I keep=3D
>=3B >=3B saying that though=3D2= >C and then press further.
>=3B >=3B=3D20
>=3B >=3B=3D20
&g= >t=3B >=3B - Jay
>=3B >=3B
>=3B >=3B
>=3B >=3B
>= >=3B >=3BFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon=3D2= >C 12 Jan 200=3D
>=3B >=3B9 19:24:50 +1100CC: m3devel at elegosoft.comSu= >bject: Re: [M3devel] declaring a=3D
>=3B >=3B type's existance but n= >ot enough to instantiate it?
>=3B >=3B
>=3B >=3B
>=3B &g= >t=3BPoint taken. We live in a C universe and so need to interact. I do thin= >k =3D
>=3B >=3Byour work with the headers is useful=3D2C and I want = >it to continue. Especia=3D
>=3B >=3Blly in simplifying ports.
>= >=3B >=3B
>=3B >=3B
>=3B >=3BOn 12 Jan 2009=3D2C at 19:18=3D= >2C Jay wrote:
>=3B >=3B
>=3B >=3BI don't think a development = >system without C headers is interesting.. Is it=3D
>=3B >=3B really?= > The transform I apply at times is wherever there is interaction wi=3D
&= >gt=3B >=3Bth C code that is described by system-dependent headers=3D2C or= > perhaps even =3D
>=3B >=3Bfairly system-independent headers outside= > the Modula-3 tree=3D2C either write=3D
>=3B >=3B wrapper functions = >for the functionality in the headers (e.g. stat=3D2C waitp=3D
>=3B >= >=3Bid)=3D2C which can be done in a system-independent way=3D2C or move the = >Modula-=3D
>=3B >=3B3<=3B->=3BC transition higher=3D2C which is = >also usually system-independent=3D2C e.g.=3D
>=3B >=3B ThreadPThread= >C_SetupHandlers. It is either that or clone the headers=3D2C wh=3D
>= >=3B >=3Bich seems like the worse evil. There is always going to be a Modu= >la-3<=3B->=3BC t=3D
>=3B >=3Bransition=3D2C it is just a matter = >of where it occurs. - Jay
>=3B >=3B
>=3B >=3BCC: m3devel at eleg= >osoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.e=3D
>=3B &g= >t=3BduSubject: Re: [M3devel] declaring a type's existance but not enough to= > ins=3D
>=3B >=3Btantiate it?Date: Mon=3D2C 12 Jan 2009 12:32:15 +11= >00
>=3B >=3B
>=3B >=3B
>=3B >=3BJay=3D2C I really thin= >k you are bending over backwards too far just to be abl=3D
>=3B >=3B= >e to shoe-horn things into C. I *like* having the transpar of C header fil= >=3D
>=3B >=3Bes expressed in Modula-3=3D2C *particularly* for system= > calls=3D2C where you mi=3D
>=3B >=3Bght even be trying to build on = >a system that does not have the C header fil=3D
>=3B >=3Bes installe= >d=3D2C even though the libraries exist and can be linked to. Fund=3D
>= >=3B >=3Bamentally=3D2C I think anytime the Modula-3 code is made less tra= >nsparent you=3D
>=3B >=3B should think hard about what you are doing= >. The same with the change of c=3D
>=3B >=3Bonstants to variables.R>>=3B >=3B
>=3B >=3BI am getting very nervous that the changes = >you are making are destroying th=3D
>=3B >=3Be clarity of the Modula= >-3 run-time code.
>=3B >=3B
>=3B >=3BIn this particular case= >=3D2C you are wanting to use a Modula-3 parameter pass=3D
>=3B >=3Bi= >ng mechanism on something that is not declared in Modula-3. Seems kind of= >=3D
>=3B >=3B dubious to me. Also=3D2C I really don't like the idea = >of accessing external=3D
>=3B >=3B variables in C.
>=3B >=3B<= >BR>>=3B >=3B-- Tony
>=3B >=3B
>=3B >=3BOn 12 Jan 2009=3D2= >C at 11:55=3D2C Jay wrote:
>=3B >=3B
>=3B >=3BI considered AD= >DRESS.However I think it still doesn't satisfy. I want to be=3D
>=3B &= >gt=3B able to do this: TYPE Foo_t =3D3D something=3D3B<=3B* EXTERNAL *>= >=3B VAR Foo1=3D2C Foo=3D
>=3B >=3B2:Foo_t=3D3B<=3B* EXTERNAL *>= >=3B PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t)=3D
>=3B >=3B= >=3D3B (* Modula-3=3D2C not external *)PROCEDURE x()=3D3DBEGIN UseFoo(Foo1)= >=3D3B U=3D
>=3B >=3BseFoo(Foo2)=3D3BEND x=3D3B AND I want any use of= >:VAR Foo3:Foo3_t=3D3B (* Modula-3=3D
>=3B >=3B=3D2C not external *)t= >o error. This is sem_t and sigset_t in particular. Poss=3D
>=3B >=3B= >ibly renaming is the thing.They used to be declared in Modula-3=3D2C system= >-d=3D
>=3B >=3Bependently=3D2C butI moved them to portable C. I coul= >d remove the types entir=3D
>=3B >=3Bely and change UseFoo to take a= >n address=3D2Cand declare mask and ackSem to b=3D
>=3B >=3Be integer= >s or I guess.<=3B*EXTERNAL>=3B VAR ackSem : RECORD END=3D3B That would = >sat=3D
>=3B >=3Bisfy but I thought it might be nicer to still provid= >e the namedtypes to ref=3D
>=3B >=3Ber to the external variables. - = >Jay
>=3B >=3B
>=3B >=3BFrom: hosking at cs.purdue.eduTo: jay.kre= >ll at cornell.eduDate: Mon=3D2C 12 Jan 200=3D
>=3B >=3B9 11:13:00 +1100= >CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a=3D
>=3B &g= >t=3B type's existance but not enough to instantiate it?What's wrong with us= >ing =3D
>=3B >=3BADDRESS for references to opaque values? If sigset_= >t is never instantiated=3D
>=3B >=3B in Modula-3=3D2C then why do yo= >u need it declared there?
>=3B >=3B
>=3B >=3B
>=3B >= >=3B
>=3B >=3BAntony Hosking | Associate Professor | Computer Science= > | Purdue University
>=3B >=3B305 N. University Street | West Lafaye= >tte | IN 47907 | USA
>=3B >=3BOffice +1 765 494 6001 | Mobile +1 765= > 427 5484
>=3B >=3B
>=3B >=3B
>=3B >=3BOn 12 Jan 2009= >=3D2C at 01:44=3D2C Jay wrote:
>=3B >=3B
>=3B >=3BIs there a = >way in Modula-3 to declare that a type exists=3D2C and there are <=3B=3D<= >BR>>=3B >=3B*external*>=3B instances of it=3D2C without "fully" decla= >ring it=3D2C so that no M=3D
>=3B >=3Bodula-3 can instantiate it? I = >have done this for sigset_t and sem_t=3D2C but =3D
>=3B >=3Bthey cou= >ld erroneously be instantiated by Modula-3 and I'd like to remove t=3D
&= >gt=3B >=3Bhat ability to mess up so easily. (* This type is not declared = >correctly. I=3D
>=3B >=3Bt is only instantiated in C code. *) sigset= >_t =3D3D RECORD END=3D3B(* This typ=3D
>=3B >=3Be is not declared co= >rrectly. It is only instantiated in C code. *) sem_t =3D
>=3B >=3B= >=3D3D RECORD END=3D3BIn C I believe you can do this=3D2C like: typedef stru= >ct fo=3D
>=3B >=3Bo foo_t=3D3B extern foo_t foo=3D3B void UseFoo(foo= >_t*)=3D3B foo_t* GetFoo=3D
>=3B >=3B(void)=3D3B Thanks=3D2C - Jay=3D= >
>=3B >=3B
>=3B >=3B--_6117a048-9185-4c03-badb-ef8f93402268_<= >BR>>=3B >=3BContent-Type: text/html=3B charset=3D"iso-8859-1"
>=3B= > >=3BContent-Transfer-Encoding: quoted-printable
>=3B >=3B
>= >=3B >=3B<=3Bhtml>=3B
>=3B >=3B<=3Bhead>=3B
>=3B >= >=3B<=3Bstyle>=3B
>=3B >=3B.hmmessage P
>=3B >=3B{
>= >=3B >=3Bmargin:0px=3D3B
>=3B >=3Bpadding:0px
>=3B >=3B}
= >>=3B >=3Bbody.hmmessage
>=3B >=3B{
>=3B >=3Bfont-size: 10= >pt=3D3B
>=3B >=3Bfont-family:Verdana
>=3B >=3B}
>=3B >= >=3B<=3B/style>=3B
>=3B >=3B<=3B/head>=3B
>=3B >=3B<= >=3Bbody class=3D3D'hmmessage'>=3B
>=3B >=3BThis is what you "have = >to" chose between.<=3BBR>=3B
>=3B >=3BHeader cloning or C code (= >and C headers).<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>= >=3B
>=3B >=3BCONST or VAR (or functions?)<=3BBR>=3B
>=3B &g= >t=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BI'm going to likely make= > the Uerror change tonight.<=3BBR>=3B
>=3B >=3BYou can still vet= >o it (er=3D2C vote against it :) )<=3BBR>=3B
>=3B >=3B&=3Bnbs= >p=3D3B<=3BBR>=3B
>=3B >=3BPossibly some convuluted C (enum/#unde= >f)=3D2C or splitting the Modula-3<=3BBR>=3B
>=3B >=3Bat boundari= >es that weren't previously believed "natural".<=3BBR>=3B
>=3B >= >=3B(See how SetupHandlers is ~two lines in Modula-3 and the rest in C=3D3B&= >lt=3BBR>=3B
>=3B >=3Bthis is partly out of ignorance. I don't know= > how to write those<=3BBR>=3B
>=3B >=3Btwo lines in C=3D3B and l= >aziness=3D2C I didn't look into how).<=3BBR>=3B
>=3B >=3B&=3B= >nbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
&= >gt=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BRemember I'm sti= >ll staying away from mainstream platforms=3D2C<=3BBR>=3B
>=3B >= >=3Bso the value isn't what it might appear to be=3D2C but it is "stage sett= >ing"=3D
>=3B >=3B=3D2C<=3BBR>=3B
>=3B >=3Band the show mi= >ght go on. :)<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B<= >BR>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BAlso=3D2C th= >e dilemna does get more difficult now=3D2C with the little C header=3D
&= >gt=3B >=3B cloning that remains.<=3BBR>=3B
>=3B >=3B&=3Bnbs= >p=3D3B<=3BBR>=3B
>=3B >=3BFor example=3D2C look at Upthreads.i3.= ><=3BBR>=3B
>=3B >=3BMainly=3D2C look at function prototypes.<= >=3BBR>=3B
>=3B >=3BConstants and types are "known problems".<=3B= >BR>=3B
>=3B >=3BPrototypes are gray. They actually tend to be port= >able.<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>= >=3B >=3BFor example:<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3B= >BR>=3B
>=3B >=3BTYPE pid_t =3D3D INTEGER=3D3B<=3BBR>=3B
>= >=3B >=3B&=3Blt=3D3B*EXTERNAL "m3_getpid*&=3Bgt=3D3B PROCEDURE getpi= >d():pid_t=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B= >
>=3B >=3Bor leave it alone?<=3BBR>=3B
>=3B >=3Bgetpid is= > probably the worst example.<=3BBR>=3B
>=3B >=3BIt is so very po= >rtable declared in Modula-3.<=3BBR>=3B
>=3B >=3BBut still=3D2C i= >magine pid_t might be 16bits or 32 or 64.<=3BBR>=3B
>=3B >=3BWri= >ting a wrapper is more portable -- as long as the pid isn't stuff into s=3D= >
>=3B >=3Bome record that the system defines.<=3BBR>=3B
>= >=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B&l= >t=3BBR>=3B
>=3B >=3BAgain=3D2C Upthreads.i3.<=3BBR>=3B
>= >=3B >=3BWould you like to see it reduced=3D2C or left alone?<=3BBR>= >=3B
>=3B >=3BOnly deal with the types and initializers=3D2C or also = >the prototypes?<=3BBR>=3B
>=3B >=3BYou know=3D2C I could write a= > little portable layer=3D2C where all the types ar=3D
>=3B >=3Be poi= >nters=3D2C always null initialized.<=3BBR>=3B
>=3B >=3BIt would = >buy /some/ portability=3D2C and cost some.<=3BBR>=3B
>=3B >=3B&a= >mp=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B= >
>=3B >=3BDo you like the sem_t change? Partly? Not at all?<=3BBR&= >gt=3B
>=3B >=3BThere is one sem_t in the system. So I moved it to be= > in C code.<=3BBR>=3B
>=3B >=3BOr=3D2C as I had it before=3D2C d= >eclared as the max size/align of all the platf=3D
>=3B >=3Borms -- g= >etting that right is the same work as getting it right "the old wa=3D
&g= >t=3B >=3By"=3D2C except if you make a mistake=3D2C odds are still good of= > it being ok.<=3BB=3D
>=3B >=3BR>=3B
>=3B >=3B&=3Bnbsp= >=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>= >=3B >=3BShould the line be drawn at generating the remaining headers=3D2C= > rather than=3D
>=3B >=3B eliminating them?<=3BBR>=3B
>=3B = >>=3BUerror.i3 is easily generated. Good enough?<=3BBR>=3B
>=3B &= >gt=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BUpthread.i3's types can= > be generated generally as records with opaque array=3D
>=3B >=3Bs w= >ith the right size and alignment.<=3BBR>=3B
>=3B >=3B&=3Bnbsp= >=3D3B<=3BBR>=3B
>=3B >=3BOther stuff can be generated or at leas= >t checked.<=3BBR>=3B
>=3B >=3Be.g. to check that getpid is decla= >red correctly=3D2C you can assign it to a f=3D
>=3B >=3Bunction poin= >ter and see if that compiles.<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3= >B<=3BBR>=3B
>=3B >=3BPerf on Uerror arguably doesn't matter.<= >=3BBR>=3B
>=3B >=3BIs it only error handling code?<=3BBR>=3BOr= > do sockets often go down "error" path=3D
>=3B >=3Bs=3D2C because th= >ey are slow and you are waiting for more data?<=3BBR>=3B
>=3B >= >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BAnyway=3D2C point is=3D2C= > I agree for sure this is valuable=3D2C but I might be h=3D
>=3B >= >=3Bitting the "tail" of the approach and should switch=3D2C I'm not sure. I= > keep=3D
>=3B >=3B saying that though=3D2C and then press further.&l= >t=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >= >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B- Jay<= >=3BBR>=3B<=3BBR>=3B
>=3B >=3B
>=3B >=3B<=3BHR id=3D3D= >stopSpelling>=3B
>=3B <=3BBR>=3B
>=3B >=3BFrom: hosking at c= >s.purdue.edu<=3BBR>=3BTo: jay.krell at cornell.edu<=3BBR>=3BDate: Mon= >=3D2C 12=3D
>=3B >=3B Jan 2009 19:24:50 +1100<=3BBR>=3BCC: m3dev= >el at elegosoft.com<=3BBR>=3BSubject: Re: [M3de=3D
>=3B >=3Bvel] de= >claring a type's existance but not enough to instantiate it?<=3BBR>=3B&= >lt=3BBR>=3B=3D
>=3B >=3B<=3BBR>=3B
>=3B >=3B<=3BDIV&g= >t=3B<=3BSPAN class=3D3DEC_Apple-style-span style=3D3D"WORD-SPACING: 0px= >=3D3B FONT: =3D
>=3B >=3B12px Helvetica=3D3B TEXT-TRANSFORM: none=3D= >3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-IND=3D
>=3B >=3BENT: 0px=3D3B= > WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPS=3D
= >>=3B >=3BE: separate">=3B
>=3B >=3B<=3BDIV style=3D3D"WORD-W= RAP: break-word">=3B<=3BSPAN class=3D3DEC_Apple-style-span styl=3D
&= >gt=3B >=3Be=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TR= >ANSFORM: none=3D3B C=3D
>=3B >=3BOLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-= >INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-S=3D
>=3B >=3BPACIN= >G: normal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=3D3DEC_Appl= >e-style-s=3D
>=3B >=3Bpan style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12= >px Helvetica=3D3B TEXT-TRANSFORM: n=3D
>=3B >=3Bone=3D3B COLOR: rgb(= >0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B =3D
&= >gt=3B >=3BLETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate">=3B<= >=3BSPAN class=3D3DEC_Apple=3D
>=3B >=3B-style-span style=3D3D"WORD-S= >PACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRAN=3D
>=3B >=3BSFO= >RM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SP= >ACE: no=3D
>=3B >=3Brmal=3D3B LETTER-SPACING: normal=3D3B BORDER-COL= >LAPSE: separate">=3B<=3BSPAN class=3D3D=3D
>=3B >=3BEC_Apple-sty= >le-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B T=3D>>=3B >=3BEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-= >INDENT: 0px=3D3B WHITE-S=3D
>=3B >=3BPACE: normal=3D3B LETTER-SPACIN= >G: normal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN =3D
>=3B >= >=3Bclass=3D3DEC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12= >px Helvet=3D
>=3B >=3Bica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(= >0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B=3D
>=3B >=3B WHITE-SPACE: = >normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate=3D
>= >=3B >=3B">=3B<=3BSPAN class=3D3DEC_Apple-style-span style=3D3D"WORD-S= >PACING: 0px=3D3B FONT: 12p=3D
>=3B >=3Bx Helvetica=3D3B TEXT-TRANSFO= >RM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT=3D
>=3B >= >=3B: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-C= >OLLAPSE: =3D
>=3B >=3Bseparate">=3B<=3BSPAN class=3D3DEC_Apple-s= >tyle-span style=3D3D"WORD-SPACING: 0px=3D3B F=3D
>=3B >=3BONT: 12px = >Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEX= >=3D
>=3B >=3BT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPAC= >ING: normal=3D3B BORDER-CO=3D
>=3B >=3BLLAPSE: separate">=3B<=3B= >SPAN class=3D3DEC_Apple-style-span style=3D3D"WORD-SPACING: =3D
>=3B &= >gt=3B0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rg= >b(0=3D2C0=3D2C0=3D
>=3B >=3B)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE= >: normal=3D3B LETTER-SPACING: normal=3D3B B=3D
>=3B >=3BORDER-COLLAP= >SE: separate">=3B
>=3B >=3B<=3BDIV>=3BPoint taken. &=3Bnbsp= >=3D3BWe live in a C universe and so need to interact. =3D
>=3B >=3B&= >amp=3Bnbsp=3D3BI do think your work with the headers is useful=3D2C and I w= >ant it to=3D
>=3B >=3B continue. &=3Bnbsp=3D3BEspecially in simpl= >ifying ports.<=3B/DIV>=3B
>=3B >=3B<=3BDIV>=3B<=3BBR>=3B= ><=3B/DIV>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/S= >PAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>= >=3B<=3B/DI=3D
>=3B >=3BV>=3B<=3B/SPAN>=3B<=3B/DIV>=3B>>=3B >=3B<=3BDIV>=3B
>=3B >=3B<=3BDIV>=3BOn 12 Jan 2009= >=3D2C at 19:18=3D2C Jay wrote:<=3B/DIV>=3B<=3BBR class=3D3DEC_Apple-i= >nt=3D
>=3B >=3Berchange-newline>=3B
>=3B >=3B<=3BBLOCKQUO= >TE>=3B<=3BSPAN class=3D3DEC_Apple-style-span style=3D3D"WORD-SPACING: 0= >px=3D3B=3D
>=3B >=3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none= >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B T=3D
>=3B >=3BEXT-INDENT: 0px= >=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-=3D
&g= >t=3B >=3BCOLLAPSE: separate">=3B
>=3B >=3B<=3BDIV class=3D3DEC= >_hmmessage style=3D3D"FONT-SIZE: 10pt=3D3B FONT-FAMILY: Verdana"=3D
>= >=3B >=3B>=3BI don't think a development system without C headers is int= >eresting.. Is i=3D
>=3B >=3Bt really?<=3BBR>=3B&=3Bnbsp=3D3B&= >lt=3BBR>=3BThe transform I apply at times is wherever there i=3D
>= >=3B >=3Bs interaction with C code that is described by system-dependent h= >eaders=3D2C =3D
>=3B >=3Bor perhaps even fairly system-independent h= >eaders outside the Modula-3 tree=3D
>=3B >=3B=3D2C either write wrap= >per functions for the functionality in the headers (e.=3D
>=3B >=3Bg= >. stat=3D2C waitpid)=3D2C which&=3Bnbsp=3D3Bcan be done in a system-inde= >pendent way=3D
>=3B >=3B=3D2C&=3Bnbsp=3D3Bor move the Modula-3&am= >p=3Blt=3D3B-&=3Bgt=3D3BC transition higher=3D2C which is=3D
>=3B &g= >t=3B also usually system-independent=3D2C e.g. ThreadPThreadC_SetupHandlers= >.<=3BBR>=3B&=3B=3D
>=3B >=3Bnbsp=3D3B<=3BBR>=3BIt is eith= >er that or clone the headers=3D2C which seems like the w=3D
>=3B >= >=3Borse evil.<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3BThere is always go= >ing to be a Modula-3&=3Blt=3D3B-&=3Bgt=3D
>=3B >=3B=3D3BC tran= >sition=3D2C it is just a matter of where it occurs.<=3BBR>=3B&=3Bnbs= >p=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bnbsp=3D3B- Jay<=3BBR>=3B= ><=3BBR>=3B
>=3B >=3B<=3BHR id=3D3DEC_stopSpelling>=3B
>= >=3B >=3B<=3BBR>=3BCC:<=3BSPAN class=3D3DEC_Apple-converted-space>= >=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BA href=3D3D"mai=3D
>=3B >= >=3Blto:m3devel at elegosoft.com">=3Bm3devel at elegosoft.com<=3B/A>=3B<= >=3BBR>=3BFrom:<=3BSPAN class=3D3D=3D
>=3B >=3BEC_Apple-converted= >-space>=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BA href=3D3D"mailto:hoski= >ng at cs.purdue=3D
>=3B >=3B.edu">=3Bhosking at cs.purdue.edu<=3B/A>= >=3B<=3BBR>=3BTo:<=3BSPAN class=3D3DEC_Apple-converted-spac=3D
>= >=3B >=3Be>=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BA href=3D3D"mailto:= >jay.krell at cornell.edu">=3Bjay.krell at cornell=3D
>=3B >=3B.edu<=3B= >/A>=3B<=3BBR>=3BSubject: Re: [M3devel] declaring a type's existance b= >ut not eno=3D
>=3B >=3Bugh to instantiate it?<=3BBR>=3BDate: Mon= >=3D2C 12 Jan 2009 12:32:15 +1100<=3BBR>=3B<=3BBR>=3B<=3BB=3D
&= >gt=3B >=3BR>=3B
>=3B <=3BDIV>=3B<=3BSPAN class=3D3DEC_EC_App= >le-style-span style=3D3D"WORD-SPACING: 0px=3D3B FON=3D
>=3B >=3BT: 1= >2px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B= > TEXT-=3D
>=3B >=3BINDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-= >SPACING: normal=3D3B BORDER-COLL=3D
>=3B >=3BAPSE: separate">=3BR>>=3B >=3B<=3BDIV style=3D3D"WORD-WRAP: break-word">=3B<=3BSPAN = >class=3D3DEC_EC_Apple-style-span s=3D
>=3B >=3Btyle=3D3D"WORD-SPACIN= >G: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D
>=3B >= >=3B=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: = >normal=3D3B LET=3D
>=3B >=3BTER-SPACING: normal=3D3B BORDER-COLLAPSE= >: separate">=3B<=3BSPAN class=3D3DEC_EC_Apple=3D
>=3B >=3B-style= >-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRAN= >=3D
>=3B >=3BSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-IN= >DENT: 0px=3D3B WHITE-SPACE: no=3D
>=3B >=3Brmal=3D3B LETTER-SPACING:= > normal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=3D3D=3D
&g= >t=3B >=3BEC_EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 1= >2px Helvetica=3D
>=3B >=3B=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb= >(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WH=3D
>=3B >=3BITE-SPACE:= > normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate">=3B&l= >t=3B=3D
>=3B >=3BSPAN class=3D3DEC_EC_Apple-style-span style=3D3D"WO= >RD-SPACING: 0px=3D3B FONT: 12p=3D
>=3B >=3Bx Helvetica=3D3B TEXT-TRA= >NSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT=3D
>=3B &= >gt=3B: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER= >-COLLAPSE: =3D
>=3B >=3Bseparate">=3B<=3BSPAN class=3D3DEC_EC_Ap= >ple-style-span style=3D3D"WORD-SPACING: 0px=3D
>=3B >=3B=3D3B FONT: = >12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D<= >BR>>=3B >=3B=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER= >-SPACING: normal=3D3B BO=3D
>=3B >=3BRDER-COLLAPSE: separate">=3B&= >lt=3BSPAN class=3D3DEC_EC_Apple-style-span style=3D3D"WORD=3D
>=3B >= >=3B-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B C= >OLOR: rgb=3D
>=3B >=3B(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHI= >TE-SPACE: normal=3D3B LETTER-SPACING: n=3D
>=3B >=3Bormal=3D3B BORDE= >R-COLLAPSE: separate">=3B<=3BSPAN class=3D3DEC_EC_Apple-style-span st= >=3D
>=3B >=3Byle=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D= >3B TEXT-TRANSFORM: none=3D3B=3D
>=3B >=3B COLOR: rgb(0=3D2C0=3D2C0)= >=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER=3D
>=3B &g= >t=3B-SPACING: normal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class= >=3D3DEC_EC_Apple-st=3D
>=3B >=3Byle-span style=3D3D"WORD-SPACING: 0p= >x=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFO=3D
>=3B >=3BRM: none= >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: nor= >ma=3D
>=3B >=3Bl=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: s= >eparate">=3B
>=3B >=3B<=3BDIV>=3BJay=3D2C I really think you a= >re bending over backwards too far just to b=3D
>=3B >=3Be able to sh= >oe-horn things into C. &=3Bnbsp=3D3BI *like* having the transpar of =3D<= >BR>>=3B >=3BC header files expressed in Modula-3=3D2C *particularly* fo= >r system calls=3D2C =3D
>=3B >=3Bwhere you might even be trying to b= >uild on a system that does not have the =3D
>=3B >=3BC header files = >installed=3D2C even though the libraries exist and can be link=3D
>=3B= > >=3Bed to. &=3Bnbsp=3D3BFundamentally=3D2C I think anytime the Modula= >-3 code is made l=3D
>=3B >=3Bess transparent you should think hard = >about what you are doing. &=3Bnbsp=3D3BThe=3D
>=3B >=3B same with= > the change of constants to variables.<=3B/DIV>=3B
>=3B >=3B<= >=3BDIV>=3B<=3BBR>=3B<=3B/DIV>=3B
>=3B >=3B<=3BDIV>=3BI= > am getting very nervous that the changes you are making are destroyi=3D>>=3B >=3Bng the clarity of the Modula-3 run-time code.<=3B/DIV>=3B= >
>=3B >=3B<=3BDIV>=3B<=3BBR>=3B<=3B/DIV>=3B
>=3B &g= >t=3B<=3BDIV>=3BIn this particular case=3D2C you are wanting to use a Mo= >dula-3 parameter=3D
>=3B >=3B passing mechanism on something that is= > not declared in Modula-3. &=3Bnbsp=3D3BS=3D
>=3B >=3Beems kind o= >f dubious to me. &=3Bnbsp=3D3BAlso=3D2C I really don't like the idea of= >=3D
>=3B >=3B accessing external variables in C.<=3B/DIV>=3B
= >>=3B >=3B<=3BDIV>=3B<=3BBR>=3B<=3B/DIV>=3B
>=3B >=3B= ><=3BDIV>=3B-- Tony<=3B/DIV>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<= >=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPA= >N>=3B<=3B/SPAN>=3B<=3B=3D
>=3B >=3B/DIV>=3B<=3B/SPAN>= >=3B<=3B/DIV>=3B<=3BBR>=3B
>=3B >=3B<=3BDIV>=3B
>=3B= > >=3B<=3BDIV>=3BOn 12 Jan 2009=3D2C at 11:55=3D2C Jay wrote:<=3B/DI= >V>=3B<=3BBR class=3D3DEC_EC_Apple-=3D
>=3B >=3Binterchange-newli= >ne>=3B
>=3B >=3B<=3BBLOCKQUOTE>=3B<=3BSPAN class=3D3DEC_EC_A= >pple-style-span style=3D3D"WORD-SPACING: 0px=3D
>=3B >=3B=3D3B FONT:= > 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D= >
>=3B >=3B=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTE= >R-SPACING: normal=3D3B BO=3D
>=3B >=3BRDER-COLLAPSE: separate">=3B= >
>=3B >=3B<=3BDIV class=3D3DEC_EC_hmmessage style=3D3D"FONT-SIZE: = >10pt=3D3B FONT-FAMILY: Verda=3D
>=3B >=3Bna">=3BI considered ADDRE= >SS.<=3BBR>=3BHowever I think it still doesn't satisfy.<=3BBR>=3B&am= >p=3B=3D
>=3B >=3Bnbsp=3D3B<=3BBR>=3BI want to be able to do this= >:<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3BTYPE&=3Bnbsp=3D3BFoo_t =3D<= >BR>>=3B >=3B=3D3D something=3D3B<=3BBR>=3B&=3Blt=3D3B* EXTERNAL = >*&=3Bgt=3D3B VAR Foo1=3D2C Foo2:Foo_t=3D3B<=3BBR>=3B&=3B=3D
&g= >t=3B >=3Blt=3D3B* EXTERNAL *&=3Bgt=3D3B PROCEDURE&=3Bnbsp=3D3BUseFo= >o(READONLY (* or VAR *) foo:F=3D
>=3B >=3Boo_t)=3D3B<=3BBR>=3B&a= >mp=3Bnbsp=3D3B<=3BBR>=3B(* Modula-3=3D2C not external *)<=3BBR>=3BP= >ROCEDURE x()=3D3D<=3B=3D
>=3B >=3BBR>=3BBEGIN<=3BBR>=3B&= >=3Bnbsp=3D3B UseFoo(Foo1)=3D3B<=3BBR>=3B&=3Bnbsp=3D3B UseFoo(Foo2)= >=3D3B<=3BBR>=3BEND x=3D
>=3B >=3B=3D3B<=3BBR>=3B&=3Bnbsp= >=3D3B<=3BBR>=3BAND I want any use of:<=3BBR>=3BVAR Foo3:Foo3_t=3D3B= > (* Modula-3=3D
>=3B >=3B=3D2C not external *)<=3BBR>=3B<=3BBR= >>=3Bto error. This is sem_t and sigset_t in particul=3D
>=3B >=3Ba= >r.<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3BPossibly renaming is the thin= >g.<=3BBR>=3BThey used to be decla=3D
>=3B >=3Bred in Modula-3=3D= >2C system-dependently=3D2C but<=3BBR>=3BI moved them to portable C.=3D<= >BR>>=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3BI could remove = >the types entirely and change UseFoo to take=3D
>=3B >=3B an address= >=3D2C<=3BBR>=3Band declare mask and ackSem to be integers or I guess.&l= >t=3BBR=3D
>=3B >=3B>=3B&=3Blt=3D3B*EXTERNAL&=3Bgt=3D3B VAR a= >ckSem&=3Bnbsp=3D3B: RECORD END=3D3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BB= >R>=3BTha=3D
>=3B >=3Bt would satisfy but I thought it might be nic= >er to still provide the named<=3B=3D
>=3B >=3BBR>=3Btypes to ref= >er to the external variables.<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B&a= >mp=3Bnbsp=3D3B- Jay<=3BB=3D
>=3B >=3BR>=3B<=3BBR>=3B
>= >=3B >=3B<=3BHR id=3D3DEC_EC_stopSpelling>=3B
>=3B >=3B<=3BBR= >>=3BFrom:<=3BSPAN class=3D3DEC_EC_Apple-converted-space>=3B&=3Bnbs= >p=3D3B<=3B/SPAN>=3B<=3BA href=3D
>=3B >=3B=3D3D"mailto:hosking= >@cs.purdue.edu">=3Bhosking at cs.purdue.edu<=3B/A>=3B<=3BBR>=3BTo:&l= >t=3BSPAN cla=3D
>=3B >=3Bss=3D3DEC_EC_Apple-converted-space>=3B&am= >p=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BA href=3D3D"mailto:jay.krell=3D
>= >=3B >=3B at cornell.edu">=3Bjay.krell at cornell.edu<=3B/A>=3B<=3BBR>= >=3BDate: Mon=3D2C 12 Jan 2009 11:13:0=3D
>=3B >=3B0 +1100<=3BBR>= >=3BCC:<=3BSPAN class=3D3DEC_EC_Apple-converted-space>=3B&=3Bnbsp=3D3= >B<=3B/SPAN>=3B<=3BA h=3D
>=3B >=3Bref=3D3D"mailto:m3devel at eleg= >osoft.com">=3Bm3devel at elegosoft.com<=3B/A>=3B<=3BBR>=3BSubject: = >=3D
>=3B >=3BRe: [M3devel] declaring a type's existance but not enou= >gh to instantiate it=3D
>=3B >=3B?<=3BBR>=3B<=3BBR>=3BWhat's= > wrong with using ADDRESS for references to opaque values? &=3B=3D
&g= >t=3B >=3Bnbsp=3D3BIf sigset_t is never instantiated in Modula-3=3D2C then= > why do you nee=3D
>=3B >=3Bd it declared there?<=3BBR>=3B
&g= >t=3B >=3B<=3BDIV>=3B<=3BBR>=3B
>=3B >=3B<=3BDIV>=3B<= >=3BSPAN class=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D= >3B =3D
>=3B >=3BFONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B = >COLOR: rgb(0=3D2C0=3D2C0)=3D3B TE=3D
>=3B >=3BXT-INDENT: 0px=3D3B WH= >ITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-C=3D
>=3B &g= >t=3BOLLAPSE: separate">=3B
>=3B >=3B<=3BDIV style=3D3D"WORD-WRAP= >: break-word">=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-spa=3D
>= >=3B >=3Bn style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEX= >T-TRANSFORM: non=3D
>=3B >=3Be=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B T= >EXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LE=3D
>=3B >=3BTTER-SP= >ACING: normal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=3D3DEC_= >EC_EC_A=3D
>=3B >=3Bpple-style-span style=3D3D"WORD-SPACING: 0px=3D3= >B FONT: 12px Helvetica=3D3B TEXT-=3D
>=3B >=3BTRANSFORM: none=3D3B C= >OLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE=3D
>= >=3B >=3B: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separa= >te">=3B<=3BSPAN clas=3D
>=3B >=3Bs=3D3DEC_EC_EC_Apple-style-span= > style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helv=3D
>=3B >=3Betica= >=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT:= > 0px=3D
>=3B >=3B=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: norm= >al=3D3B BORDER-COLLAPSE: separ=3D
>=3B >=3Bate">=3B<=3BSPAN clas= >s=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B =3D
&g= >t=3B >=3BFONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0= >=3D2C0=3D2C0)=3D3B TE=3D
>=3B >=3BXT-INDENT: 0px=3D3B WHITE-SPACE: n= >ormal=3D3B LETTER-SPACING: normal=3D3B BORDER-C=3D
>=3B >=3BOLLAPSE:= > separate">=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-span style=3D3D"W= >ORD-SP=3D
>=3B >=3BACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TR= >ANSFORM: none=3D3B COLOR: rgb(0=3D
>=3B >=3B=3D2C0=3D2C0)=3D3B TEXT-= >INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: nor=3D
>=3B = >>=3Bmal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=3D3DEC_EC_E= >C_Apple-style-span s=3D
>=3B >=3Btyle=3D3D"WORD-SPACING: 0px=3D3B FO= >NT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D
>=3B >=3B=3D3B COLOR= >: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LE= >T=3D
>=3B >=3BTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate">= >=3B<=3BSPAN class=3D3DEC_EC_EC_Ap=3D
>=3B >=3Bple-style-span style= >=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-T=3D
>=3B = >>=3BRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px= >=3D3B WHITE-SPACE:=3D
>=3B >=3B normal=3D3B LETTER-SPACING: normal= >=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=3D
>=3B >=3B= >=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px= > Helve=3D
>=3B >=3Btica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0= >=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D
>=3B >=3B=3D3B WHITE-SPACE: n= >ormal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separ=3D
>=3B = >>=3Bate">=3B
>=3B >=3B<=3BDIV>=3B<=3BFONT class=3D3DEC_EC_= >EC_Apple-style-span color=3D3D#0000ff>=3B<=3BFONT class=3D3D=3D
>= >=3B >=3BEC_EC_EC_Apple-style-span face=3D3D"Gill Sans">=3B<=3BSPAN cl= >ass=3D3DEC_EC_EC_Apple-s=3D
>=3B >=3Btyle-span style=3D3D"COLOR: rgb= >(0=3D2C0=3D2C255)=3D3B FONT-FAMILY: 'Gill Sans'">=3B<=3BSP=3D
>=3B= > >=3BAN class=3D3DEC_EC_EC_Apple-style-span style=3D3D"COLOR: rgb(0=3D2C0= >=3D2C255)=3D3B FO=3D
>=3B >=3BNT-FAMILY: 'Gill Sans'">=3BAntony Ho= >sking<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/FONT>=3B<=3B/FONT>=3B&l= >t=3BFONT cla=3D
>=3B >=3Bss=3D3DEC_EC_EC_Apple-style-span face=3D3D"= >Gill Sans">=3B<=3BSPAN class=3D3DEC_EC_EC_Ap=3D
>=3B >=3Bple-sty= >le-span style=3D3D"FONT-FAMILY: 'Gill Sans'">=3B<=3BSPAN class=3D3DEC_E= >C_EC_Ap=3D
>=3B >=3Bple-style-span style=3D3D"FONT-FAMILY: 'Gill San= >s'">=3B<=3BSPAN class=3D3DEC_EC_Apple=3D
>=3B >=3B-converted-spa= >ce>=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B|<=3BSPAN class=3D3DEC_EC_Apple-= >converted-space>=3B=3D
>=3B >=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B&= >lt=3B/SPAN>=3B<=3B/SPAN>=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-= >span style=3D
>=3B >=3B=3D3D"FONT-FAMILY: 'Gill Sans'">=3B<=3BSP= >AN class=3D3DEC_EC_EC_Apple-style-span style=3D
>=3B >=3B=3D3D"FONT-= >FAMILY: 'Gill Sans'">=3BAssociate Professor<=3B/SPAN>=3B<=3B/SPAN&g= >t=3B<=3BSPAN class=3D
>=3B >=3B=3D3DEC_EC_EC_Apple-style-span styl= >e=3D3D"FONT-FAMILY: 'Gill Sans'">=3B<=3BSPAN class=3D
>=3B >=3B= >=3D3DEC_EC_EC_Apple-style-span style=3D3D"FONT-FAMILY: 'Gill Sans'">=3B&a= >mp=3Bnbsp=3D3B| C=3D
>=3B >=3Bomputer Science | Purdue University<= >=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/FONT>=3B<=3B/DIV>=3B
>=3B = >>=3B<=3BDIV>=3B<=3BFONT class=3D3DEC_EC_EC_Apple-style-span face=3D= >3DGillSans-Light>=3B<=3BSPAN cl=3D
>=3B >=3Bass=3D3DEC_EC_EC_App= >le-style-span style=3D3D"FONT-FAMILY: GillSans-Light">=3B305 N=3D
>= >=3B >=3B. University Street | West Lafayette | IN 47907 | USA<=3B/SPAN&= >gt=3B<=3B/FONT>=3B<=3B/DIV>=3B
>=3B >=3B<=3BDIV>=3B<= >=3BFONT class=3D3DEC_EC_EC_Apple-style-span face=3D3D"Gill Sans" color=3D3D= >#00=3D
>=3B >=3B00ff>=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-= >span style=3D3D"COLOR: rgb(0=3D2C0=3D2C25=3D
>=3B >=3B5)=3D3B FONT-F= >AMILY: 'Gill Sans'">=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-span sty= >=3D
>=3B >=3Ble=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=3D3B FONT-FAMILY: '= >Gill Sans'">=3BOffice<=3B/SPAN>=3B<=3B/S=3D
>=3B >=3BPAN>= >=3B<=3B/FONT>=3B<=3BFONT class=3D3DEC_EC_EC_Apple-style-span face=3D3= >DGillSans-Light>=3B<=3BS=3D
>=3B >=3BPAN class=3D3DEC_EC_EC_Appl= >e-style-span style=3D3D"FONT-FAMILY: GillSans-Light"=3D
>=3B >=3B>= >=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-span style=3D3D"FONT-FAMILY: G= >illSans-Lig=3D
>=3B >=3Bht">=3B&=3Bnbsp=3D3B+1 765 494 6001 |&l= >t=3BSPAN class=3D3DEC_EC_Apple-converted-space>=3B&=3Bnbs=3D
>=3B= > >=3Bp=3D3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/FONT= >>=3B<=3BFONT class=3D3DEC_EC_EC_Apple-style-span fac=3D
>=3B >= >=3Be=3D3D"Gill Sans" color=3D3D#0000ff>=3B<=3BSPAN class=3D3DEC_EC_EC_A= >pple-style-span sty=3D
>=3B >=3Ble=3D3D"COLOR: rgb(0=3D2C0=3D2C255)= >=3D3B FONT-FAMILY: 'Gill Sans'">=3B<=3BSPAN class=3D3DEC=3D
>=3B &= >gt=3B_EC_EC_Apple-style-span style=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=3D3B FO= >NT-FAMILY: 'G=3D
>=3B >=3Bill Sans'">=3BMobile<=3B/SPAN>=3B<= >=3B/SPAN>=3B<=3B/FONT>=3B<=3BFONT class=3D3DEC_EC_EC_Apple-style-sp= >=3D
>=3B >=3Ban face=3D3DGillSans-Light>=3B<=3BSPAN class=3D3DEC= >_EC_EC_Apple-style-span style=3D3D"F=3D
>=3B >=3BONT-FAMILY: GillSan= >s-Light">=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-span style=3D
&g= >t=3B >=3B=3D3D"FONT-FAMILY: GillSans-Light">=3B<=3BSPAN class=3D3DEC_= >EC_Apple-converted-space>=3B=3D
>=3B >=3B&=3Bnbsp=3D3B<=3B/SP= >AN>=3B+1 765 427 5484<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/FONT>=3B&= >lt=3B/DIV>=3B
>=3B >=3B<=3BDIV>=3B<=3BFONT class=3D3DEC_EC_E= >C_Apple-style-span face=3D3DGillSans-Light>=3B<=3BBR clas=3D
>=3B = >>=3Bs=3D3DEC_EC_EC_khtml-block-placeholder>=3B<=3B/FONT>=3B<=3B/D= >IV>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SP=3D
= >>=3B >=3BAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<= >=3BBR class=3D3DEC_EC_EC_Apple-interchange-newline>=3B<=3B/SP=3D
>= >=3B >=3BAN>=3B<=3B/DIV>=3B<=3B/SPAN>=3B<=3B/DIV>=3B<=3BBR= >>=3B
>=3B >=3B<=3BDIV>=3B
>=3B >=3B<=3BDIV>=3BOn 12= > Jan 2009=3D2C at 01:44=3D2C Jay wrote:<=3B/DIV>=3B<=3BBR class=3D3DE= >C_EC_EC_App=3D
>=3B >=3Ble-interchange-newline>=3B
>=3B >= >=3B<=3BBLOCKQUOTE>=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-span sty= >le=3D3D"WORD-SPACING: =3D
>=3B >=3B0px=3D3B FONT: 12px Helvetica=3D3= >B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0=3D
>=3B >=3B)= >=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal= >=3D3B B=3D
>=3B >=3BORDER-COLLAPSE: separate">=3B
>=3B >=3B= ><=3BDIV class=3D3DEC_EC_EC_hmmessage style=3D3D"FONT-SIZE: 10pt=3D3B FONT= >-FAMILY: Ve=3D
>=3B >=3Brdana">=3BIs there a way in Modula-3 to de= >clare that&=3Bnbsp=3D3Ba type exists=3D2C a=3D
>=3B >=3Bnd there = >are &=3Blt=3D3B*external*&=3Bgt=3D3B instances of it=3D2C without "fu= >lly" decl=3D
>=3B >=3Baring it=3D2C so that no Modula-3 can instanti= >ate it?<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3BI have d=3D
>=3B &g= >t=3Bone this for sigset_t and sem_t=3D2C but they could erroneously be inst= >antiat=3D
>=3B >=3Bed by Modula-3 and I'd like to remove that abilit= >y to mess up so easily.<=3BBR=3D
>=3B >=3B>=3B&=3Bnbsp=3D3B&l= >t=3BBR>=3B(* This type is not declared correctly. It is only instantiate= >=3D
>=3B >=3Bd in C code. *)<=3BBR>=3B&=3Bnbsp=3D3B sigset_t = >=3D3D RECORD END=3D3B<=3BBR>=3B<=3BBR>=3B(* This type =3D
>=3B= > >=3Bis not declared correctly. It is only instantiated in C code. *)<= >=3BBR>=3B&=3Bnbsp=3D
>=3B >=3B=3D3B sem_t =3D3D RECORD END=3D3B= ><=3BBR>=3B<=3BBR>=3BIn C I believe you can do this=3D2C like:<=3B= >=3D
>=3B >=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3Btypedef struct = >foo foo_t=3D3B&=3Bnbsp=3D3B<=3BSPAN class=3D3DEC_EC_E=3D
>=3B >= >=3BC_Apple-converted-space>=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BBR&g= >t=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3Bextern foo_t foo=3D
>=3B >=3B=3D= >3B&=3Bnbsp=3D3B<=3BSPAN class=3D3DEC_EC_EC_Apple-converted-space>=3B= >&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BBR>=3B=3D
>=3B >=3B&=3Bn= >bsp=3D3B<=3BBR>=3B&=3Bnbsp=3D3Bvoid UseFoo(foo_t*)=3D3B<=3BSPAN cl= >ass=3D3DEC_EC_EC_Apple-conv=3D
>=3B >=3Berted-space>=3B&=3Bnbsp= >=3D3B<=3B/SPAN>=3B<=3BBR>=3B&=3Bnbsp=3D3B foo_t* GetFoo(void)=3D= >3B<=3BSPAN class=3D
>=3B >=3B=3D3DEC_EC_EC_Apple-converted-space&g= >t=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR= >>=3BThanks=3D2C<=3B=3D
>=3B >=3BBR>=3B&=3Bnbsp=3D3B- Jay<= >=3BBR>=3B<=3BBR>=3B<=3BBR>=3B<=3BBR>=3B<=3B/DIV>=3B<=3B= >/SPAN>=3B<=3B/BLOCKQUOTE>=3B<=3B/DIV>=3B<=3BBR>=3B<=3B/DIV&= >gt=3B<=3B=3D
>=3B >=3B/DIV>=3B<=3B/SPAN>=3B<=3BBR class=3D= >3DEC_EC_Apple-interchange-newline>=3B<=3B/BLOCKQUOTE>=3B<=3B/DIV>= >=3B=3D
>=3B >=3B<=3BBR>=3B<=3B/DIV>=3B<=3B/SPAN>=3B<= >=3BBR class=3D3DEC_Apple-interchange-newline>=3B<=3B/BLOCKQUOTE>=3B&l= >t=3B/DI=3D
>=3B >=3BV>=3B<=3BBR>=3B<=3B/body>=3B
>=3B= > >=3B<=3B/html>=3B=3D
>=3B >=3B
>=3B >=3B--_6117a048-91= >85-4c03-badb-ef8f93402268_--

>= > >--_2e194b09-14b6-4301-9116-a9e4d1e522b4_-- From jay.krell at cornell.edu Mon Jan 12 11:24:37 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 10:24:37 +0000 Subject: [M3devel] declaring a type's existance but not enough to instantiate it? In-Reply-To: <200901121013.n0CADQE0075969@camembert.async.caltech.edu> References: Your message of "Mon, 12 Jan 2009 09:56:43 GMT." <200901121013.n0CADQE0075969@camembert.async.caltech.edu> Message-ID: I don't at this time want to write C a parser. (Actually I do, as part of an entire compiler, but...) I'd rather run the one I already have -- the C compiler. I briefly in the past dreamt that C programmers might start writing "xml" (schema?!) or "idl". Oh, and you can't rely on headers being written in an easy to parse C subset. There are inlines, #pragmas, compiler-specific extensions, etc. Best just to use them as part of compiling C with the intended compiler. Well, I have parsed C subsets actually..more than once. One didn't really have to be very complete. One "lived" with the headers and there was flexibility to fix the headers to suit. - Jay> To: jay.krell at cornell.edu> Date: Mon, 12 Jan 2009 02:13:25 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?> > > I think you're misunderstanding me a bit. You don't need C either.> I would use a Lisp-based language for the "top level" just because> they are good at handling things like parse trees, if one gets to> that.> > The objectives are:> > * A finished system in Pure Modula-3 (no executable C)> > * Make it as self-contained as possible> > You'd start by simply bundling the existing headers with m3bundle> and printing them out. Then you'd find duplication (what you've> been doing) and express that programmatically. Then you might find> things that might conceivably change in the OS headers and use> whatever tricks were necessary to figure them out automatically.> Does this involve C? Maybe on some architecture it does, maybe on> another it doesn't. On some it might not involve running C but> merely parsing C headers. Perhaps the program is just hand-written> and just a way of distilling all the duplication into one place> where it can be clearly described and documented. Since this is a> Modula-3 distribution, obviously the program I'm talking about is> written in Modula-3, not in C or Perl or Python.> > Mika> > Jay writes:> >--_2e194b09-14b6-4301-9116-a9e4d1e522b4_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >Yes=2C generating the headers is viable.> >I thought I mentioned that a few times.> >They could be generated in any build "that can". i.e. a native build=2C th=> >at has a working C development system and checked against the checked in o=> >nes.> > So then porting is: copy the generator to new system=2C run it=2C copy r=> >esults back=2C proceed=20> > Maybe a good compromise. Not good for "embedded systems"=2C but heck=2C i=> >s there any such thing any longer? Doesn't everything have megs of RAM and=> > gigs of persistant storage? :)> >You don't need Scheme.> >Just Quake + compiling and running C code.> >Assuming a native build system.> >I've done stuff in cross build systems like:> >typedef struct foo_t {int i=3B int j=3B } foo_t=3B> >extern const int xi =3D offsetof(foo_t=2C i)=3B> >=20> >compile that=2C and read the value of xi out of the .obj file.> >=20> > The .obj file reader was written in Perl. :)=20> > (Python not available.)> > but to do that here=2C I'd have to support multiple .obj file formats.> >=20> > - Jay> To: jay.krell at cornell.edu> Date: Mon=2C 12 Jan 2009 01:34:24 -0800>=> > From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3d=> >evel] declaring a type's existance but not enough to instantiate it?> > > Y=> >ou present it as a true tragic Dilemma.> > But isn't there a Third Way---to=> > wit=2C can't you "Ask the Computer"> to do the work for you?> > Generate t=> >he code somehow... Parsing the C headers is an obvious> way but there may b=> >e others that are simpler=2C such as writing a> Modula-3 program to generat=> >e the cloned M3 headers=2C sorry=2C interfaces.> > If I had to do this I wo=> >uld use my Scheme interpreter that's coded> in Modula-3 to write a Scheme p=> >rogram to generate the headers. This> program could pull whatever tricks ar=> >e deemed necessary and suitable=2C> down to the point of generating and com=> >piling and running C programs> as necessary (or parsing C code=2C or readin=> >g tea leaves). But the> end result would be a set of interfaces written in => >"Pure Modula-3".> The process of running the header generator would also ha=> >ve very> few dependencies on anything outside the M3 distribution.> > Mika>=> > > Jay writes:> >--_6117a048-9185-4c03-badb-ef8f93402268_> >Content-Type: t=> >ext/plain=3B charset=3D"iso-8859-1"> >Content-Transfer-Encoding: quoted-pri=> >ntable> >> >> >This is what you "have to" chose between.> >Header cloning o=> >r C code (and C headers).> >=3D20> >CONST or VAR (or functions?)> >=3D20> >=> >I'm going to likely make the Uerror change tonight.> >You can still veto it=> > (er=3D2C vote against it :) )> >=3D20> >Possibly some convuluted C (enum/#=> >undef)=3D2C or splitting the Modula-3> >at boundaries that weren't previous=> >ly believed "natural".> >(See how SetupHandlers is ~two lines in Modula-3 a=> >nd the rest in C=3D3B> >this is partly out of ignorance. I don't know how t=> >o write those> >two lines in C=3D3B and laziness=3D2C I didn't look into ho=> >w).> >=3D20> >=3D20> >=3D20> >Remember I'm still staying away from mainstre=> >am platforms=3D2C> >so the value isn't what it might appear to be=3D2C but => >it is "stage setting"=3D> >=3D2C> >and the show might go on. :)> >=3D20> >=> >=3D20> >Also=3D2C the dilemna does get more difficult now=3D2C with the lit=> >tle C header=3D> > cloning that remains.> >=3D20> >For example=3D2C look at=> > Upthreads.i3.> >Mainly=3D2C look at function prototypes.> >Constants and t=> >ypes are "known problems".> >Prototypes are gray. They actually tend to be => >portable.> >=3D20> >For example:> >=3D20> >TYPE pid_t =3D3D INTEGER=3D3B> >=> ><*EXTERNAL "m3_getpid*> PROCEDURE getpid():pid_t=3D3B> >=3D20> >or leave it=> > alone?> >getpid is probably the worst example.> >It is so very portable de=> >clared in Modula-3.> >But still=3D2C imagine pid_t might be 16bits or 32 or=> > 64.> >Writing a wrapper is more portable -- as long as the pid isn't stuff=> > into s=3D> >ome record that the system defines.> >=3D20> >=3D20> >Again=3D=> >2C Upthreads.i3.> >Would you like to see it reduced=3D2C or left alone?> >O=> >nly deal with the types and initializers=3D2C or also the prototypes?> >You=> > know=3D2C I could write a little portable layer=3D2C where all the types a=> >r=3D> >e pointers=3D2C always null initialized.> >It would buy /some/ porta=> >bility=3D2C and cost some.> >=3D20> >=3D20> >Do you like the sem_t change? => >Partly? Not at all?> >There is one sem_t in the system. So I moved it to be=> > in C code.> >Or=3D2C as I had it before=3D2C declared as the max size/alig=> >n of all the platf=3D> >orms -- getting that right is the same work as gett=> >ing it right "the old wa=3D> >y"=3D2C except if you make a mistake=3D2C odd=> >s are still good of it being ok.> >=3D20> >=3D20> >Should the line be drawn=> > at generating the remaining headers=3D2C rather than=3D> > eliminating the=> >m?> >Uerror.i3 is easily generated. Good enough?> >=3D20> >Upthread.i3's ty=> >pes can be generated generally as records with opaque array=3D> >s with the=> > right size and alignment.> >=3D20> >Other stuff can be generated or at lea=> >st checked.> >e.g. to check that getpid is declared correctly=3D2C you can => >assign it to a f=3D> >unction pointer and see if that compiles.> >=3D20> >P=> >erf on Uerror arguably doesn't matter.> >Is it only error handling code?Or => >do sockets often go down "error" paths=3D2C=3D> > because they are slow and=> > you are waiting for more data?> >=3D20> >Anyway=3D2C point is=3D2C I agree=> > for sure this is valuable=3D2C but I might be h=3D> >itting the "tail" of => >the approach and should switch=3D2C I'm not sure. I keep=3D> > saying that => >though=3D2C and then press further.> >=3D20> >=3D20> > - Jay> >> >> >> >Fro=> >m: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon=3D2C 12 Jan 200=> >=3D> >9 19:24:50 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] decla=> >ring a=3D> > type's existance but not enough to instantiate it?> >> >> >Poi=> >nt taken. We live in a C universe and so need to interact. I do think =3D> => >>your work with the headers is useful=3D2C and I want it to continue. Espec=> >ia=3D> >lly in simplifying ports.> >> >> >On 12 Jan 2009=3D2C at 19:18=3D2C=> > Jay wrote:> >> >I don't think a development system without C headers is in=> >teresting.. Is it=3D> > really? The transform I apply at times is wherever => >there is interaction wi=3D> >th C code that is described by system-dependen=> >t headers=3D2C or perhaps even =3D> >fairly system-independent headers outs=> >ide the Modula-3 tree=3D2C either write=3D> > wrapper functions for the fun=> >ctionality in the headers (e.g. stat=3D2C waitp=3D> >id)=3D2C which can be => >done in a system-independent way=3D2C or move the Modula-=3D> >3<->C transi=> >tion higher=3D2C which is also usually system-independent=3D2C e.g.=3D> > T=> >hreadPThreadC_SetupHandlers. It is either that or clone the headers=3D2C wh=> >=3D> >ich seems like the worse evil. There is always going to be a Modula-3=> ><->C t=3D> >ransition=3D2C it is just a matter of where it occurs. - Jay> >=> >> >CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornel=> >l.e=3D> >duSubject: Re: [M3devel] declaring a type's existance but not enou=> >gh to ins=3D> >tantiate it?Date: Mon=3D2C 12 Jan 2009 12:32:15 +1100> >> >>=> > >Jay=3D2C I really think you are bending over backwards too far just to be=> > abl=3D> >e to shoe-horn things into C. I *like* having the transpar of C h=> >eader fil=3D> >es expressed in Modula-3=3D2C *particularly* for system call=> >s=3D2C where you mi=3D> >ght even be trying to build on a system that does => >not have the C header fil=3D> >es installed=3D2C even though the libraries => >exist and can be linked to. Fund=3D> >amentally=3D2C I think anytime the Mo=> >dula-3 code is made less transparent you=3D> > should think hard about what=> > you are doing. The same with the change of c=3D> >onstants to variables.> => >>> >I am getting very nervous that the changes you are making are destroyin=> >g th=3D> >e clarity of the Modula-3 run-time code.> >> >In this particular => >case=3D2C you are wanting to use a Modula-3 parameter pass=3D> >ing mechani=> >sm on something that is not declared in Modula-3. Seems kind of=3D> > dubio=> >us to me. Also=3D2C I really don't like the idea of accessing external=3D> => >> variables in C.> >> >-- Tony> >> >On 12 Jan 2009=3D2C at 11:55=3D2C Jay w=> >rote:> >> >I considered ADDRESS.However I think it still doesn't satisfy. I=> > want to be=3D> > able to do this: TYPE Foo_t =3D3D something=3D3B<* EXTERN=> >AL *> VAR Foo1=3D2C Foo=3D> >2:Foo_t=3D3B<* EXTERNAL *> PROCEDURE UseFoo(RE=> >ADONLY (* or VAR *) foo:Foo_t)=3D> >=3D3B (* Modula-3=3D2C not external *)P=> >ROCEDURE x()=3D3DBEGIN UseFoo(Foo1)=3D3B U=3D> >seFoo(Foo2)=3D3BEND x=3D3B => >AND I want any use of:VAR Foo3:Foo3_t=3D3B (* Modula-3=3D> >=3D2C not exter=> >nal *)to error. This is sem_t and sigset_t in particular. Poss=3D> >ibly re=> >naming is the thing.They used to be declared in Modula-3=3D2C system-d=3D> => >>ependently=3D2C butI moved them to portable C. I could remove the types en=> >tir=3D> >ely and change UseFoo to take an address=3D2Cand declare mask and => >ackSem to b=3D> >e integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END=> >=3D3B That would sat=3D> >isfy but I thought it might be nicer to still pro=> >vide the namedtypes to ref=3D> >er to the external variables. - Jay> >> >Fr=> >om: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon=3D2C 12 Jan 200=> >=3D> >9 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] decla=> >ring a=3D> > type's existance but not enough to instantiate it?What's wrong=> > with using =3D> >ADDRESS for references to opaque values? If sigset_t is n=> >ever instantiated=3D> > in Modula-3=3D2C then why do you need it declared t=> >here?> >> >> >> >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 200=> >9=3D2C at 01:44=3D2C Jay wrote:> >> >Is there a way in Modula-3 to declare => >that a type exists=3D2C and there are <=3D> >*external*> instances of it=3D=> >2C without "fully" declaring it=3D2C so that no M=3D> >odula-3 can instanti=> >ate it? I have done this for sigset_t and sem_t=3D2C but =3D> >they could e=> >rroneously be instantiated by Modula-3 and I'd like to remove t=3D> >hat ab=> >ility to mess up so easily. (* This type is not declared correctly. I=3D> >=> >t is only instantiated in C code. *) sigset_t =3D3D RECORD END=3D3B(* This => >typ=3D> >e is not declared correctly. It is only instantiated in C code. *)=> > sem_t =3D> >=3D3D RECORD END=3D3BIn C I believe you can do this=3D2C like:=> > typedef struct fo=3D> >o foo_t=3D3B extern foo_t foo=3D3B void UseFoo(foo_=> >t*)=3D3B foo_t* GetFoo=3D> >(void)=3D3B Thanks=3D2C - Jay=3D> >> >--_6117a0=> >48-9185-4c03-badb-ef8f93402268_> >Content-Type: text/html=3B charset=3D"iso=> >-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >=> >> >> ><=> >/head>> >> >This is what you "have to" chose be=> >tween.
> >Header cloning or C code (and C headers).
> > =3D3B
=> >> >CONST or VAR (or functions?)
> > =3D3B
> >I'm going to likely => >make the Uerror change tonight.
> >You can still veto it (er=3D2C vote a=> >gainst it :) )
> > =3D3B
> >Possibly some convuluted C (enum/#und=> >ef)=3D2C or splitting the Modula-3
> >at boundaries that weren't previou=> >sly believed "natural".
> >(See how SetupHandlers is ~two lines in Modul=> >a-3 and the rest in C=3D3B
> >this is partly out of ignorance. I don't k=> >now how to write those
> >two lines in C=3D3B and laziness=3D2C I didn't=> > look into how).
> > =3D3B
> > =3D3B
> > =3D3B
> >R=> >emember I'm still staying away from mainstream platforms=3D2C
> >so the => >value isn't what it might appear to be=3D2C but it is "stage setting"=3D> >=> >=3D2C
> >and the show might go on. :)
> > =3D3B
> > =3D3B<=> >BR>> >Also=3D2C the dilemna does get more difficult now=3D2C with the littl=> >e C header=3D> > cloning that remains.
> > =3D3B
> >For example=> >=3D2C look at Upthreads.i3.
> >Mainly=3D2C look at function prototypes.<=> >BR>> >Constants and types are "known problems".
> >Prototypes are gray. => >They actually tend to be portable.
> > =3D3B
> >For example:
>=> > > =3D3B
> >TYPE pid_t =3D3D INTEGER=3D3B
> ><=3D3B*EXTERNAL "m=> >3_getpid*>=3D3B PROCEDURE getpid():pid_t=3D3B
> > =3D3B
> >or l=> >eave it alone?
> >getpid is probably the worst example.
> >It is so v=> >ery portable declared in Modula-3.
> >But still=3D2C imagine pid_t might=> > be 16bits or 32 or 64.
> >Writing a wrapper is more portable -- as long=> > as the pid isn't stuff into s=3D> >ome record that the system defines.
=> >> > =3D3B
> > =3D3B
> >Again=3D2C Upthreads.i3.
> >Would y=> >ou like to see it reduced=3D2C or left alone?
> >Only deal with the type=> >s and initializers=3D2C or also the prototypes?
> >You know=3D2C I could=> > write a little portable layer=3D2C where all the types ar=3D> >e pointers=> >=3D2C always null initialized.
> >It would buy /some/ portability=3D2C a=> >nd cost some.
> > =3D3B
> > =3D3B
> >Do you like the sem_t=> > change? Partly? Not at all?
> >There is one sem_t in the system. So I m=> >oved it to be in C code.
> >Or=3D2C as I had it before=3D2C declared as => >the max size/align of all the platf=3D> >orms -- getting that right is the => >same work as getting it right "the old wa=3D> >y"=3D2C except if you make a=> > mistake=3D2C odds are still good of it being ok. >R>> > =3D3B >>> > =3D3B
> >Should the line be drawn at generating the remaining h=> >eaders=3D2C rather than=3D> > eliminating them?
> >Uerror.i3 is easily g=> >enerated. Good enough?
> > =3D3B
> >Upthread.i3's types can be ge=> >nerated generally as records with opaque array=3D> >s with the right size a=> >nd alignment.
> > =3D3B
> >Other stuff can be generated or at lea=> >st checked.
> >e.g. to check that getpid is declared correctly=3D2C you => >can assign it to a f=3D> >unction pointer and see if that compiles.
> >&=> >nbsp=3D3B
> >Perf on Uerror arguably doesn't matter.
> >Is it only er=> >ror handling code?
Or do sockets often go down "error" path=3D> >s=3D2C => >because they are slow and you are waiting for more data?
> > =3D3B >R>> >Anyway=3D2C point is=3D2C I agree for sure this is valuable=3D2C but I=> > might be h=3D> >itting the "tail" of the approach and should switch=3D2C I=> >'m not sure. I keep=3D> > saying that though=3D2C and then press further. >R>> > =3D3B
> > =3D3B
> > =3D3B- Jay

> >> >
>=3D3DstopSpelling>>
> >From: hosking at cs.purdue.edu
To: jay.krell at cor=> >nell.edu
Date: Mon=3D2C 12=3D> > Jan 2009 19:24:50 +1100
CC: m3devel@=> >elegosoft.com
Subject: Re: [M3de=3D> >vel] declaring a type's existance => >but not enough to instantiate it?

=3D> >
> >
>EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: =3D> >12px Helv=> >etica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-IN=> >D=3D> >ENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B B=> >ORDER-COLLAPS=3D> >E: separate">> >
<=> >SPAN class=3D3DEC_Apple-style-span styl=3D> >e=3D3D"WORD-SPACING: 0px=3D3B => >FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B C=3D> >OLOR: rgb(0=3D2C=> >0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-S=3D> >=> >PACING: normal=3D3B BORDER-COLLAPSE: separate"> >le-s=3D> >pan style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B T=> >EXT-TRANSFORM: n=3D> >one=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: => >0px=3D3B WHITE-SPACE: normal=3D3B =3D> >LETTER-SPACING: normal=3D3B BORDER-=> >COLLAPSE: separate"> >-style-span style=3D3D"WO=> >RD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRAN=3D> >SFORM: none=> >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: no=> >=3D> >rmal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate"> >N class=3D3D=3D> >EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FON=> >T: 12px Helvetica=3D3B T=3D> >EXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=> >=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-S=3D> >PACE: normal=3D3B LETTER-SP=> >ACING: normal=3D3B BORDER-COLLAPSE: separate"> >class=3D3DEC_Appl=> >e-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvet=3D> >ica=> >=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT:=> > 0px=3D3B=3D> > WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER=> >-COLLAPSE: separate=3D> >"> >ORD-SPACING: 0px=3D3B FONT: 12p=3D> >x Helvetica=3D3B TEXT-TRANSFORM: none=> >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT=3D> >: 0px=3D3B WHITE-SPAC=> >E: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: =3D> >separate"=> >> >> >ONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D=> >2C0)=3D3B TEX=3D> >T-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACI=> >NG: normal=3D3B BORDER-CO=3D> >LLAPSE: separate"> >tyle-span style=3D3D"WORD-SPACING: =3D> >0px=3D3B FONT: 12px Helvetica=3D3B=> > TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0=3D> >)=3D3B TEXT-INDENT=> >: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B B=3D> >ORDE=> >R-COLLAPSE: separate">> >
Point taken.  =3D3BWe live in a C univers=> >e and so need to interact. =3D> > =3D3BI do think your work with the he=> >aders is useful=3D2C and I want it to=3D> > continue.  =3D3BEspecially => >in simplifying ports.
> >

 >SPAN> >V>
> >
> >
On 12 Ja=> >n 2009=3D2C at 19:18=3D2C Jay wrote:

>e=> >rchange-newline>> >
>3D"WORD-SPACING: 0px=3D3B=3D> > FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: n=> >one=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B T=3D> >EXT-INDENT: 0px=3D3B WHITE-S=> >PACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-=3D> >COLLAPSE: separa=> >te">> >
>ILY: Verdana"=3D> >>I don't think a development system without C headers is=> > interesting.. Is i=3D> >t really?
 =3D3B
The transform I apply a=> >t times is wherever there i=3D> >s interaction with C code that is describe=> >d by system-dependent headers=3D2C =3D> >or perhaps even fairly system-inde=> >pendent headers outside the Modula-3 tree=3D> >=3D2C either write wrapper f=> >unctions for the functionality in the headers (e.=3D> >g. stat=3D2C waitpid=> >)=3D2C which =3D3Bcan be done in a system-independent way=3D> >=3D2C&nb=> >sp=3D3Bor move the Modula-3<=3D3B->=3D3BC transition higher=3D2C which => >is=3D> > also usually system-independent=3D2C e.g. ThreadPThreadC_SetupHand=> >lers.
&=3D> >nbsp=3D3B
It is either that or clone the headers=3D2C wh=> >ich seems like the w=3D> >orse evil.
 =3D3B
There is always going=> > to be a Modula-3<=3D3B->=3D> >=3D3BC transition=3D2C it is just a matt=> >er of where it occurs.
 =3D3B
&=3D> >nbsp=3D3B- Jay

> > > id=3D3DEC_stopSpelling>> >
CC:=> > =3D3B >lto:m3devel at elegosoft.com">m3devel at e=> >legosoft.com
From: >EC_Apple-converted-space>&nb=> >sp=3D3B >.edu">hosking at cs.p=> >urdue.edu
To: >e> =3D=> >3Bjay.krell at cornell=3D> >=> >.edu
Subject: Re: [M3devel] declaring a type's existance but not eno=> >=3D> >ugh to instantiate it?
Date: Mon=3D2C 12 Jan 2009 12:32:15 +1100 >R>
>R>>
>RD-SPACING: 0px=3D3B FON=3D> >T: 12px Helvetica=3D3B TEXT-TRANSFORM: none=> >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-=3D> >INDENT: 0px=3D3B WHITE-SPAC=> >E: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLL=3D> >APSE: separate"=> >>> >
>e-span s=3D> >tyle=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TE=> >XT-TRANSFORM: none=3D> >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0=> >px=3D3B WHITE-SPACE: normal=3D3B LET=3D> >TER-SPACING: normal=3D3B BORDER-C=> >OLLAPSE: separate"> >-style-span style=3D3D"=> >WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRAN=3D> >SFORM: none=> >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: no=> >=3D> >rmal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate"> >N class=3D3D=3D> >EC_EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B => >FONT: 12px Helvetica=3D> >=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C=> >0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WH=3D> >ITE-SPACE: normal=3D3B LETTER-S=> >PACING: normal=3D3B BORDER-COLLAPSE: separate"><=3D> >SPAN class=3D3DEC_EC_=> >Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12p=3D> >x Helveti=> >ca=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDEN=> >T=3D> >: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORD=> >ER-COLLAPSE: =3D> >separate"> >=3D3D"WORD-SPACING: 0px=3D> >=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM=> >: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D> >=3D3B TEXT-INDENT: 0px=3D3B WHIT=> >E-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BO=3D> >RDER-COLLAPSE: sep=> >arate"> >-SPACING=> >: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb=> >=3D> >(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B L=> >ETTER-SPACING: n=3D> >ormal=3D3B BORDER-COLLAPSE: separate"> >DEC_EC_Apple-style-span st=3D> >yle=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px => >Helvetica=3D3B TEXT-TRANSFORM: none=3D3B=3D> > COLOR: rgb(0=3D2C0=3D2C0)=3D=> >3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER=3D> >-SPACING: nor=> >mal=3D3B BORDER-COLLAPSE: separate"> >yle=> >-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRAN=> >SFO=3D> >RM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B=> > WHITE-SPACE: norma=3D> >l=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE=> >: separate">> >
Jay=3D2C I really think you are bending over backwards => >too far just to b=3D> >e able to shoe-horn things into C.  =3D3BI *like=> >* having the transpar of =3D> >C header files expressed in Modula-3=3D2C *p=> >articularly* for system calls=3D2C =3D> >where you might even be trying to => >build on a system that does not have the =3D> >C header files installed=3D2=> >C even though the libraries exist and can be link=3D> >ed to.  =3D3BFun=> >damentally=3D2C I think anytime the Modula-3 code is made l=3D> >ess transp=> >arent you should think hard about what you are doing.  =3D3BThe=3D> > s=> >ame with the change of constants to variables.
> >

> > >IV>I am getting very nervous that the changes you are making are destroyi=> >=3D> >ng the clarity of the Modula-3 run-time code.
> >

=> >> >
In this particular case=3D2C you are wanting to use a Modula-3 para=> >meter=3D> > passing mechanism on something that is not declared in Modula-3=> >.  =3D3BS=3D> >eems kind of dubious to me.  =3D3BAlso=3D2C I really=> > don't like the idea of=3D> > accessing external variables in C.
> > >IV>
> >
-- Tony
>><=3D> >/DIV>

> >
> >
On 12 Jan 2009=> >=3D2C at 11:55=3D2C Jay wrote:

>interch=> >ange-newline>> >
>3D"WORD-SPACING: 0px=3D> >=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: n=> >one=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D> >=3D3B TEXT-INDENT: 0px=3D3B WHITE-S=> >PACE: normal=3D3B LETTER-SPACING: normal=3D3B BO=3D> >RDER-COLLAPSE: separa=> >te">> >
>FAMILY: Verda=3D> >na">I considered ADDRESS.
However I think it still do=> >esn't satisfy.
&=3D> >nbsp=3D3B
I want to be able to do this:
&nbs=> >p=3D3B
TYPE =3D3BFoo_t =3D> >=3D3D something=3D3B
<=3D3B* EXTER=> >NAL *>=3D3B VAR Foo1=3D2C Foo2:Foo_t=3D3B
&=3D> >lt=3D3B* EXTERNAL *&g=> >t=3D3B PROCEDURE =3D3BUseFoo(READONLY (* or VAR *) foo:F=3D> >oo_t)=3D3=> >B
 =3D3B
(* Modula-3=3D2C not external *)
PROCEDURE x()=3D3D<=> >=3D> >BR>BEGIN
 =3D3B UseFoo(Foo1)=3D3B
 =3D3B UseFoo(Foo2)=> >=3D3B
END x=3D> >=3D3B
 =3D3B
AND I want any use of:
VAR Fo=> >o3:Foo3_t=3D3B (* Modula-3=3D> >=3D2C not external *)

to error. This=> > is sem_t and sigset_t in particul=3D> >ar.
 =3D3B
Possibly renam=> >ing is the thing.
They used to be decla=3D> >red in Modula-3=3D2C system=> >-dependently=3D2C but
I moved them to portable C.=3D> >
 =3D3B >>I could remove the types entirely and change UseFoo to take=3D> > an addre=> >ss=3D2C
and declare mask and ackSem to be integers or I guess. >>=> ><=3D3B*EXTERNAL>=3D3B VAR ackSem =3D3B: RECORD END=3D3B
 =3D=> >3B
Tha=3D> >t would satisfy but I thought it might be nicer to still pro=> >vide the named<=3D> >BR>types to refer to the external variables.
 => >=3D3B
 =3D3B- Jay >R>
> >
> ><=> >BR>From: =3D3B >f=3D> >=3D3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu
To:=> > >ss=3D3DEC_EC_Apple-converted-space> =3D3B >=3D3D"mailto:jay.krell=3D> >@cornell.edu">jay.krell at cornell.edu
Date=> >: Mon=3D2C 12 Jan 2009 11:13:0=3D> >0 +1100
CC: >le-converted-space> =3D3B >ref=3D3D"mailto:m3devel at elego=> >soft.com">m3devel at elegosoft.com
Subject: =3D> >Re: [M3devel] declari=> >ng a type's existance but not enough to instantiate it=3D> >?

What's=> > wrong with using ADDRESS for references to opaque values? &=3D> >nbsp=3D3B=> >If sigset_t is never instantiated in Modula-3=3D2C then why do you nee=3D> => >>d it declared there?
> >

> >
>-style-span style=3D3D"WORD-SPACING: 0px=3D3B =3D> >FONT: 12px Helvetica=3D=> >3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TE=3D> >XT-INDE=> >NT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-C=> >=3D> >OLLAPSE: separate">> >
>ass=3D3DEC_EC_EC_Apple-style-spa=3D> >n style=3D3D"WORD-SPACING: 0px=3D3B F=> >ONT: 12px Helvetica=3D3B TEXT-TRANSFORM: non=3D> >e=3D3B COLOR: rgb(0=3D2C0=> >=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LE=3D> >TTER-SP=> >ACING: normal=3D3B BORDER-COLLAPSE: separate"> >> >pple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=> >=3D3B TEXT-=3D> >TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-I=> >NDENT: 0px=3D3B WHITE-SPACE=3D> >: normal=3D3B LETTER-SPACING: normal=3D3B => >BORDER-COLLAPSE: separate"> >s=3D3DEC_EC_EC_Apple-style-span => >style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helv=3D> >etica=3D3B TEXT-TRAN=> >SFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D> >=3D3B=> > WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: sepa=> >r=3D> >ate"> >NG: 0px=3D3B =3D> >FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLO=> >R: rgb(0=3D2C0=3D2C0)=3D3B TE=3D> >XT-INDENT: 0px=3D3B WHITE-SPACE: normal=> >=3D3B LETTER-SPACING: normal=3D3B BORDER-C=3D> >OLLAPSE: separate"> >ass=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SP=3D> >ACING: 0px=3D3B F=> >ONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D> >=3D2C0=> >=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING:=> > nor=3D> >mal=3D3B BORDER-COLLAPSE: separate"> >e-style-span s=3D> >tyle=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=> >=3D3B TEXT-TRANSFORM: none=3D> >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-I=> >NDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LET=3D> >TER-SPACING: normal=3D3B => >BORDER-COLLAPSE: separate"> >ple-style-span => >style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-T=3D> >RAN=> >SFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE=> >-SPACE:=3D> > normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: sepa=> >rate"> >=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SPACI=> >NG: 0px=3D3B FONT: 12px Helve=3D> >tica=3D3B TEXT-TRANSFORM: none=3D3B COLO=> >R: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D> >=3D3B WHITE-SPACE: normal=> >=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separ=3D> >ate">> >
=> > >D=3D> >EC_EC_EC_Apple-style-span face=3D3D"Gill Sans"> >_EC_Apple-s=3D> >tyle-span style=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=3D3B FONT=> >-FAMILY: 'Gill Sans'"> >AN class=3D3DEC_EC_EC_Apple-style-span style=> >=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=3D3B FO=3D> >NT-FAMILY: 'Gill Sans'">Anto=> >ny Hosking >ss=3D3DEC_EC_EC_Apple-=> >style-span face=3D3D"Gill Sans"> >ple-style-=> >span style=3D3D"FONT-FAMILY: 'Gill Sans'"> >=> >ple-style-span style=3D3D"FONT-FAMILY: 'Gill Sans'"> >pple=3D> >-converted-space> =3D3B| >nverted-space>=3D> > =3D3B >_Apple-style-span style=3D> >=3D3D"FONT-FAMILY: 'Gill Sans'"> >3DEC_EC_EC_Apple-style-span style=3D> >=3D3D"FONT-FAMILY: 'Gill Sans'">Asso=> >ciate Professor >=3D3DEC_EC_EC_Apple-style-spa=> >n style=3D3D"FONT-FAMILY: 'Gill Sans'"> >=3D3DEC_EC_EC_Apple=> >-style-span style=3D3D"FONT-FAMILY: 'Gill Sans'"> =3D3B| C=3D> >omputer=> > Science | Purdue University
> >
>=3D3DEC_EC_EC_Apple-style-span face=3D3DGillSans-Light> >ass=3D=> >3DEC_EC_EC_Apple-style-span style=3D3D"FONT-FAMILY: GillSans-Light">305 N=> >=3D> >. University Street | West Lafayette | IN 47907 | USA >DIV>> >
>color=3D3D#00=3D> >00ff> >D"COLOR: rgb(0=3D2C0=3D2C25=3D> >5)=3D3B FONT-FAMILY: 'Gill Sans'"> >ass=3D3DEC_EC_EC_Apple-style-span sty=3D> >le=3D3D"COLOR: rgb(0=3D2C0=3D2C2=> >55)=3D3B FONT-FAMILY: 'Gill Sans'">Office >PAN> >lass=3D3DEC_EC_EC_Apple-style-span face=3D3DGillSans-Light> >PAN clas=> >s=3D3DEC_EC_EC_Apple-style-span style=3D3D"FONT-FAMILY: GillSans-Light"=3D>=> > >> >ns-Lig=3D> >ht"> =3D3B+1 765 494 6001 | >erted-space>&nbs=3D> >p=3D3B >EC_EC_Apple-style-span fac=3D> >e=3D3D"Gill Sans" color=3D3D#0000ff> >lass=3D3DEC_EC_EC_Apple-style-span sty=3D> >le=3D3D"COLOR: rgb(0=3D2C0=3D2C=> >255)=3D3B FONT-FAMILY: 'Gill Sans'"> >_EC_EC_Apple-st=> >yle-span style=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=3D3B FONT-FAMILY: 'G=3D> >i=> >ll Sans'">Mobile >p=3D> >an face=3D3DGillSans-Light> > style=3D3D"F=3D> >ONT-FAMILY: GillSans-Light"> >le-style-span style=3D> >=3D3D"FONT-FAMILY: GillSans-Light"> >DEC_EC_Apple-converted-space>=3D> > =3D3B+1 765 427 5484<=> >/SPAN>
> >
>=3D3DGillSans-Light>
>s=3D3DEC_EC_EC_khtml-block-placeholder> >FONT>
>AN>
>=3D3DEC_EC_EC_Apple-interchange-newline> >AN>
>>> >
> >
On 12 Jan 2009=3D2C at 01:44=3D2C Jay wrote:

>s=3D3DEC_EC_EC_App=3D> >le-interchange-newline>> >
>=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SPACING: =3D> >0px=3D3B FONT=> >: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0=3D=> >> >)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: no=> >rmal=3D3B B=3D> >ORDER-COLLAPSE: separate">> >
>sage style=3D3D"FONT-SIZE: 10pt=3D3B FONT-FAMILY: Ve=3D> >rdana">Is there a=> > way in Modula-3 to declare that =3D3Ba type exists=3D2C a=3D> >nd ther=> >e are <=3D3B*external*>=3D3B instances of it=3D2C without "fully" decl=> >=3D> >aring it=3D2C so that no Modula-3 can instantiate it?
 =3D3B >R>I have d=3D> >one this for sigset_t and sem_t=3D2C but they could erroneo=> >usly be instantiat=3D> >ed by Modula-3 and I'd like to remove that ability => >to mess up so easily. >> =3D3B
(* This type is not declared c=> >orrectly. It is only instantiate=3D> >d in C code. *)
 =3D3B sigset_=> >t =3D3D RECORD END=3D3B

(* This type =3D> >is not declared correctly=> >. It is only instantiated in C code. *)
 =3D> >=3D3B sem_t =3D3D REC=> >ORD END=3D3B

In C I believe you can do this=3D2C like:<=3D> >BR>&nbs=> >p=3D3B =3D3Btypedef struct foo foo_t=3D3B =3D3B >C_E=3D> >C_Apple-converted-space> =3D3B
 =3D3B =3D3Be=> >xtern foo_t foo=3D> >=3D3B =3D3B >d-space> =3D3B
=3D> > =3D3B
 =3D3Bvoid UseFoo(foo_=> >t*)=3D3B >erted-space> =3D3B >AN>
 =3D3B foo_t* GetFoo(void)=3D3B >=3D3DEC_EC_EC_Ap=> >ple-converted-space> =3D3B
 =3D3B
Thanks=3D2C<=3D> >BR=> >> =3D3B- Jay




<=> >=3D> >/DIV>
>E>
=3D> >

<=> >/BLOCKQUOTE> >V>
> >=3D> >> >--_6117a048-9185-4c03=> >-badb-ef8f93402268_--=> >> >--_2e194b09-14b6-4301-9116-a9e4d1e522b4_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >> >Yes=2C generating the headers is viable.
> >I thought I mentioned that a few times.
> They could be generated in any build "that can".
 =3B i.e. a native => >build=2C that has a working C development system
 =3B and checked ag=> >ainst the checked in ones.
> > =3BSo then porting is:
 =3B copy the generator to new system=> >=2C run it=2C copy results back=2C proceed
> >
 =3BMaybe a good compromise.
 =3BNot good for "embedded sys=> >tems"=2C but heck=2C is there any such thing
 =3B any longer? Doesn'=> >t everything have megs of RAM and gigs of persistant storage? :)
> >
You don't need =3BScheme.
> >Just Quake =3B+ compiling and running C code.
> >Assuming a native build system.
> >I've done stuff in cross build systems like:
> >typedef struct foo_t {int i=3B int j=3B } foo_t=3B
> >extern const int xi =3D offsetof(foo_t=2C i)=3B
> > =3B
> >compile that=2C and read the value of xi out of the .obj file.
> > =3B
> > =3BThe .obj file reader was written in Perl. :)
> > =3B (Python not available.)
> > =3Bbut to do that here=2C I'd have to support multiple .obj file forma=> >ts.
> > =3B
> > =3B- Jay

>=3B To: jay.krell at cornell.edu
>=3B Date: Mon=> >=2C 12 Jan 2009 01:34:24 -0800
>=3B From: mika at async.caltech.edu
&g=> >t=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] declaring a=> > type's existance but not enough to instantiate it?
>=3B
>=3B >R>>=3B You present it as a true tragic Dilemma.
>=3B
>=3B But => >isn't there a Third Way---to wit=2C can't you "Ask the Computer"
>=3B => >to do the work for you?
>=3B
>=3B Generate the code somehow... P=> >arsing the C headers is an obvious
>=3B way but there may be others th=> >at are simpler=2C such as writing a
>=3B Modula-3 program to generate => >the cloned M3 headers=2C sorry=2C interfaces.
>=3B
>=3B If I had=> > to do this I would use my Scheme interpreter that's coded
>=3B in Mod=> >ula-3 to write a Scheme program to generate the headers. This
>=3B pro=> >gram could pull whatever tricks are deemed necessary and suitable=2C
>=> >=3B down to the point of generating and compiling and running C programs >>>=3B as necessary (or parsing C code=2C or reading tea leaves). But the<=> >BR>>=3B end result would be a set of interfaces written in "Pure Modula-3=> >".
>=3B The process of running the header generator would also have ve=> >ry
>=3B few dependencies on anything outside the M3 distribution.
&=> >gt=3B
>=3B Mika
>=3B
>=3B Jay writes:
>=3B >=3B--_6=> >117a048-9185-4c03-badb-ef8f93402268_
>=3B >=3BContent-Type: text/pla=> >in=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Encoding: quo=> >ted-printable
>=3B >=3B
>=3B >=3B
>=3B >=3BThis is wha=> >t you "have to" chose between.
>=3B >=3BHeader cloning or C code (an=> >d C headers).
>=3B >=3B=3D20
>=3B >=3BCONST or VAR (or functi=> >ons?)
>=3B >=3B=3D20
>=3B >=3BI'm going to likely make the Ue=> >rror change tonight.
>=3B >=3BYou can still veto it (er=3D2C vote ag=> >ainst it :) )
>=3B >=3B=3D20
>=3B >=3BPossibly some convulute=> >d C (enum/#undef)=3D2C or splitting the Modula-3
>=3B >=3Bat boundar=> >ies that weren't previously believed "natural".
>=3B >=3B(See how Se=> >tupHandlers is ~two lines in Modula-3 and the rest in C=3D3B
>=3B >=> >=3Bthis is partly out of ignorance. I don't know how to write those
>=> >=3B >=3Btwo lines in C=3D3B and laziness=3D2C I didn't look into how). >>>=3B >=3B=3D20
>=3B >=3B=3D20
>=3B >=3B=3D20
>=3B &=> >gt=3BRemember I'm still staying away from mainstream platforms=3D2C
>=> >=3B >=3Bso the value isn't what it might appear to be=3D2C but it is "sta=> >ge setting"=3D
>=3B >=3B=3D2C
>=3B >=3Band the show might go => >on. :)
>=3B >=3B=3D20
>=3B >=3B=3D20
>=3B >=3BAlso=3D2=> >C the dilemna does get more difficult now=3D2C with the little C header=3D<=> >BR>>=3B >=3B cloning that remains.
>=3B >=3B=3D20
>=3B >=> >=3BFor example=3D2C look at Upthreads.i3.
>=3B >=3BMainly=3D2C look => >at function prototypes.
>=3B >=3BConstants and types are "known prob=> >lems".
>=3B >=3BPrototypes are gray. They actually tend to be portab=> >le.
>=3B >=3B=3D20
>=3B >=3BFor example:
>=3B >=3B=3D2=> >0
>=3B >=3BTYPE pid_t =3D3D INTEGER=3D3B
>=3B >=3B<=3B*EXTE=> >RNAL "m3_getpid*>=3B PROCEDURE getpid():pid_t=3D3B
>=3B >=3B=3D20<=> >BR>>=3B >=3Bor leave it alone?
>=3B >=3Bgetpid is probably the w=> >orst example.
>=3B >=3BIt is so very portable declared in Modula-3.<=> >BR>>=3B >=3BBut still=3D2C imagine pid_t might be 16bits or 32 or 64. >R>>=3B >=3BWriting a wrapper is more portable -- as long as the pid isn=> >'t stuff into s=3D
>=3B >=3Bome record that the system defines.
&=> >gt=3B >=3B=3D20
>=3B >=3B=3D20
>=3B >=3BAgain=3D2C Upthread=> >s.i3.
>=3B >=3BWould you like to see it reduced=3D2C or left alone?<=> >BR>>=3B >=3BOnly deal with the types and initializers=3D2C or also the => >prototypes?
>=3B >=3BYou know=3D2C I could write a little portable l=> >ayer=3D2C where all the types ar=3D
>=3B >=3Be pointers=3D2C always => >null initialized.
>=3B >=3BIt would buy /some/ portability=3D2C and => >cost some.
>=3B >=3B=3D20
>=3B >=3B=3D20
>=3B >=3BDo y=> >ou like the sem_t change? Partly? Not at all?
>=3B >=3BThere is one => >sem_t in the system. So I moved it to be in C code.
>=3B >=3BOr=3D2C=> > as I had it before=3D2C declared as the max size/align of all the platf=3D=> >
>=3B >=3Borms -- getting that right is the same work as getting it => >right "the old wa=3D
>=3B >=3By"=3D2C except if you make a mistake=> >=3D2C odds are still good of it being ok.
>=3B >=3B=3D20
>=3B &=> >gt=3B=3D20
>=3B >=3BShould the line be drawn at generating the remai=> >ning headers=3D2C rather than=3D
>=3B >=3B eliminating them?
>=> >=3B >=3BUerror.i3 is easily generated. Good enough?
>=3B >=3B=3D20=> >
>=3B >=3BUpthread.i3's types can be generated generally as records => >with opaque array=3D
>=3B >=3Bs with the right size and alignment. >R>>=3B >=3B=3D20
>=3B >=3BOther stuff can be generated or at lea=> >st checked.
>=3B >=3Be.g. to check that getpid is declared correctly=> >=3D2C you can assign it to a f=3D
>=3B >=3Bunction pointer and see i=> >f that compiles.
>=3B >=3B=3D20
>=3B >=3BPerf on Uerror argua=> >bly doesn't matter.
>=3B >=3BIs it only error handling code?Or do so=> >ckets often go down "error" paths=3D2C=3D
>=3B >=3B because they are=> > slow and you are waiting for more data?
>=3B >=3B=3D20
>=3B &g=> >t=3BAnyway=3D2C point is=3D2C I agree for sure this is valuable=3D2C but I => >might be h=3D
>=3B >=3Bitting the "tail" of the approach and should => >switch=3D2C I'm not sure. I keep=3D
>=3B >=3B saying that though=3D2=> >C and then press further.
>=3B >=3B=3D20
>=3B >=3B=3D20
&g=> >t=3B >=3B - Jay
>=3B >=3B
>=3B >=3B
>=3B >=3B
>=> >=3B >=3BFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon=3D2=> >C 12 Jan 200=3D
>=3B >=3B9 19:24:50 +1100CC: m3devel at elegosoft.comSu=> >bject: Re: [M3devel] declaring a=3D
>=3B >=3B type's existance but n=> >ot enough to instantiate it?
>=3B >=3B
>=3B >=3B
>=3B &g=> >t=3BPoint taken. We live in a C universe and so need to interact. I do thin=> >k =3D
>=3B >=3Byour work with the headers is useful=3D2C and I want => >it to continue. Especia=3D
>=3B >=3Blly in simplifying ports.
>=> >=3B >=3B
>=3B >=3B
>=3B >=3BOn 12 Jan 2009=3D2C at 19:18=3D=> >2C Jay wrote:
>=3B >=3B
>=3B >=3BI don't think a development => >system without C headers is interesting.. Is it=3D
>=3B >=3B really?=> > The transform I apply at times is wherever there is interaction wi=3D
&=> >gt=3B >=3Bth C code that is described by system-dependent headers=3D2C or=> > perhaps even =3D
>=3B >=3Bfairly system-independent headers outside=> > the Modula-3 tree=3D2C either write=3D
>=3B >=3B wrapper functions => >for the functionality in the headers (e.g. stat=3D2C waitp=3D
>=3B >=> >=3Bid)=3D2C which can be done in a system-independent way=3D2C or move the => >Modula-=3D
>=3B >=3B3<=3B->=3BC transition higher=3D2C which is => >also usually system-independent=3D2C e.g.=3D
>=3B >=3B ThreadPThread=> >C_SetupHandlers. It is either that or clone the headers=3D2C wh=3D
>=> >=3B >=3Bich seems like the worse evil. There is always going to be a Modu=> >la-3<=3B->=3BC t=3D
>=3B >=3Bransition=3D2C it is just a matter => >of where it occurs. - Jay
>=3B >=3B
>=3B >=3BCC: m3devel at eleg=> >osoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.e=3D
>=3B &g=> >t=3BduSubject: Re: [M3devel] declaring a type's existance but not enough to=> > ins=3D
>=3B >=3Btantiate it?Date: Mon=3D2C 12 Jan 2009 12:32:15 +11=> >00
>=3B >=3B
>=3B >=3B
>=3B >=3BJay=3D2C I really thin=> >k you are bending over backwards too far just to be abl=3D
>=3B >=3B=> >e to shoe-horn things into C. I *like* having the transpar of C header fil=> >=3D
>=3B >=3Bes expressed in Modula-3=3D2C *particularly* for system=> > calls=3D2C where you mi=3D
>=3B >=3Bght even be trying to build on => >a system that does not have the C header fil=3D
>=3B >=3Bes installe=> >d=3D2C even though the libraries exist and can be linked to. Fund=3D
>=> >=3B >=3Bamentally=3D2C I think anytime the Modula-3 code is made less tra=> >nsparent you=3D
>=3B >=3B should think hard about what you are doing=> >. The same with the change of c=3D
>=3B >=3Bonstants to variables. >R>>=3B >=3B
>=3B >=3BI am getting very nervous that the changes => >you are making are destroying th=3D
>=3B >=3Be clarity of the Modula=> >-3 run-time code.
>=3B >=3B
>=3B >=3BIn this particular case=> >=3D2C you are wanting to use a Modula-3 parameter pass=3D
>=3B >=3Bi=> >ng mechanism on something that is not declared in Modula-3. Seems kind of=> >=3D
>=3B >=3B dubious to me. Also=3D2C I really don't like the idea => >of accessing external=3D
>=3B >=3B variables in C.
>=3B >=3B<=> >BR>>=3B >=3B-- Tony
>=3B >=3B
>=3B >=3BOn 12 Jan 2009=3D2=> >C at 11:55=3D2C Jay wrote:
>=3B >=3B
>=3B >=3BI considered AD=> >DRESS.However I think it still doesn't satisfy. I want to be=3D
>=3B &=> >gt=3B able to do this: TYPE Foo_t =3D3D something=3D3B<=3B* EXTERNAL *>=> >=3B VAR Foo1=3D2C Foo=3D
>=3B >=3B2:Foo_t=3D3B<=3B* EXTERNAL *>=> >=3B PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t)=3D
>=3B >=3B=> >=3D3B (* Modula-3=3D2C not external *)PROCEDURE x()=3D3DBEGIN UseFoo(Foo1)=> >=3D3B U=3D
>=3B >=3BseFoo(Foo2)=3D3BEND x=3D3B AND I want any use of=> >:VAR Foo3:Foo3_t=3D3B (* Modula-3=3D
>=3B >=3B=3D2C not external *)t=> >o error. This is sem_t and sigset_t in particular. Poss=3D
>=3B >=3B=> >ibly renaming is the thing.They used to be declared in Modula-3=3D2C system=> >-d=3D
>=3B >=3Bependently=3D2C butI moved them to portable C. I coul=> >d remove the types entir=3D
>=3B >=3Bely and change UseFoo to take a=> >n address=3D2Cand declare mask and ackSem to b=3D
>=3B >=3Be integer=> >s or I guess.<=3B*EXTERNAL>=3B VAR ackSem : RECORD END=3D3B That would => >sat=3D
>=3B >=3Bisfy but I thought it might be nicer to still provid=> >e the namedtypes to ref=3D
>=3B >=3Ber to the external variables. - => >Jay
>=3B >=3B
>=3B >=3BFrom: hosking at cs.purdue.eduTo: jay.kre=> >ll at cornell.eduDate: Mon=3D2C 12 Jan 200=3D
>=3B >=3B9 11:13:00 +1100=> >CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a=3D
>=3B &g=> >t=3B type's existance but not enough to instantiate it?What's wrong with us=> >ing =3D
>=3B >=3BADDRESS for references to opaque values? If sigset_=> >t is never instantiated=3D
>=3B >=3B in Modula-3=3D2C then why do yo=> >u need it declared there?
>=3B >=3B
>=3B >=3B
>=3B >=> >=3B
>=3B >=3BAntony Hosking | Associate Professor | Computer Science=> > | Purdue University
>=3B >=3B305 N. University Street | West Lafaye=> >tte | IN 47907 | USA
>=3B >=3BOffice +1 765 494 6001 | Mobile +1 765=> > 427 5484
>=3B >=3B
>=3B >=3B
>=3B >=3BOn 12 Jan 2009=> >=3D2C at 01:44=3D2C Jay wrote:
>=3B >=3B
>=3B >=3BIs there a => >way in Modula-3 to declare that a type exists=3D2C and there are <=3B=3D<=> >BR>>=3B >=3B*external*>=3B instances of it=3D2C without "fully" decla=> >ring it=3D2C so that no M=3D
>=3B >=3Bodula-3 can instantiate it? I => >have done this for sigset_t and sem_t=3D2C but =3D
>=3B >=3Bthey cou=> >ld erroneously be instantiated by Modula-3 and I'd like to remove t=3D
&=> >gt=3B >=3Bhat ability to mess up so easily. (* This type is not declared => >correctly. I=3D
>=3B >=3Bt is only instantiated in C code. *) sigset=> >_t =3D3D RECORD END=3D3B(* This typ=3D
>=3B >=3Be is not declared co=> >rrectly. It is only instantiated in C code. *) sem_t =3D
>=3B >=3B=> >=3D3D RECORD END=3D3BIn C I believe you can do this=3D2C like: typedef stru=> >ct fo=3D
>=3B >=3Bo foo_t=3D3B extern foo_t foo=3D3B void UseFoo(foo=> >_t*)=3D3B foo_t* GetFoo=3D
>=3B >=3B(void)=3D3B Thanks=3D2C - Jay=3D=> >
>=3B >=3B
>=3B >=3B--_6117a048-9185-4c03-badb-ef8f93402268_<=> >BR>>=3B >=3BContent-Type: text/html=3B charset=3D"iso-8859-1"
>=3B=> > >=3BContent-Transfer-Encoding: quoted-printable
>=3B >=3B
>=> >=3B >=3B<=3Bhtml>=3B
>=3B >=3B<=3Bhead>=3B
>=3B >=> >=3B<=3Bstyle>=3B
>=3B >=3B.hmmessage P
>=3B >=3B{
>=> >=3B >=3Bmargin:0px=3D3B
>=3B >=3Bpadding:0px
>=3B >=3B}
=> >>=3B >=3Bbody.hmmessage
>=3B >=3B{
>=3B >=3Bfont-size: 10=> >pt=3D3B
>=3B >=3Bfont-family:Verdana
>=3B >=3B}
>=3B >=> >=3B<=3B/style>=3B
>=3B >=3B<=3B/head>=3B
>=3B >=3B<=> >=3Bbody class=3D3D'hmmessage'>=3B
>=3B >=3BThis is what you "have => >to" chose between.<=3BBR>=3B
>=3B >=3BHeader cloning or C code (=> >and C headers).<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=> >=3B
>=3B >=3BCONST or VAR (or functions?)<=3BBR>=3B
>=3B &g=> >t=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BI'm going to likely make=> > the Uerror change tonight.<=3BBR>=3B
>=3B >=3BYou can still vet=> >o it (er=3D2C vote against it :) )<=3BBR>=3B
>=3B >=3B&=3Bnbs=> >p=3D3B<=3BBR>=3B
>=3B >=3BPossibly some convuluted C (enum/#unde=> >f)=3D2C or splitting the Modula-3<=3BBR>=3B
>=3B >=3Bat boundari=> >es that weren't previously believed "natural".<=3BBR>=3B
>=3B >=> >=3B(See how SetupHandlers is ~two lines in Modula-3 and the rest in C=3D3B&=> >lt=3BBR>=3B
>=3B >=3Bthis is partly out of ignorance. I don't know=> > how to write those<=3BBR>=3B
>=3B >=3Btwo lines in C=3D3B and l=> >aziness=3D2C I didn't look into how).<=3BBR>=3B
>=3B >=3B&=3B=> >nbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
&=> >gt=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BRemember I'm sti=> >ll staying away from mainstream platforms=3D2C<=3BBR>=3B
>=3B >=> >=3Bso the value isn't what it might appear to be=3D2C but it is "stage sett=> >ing"=3D
>=3B >=3B=3D2C<=3BBR>=3B
>=3B >=3Band the show mi=> >ght go on. :)<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B<=> >BR>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BAlso=3D2C th=> >e dilemna does get more difficult now=3D2C with the little C header=3D
&=> >gt=3B >=3B cloning that remains.<=3BBR>=3B
>=3B >=3B&=3Bnbs=> >p=3D3B<=3BBR>=3B
>=3B >=3BFor example=3D2C look at Upthreads.i3.=> ><=3BBR>=3B
>=3B >=3BMainly=3D2C look at function prototypes.<=> >=3BBR>=3B
>=3B >=3BConstants and types are "known problems".<=3B=> >BR>=3B
>=3B >=3BPrototypes are gray. They actually tend to be port=> >able.<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=> >=3B >=3BFor example:<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3B=> >BR>=3B
>=3B >=3BTYPE pid_t =3D3D INTEGER=3D3B<=3BBR>=3B
>=> >=3B >=3B&=3Blt=3D3B*EXTERNAL "m3_getpid*&=3Bgt=3D3B PROCEDURE getpi=> >d():pid_t=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B=> >
>=3B >=3Bor leave it alone?<=3BBR>=3B
>=3B >=3Bgetpid is=> > probably the worst example.<=3BBR>=3B
>=3B >=3BIt is so very po=> >rtable declared in Modula-3.<=3BBR>=3B
>=3B >=3BBut still=3D2C i=> >magine pid_t might be 16bits or 32 or 64.<=3BBR>=3B
>=3B >=3BWri=> >ting a wrapper is more portable -- as long as the pid isn't stuff into s=3D=> >
>=3B >=3Bome record that the system defines.<=3BBR>=3B
>=> >=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B&l=> >t=3BBR>=3B
>=3B >=3BAgain=3D2C Upthreads.i3.<=3BBR>=3B
>=> >=3B >=3BWould you like to see it reduced=3D2C or left alone?<=3BBR>=> >=3B
>=3B >=3BOnly deal with the types and initializers=3D2C or also => >the prototypes?<=3BBR>=3B
>=3B >=3BYou know=3D2C I could write a=> > little portable layer=3D2C where all the types ar=3D
>=3B >=3Be poi=> >nters=3D2C always null initialized.<=3BBR>=3B
>=3B >=3BIt would => >buy /some/ portability=3D2C and cost some.<=3BBR>=3B
>=3B >=3B&a=> >mp=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B=> >
>=3B >=3BDo you like the sem_t change? Partly? Not at all?<=3BBR&=> >gt=3B
>=3B >=3BThere is one sem_t in the system. So I moved it to be=> > in C code.<=3BBR>=3B
>=3B >=3BOr=3D2C as I had it before=3D2C d=> >eclared as the max size/align of all the platf=3D
>=3B >=3Borms -- g=> >etting that right is the same work as getting it right "the old wa=3D
&g=> >t=3B >=3By"=3D2C except if you make a mistake=3D2C odds are still good of=> > it being ok.<=3BB=3D
>=3B >=3BR>=3B
>=3B >=3B&=3Bnbsp=> >=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=> >=3B >=3BShould the line be drawn at generating the remaining headers=3D2C=> > rather than=3D
>=3B >=3B eliminating them?<=3BBR>=3B
>=3B => >>=3BUerror.i3 is easily generated. Good enough?<=3BBR>=3B
>=3B &=> >gt=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BUpthread.i3's types can=> > be generated generally as records with opaque array=3D
>=3B >=3Bs w=> >ith the right size and alignment.<=3BBR>=3B
>=3B >=3B&=3Bnbsp=> >=3D3B<=3BBR>=3B
>=3B >=3BOther stuff can be generated or at leas=> >t checked.<=3BBR>=3B
>=3B >=3Be.g. to check that getpid is decla=> >red correctly=3D2C you can assign it to a f=3D
>=3B >=3Bunction poin=> >ter and see if that compiles.<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3=> >B<=3BBR>=3B
>=3B >=3BPerf on Uerror arguably doesn't matter.<=> >=3BBR>=3B
>=3B >=3BIs it only error handling code?<=3BBR>=3BOr=> > do sockets often go down "error" path=3D
>=3B >=3Bs=3D2C because th=> >ey are slow and you are waiting for more data?<=3BBR>=3B
>=3B >=> >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3BAnyway=3D2C point is=3D2C=> > I agree for sure this is valuable=3D2C but I might be h=3D
>=3B >=> >=3Bitting the "tail" of the approach and should switch=3D2C I'm not sure. I=> > keep=3D
>=3B >=3B saying that though=3D2C and then press further.&l=> >t=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=> >=3B&=3Bnbsp=3D3B<=3BBR>=3B
>=3B >=3B&=3Bnbsp=3D3B- Jay<=> >=3BBR>=3B<=3BBR>=3B
>=3B >=3B
>=3B >=3B<=3BHR id=3D3D=> >stopSpelling>=3B
>=3B <=3BBR>=3B
>=3B >=3BFrom: hosking at c=> >s.purdue.edu<=3BBR>=3BTo: jay.krell at cornell.edu<=3BBR>=3BDate: Mon=> >=3D2C 12=3D
>=3B >=3B Jan 2009 19:24:50 +1100<=3BBR>=3BCC: m3dev=> >el at elegosoft.com<=3BBR>=3BSubject: Re: [M3de=3D
>=3B >=3Bvel] de=> >claring a type's existance but not enough to instantiate it?<=3BBR>=3B&=> >lt=3BBR>=3B=3D
>=3B >=3B<=3BBR>=3B
>=3B >=3B<=3BDIV&g=> >t=3B<=3BSPAN class=3D3DEC_Apple-style-span style=3D3D"WORD-SPACING: 0px=> >=3D3B FONT: =3D
>=3B >=3B12px Helvetica=3D3B TEXT-TRANSFORM: none=3D=> >3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-IND=3D
>=3B >=3BENT: 0px=3D3B=> > WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPS=3D
=> >>=3B >=3BE: separate">=3B
>=3B >=3B<=3BDIV style=3D3D"WORD-W=> RAP: break-word">=3B<=3BSPAN class=3D3DEC_Apple-style-span styl=3D
&=> >gt=3B >=3Be=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TR=> >ANSFORM: none=3D3B C=3D
>=3B >=3BOLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-=> >INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-S=3D
>=3B >=3BPACIN=> >G: normal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=3D3DEC_Appl=> >e-style-s=3D
>=3B >=3Bpan style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12=> >px Helvetica=3D3B TEXT-TRANSFORM: n=3D
>=3B >=3Bone=3D3B COLOR: rgb(=> >0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B =3D
&=> >gt=3B >=3BLETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate">=3B<=> >=3BSPAN class=3D3DEC_Apple=3D
>=3B >=3B-style-span style=3D3D"WORD-S=> >PACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRAN=3D
>=3B >=3BSFO=> >RM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SP=> >ACE: no=3D
>=3B >=3Brmal=3D3B LETTER-SPACING: normal=3D3B BORDER-COL=> >LAPSE: separate">=3B<=3BSPAN class=3D3D=3D
>=3B >=3BEC_Apple-sty=> >le-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B T=3D >>>=3B >=3BEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-=> >INDENT: 0px=3D3B WHITE-S=3D
>=3B >=3BPACE: normal=3D3B LETTER-SPACIN=> >G: normal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN =3D
>=3B >=> >=3Bclass=3D3DEC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12=> >px Helvet=3D
>=3B >=3Bica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(=> >0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B=3D
>=3B >=3B WHITE-SPACE: => >normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate=3D
>=> >=3B >=3B">=3B<=3BSPAN class=3D3DEC_Apple-style-span style=3D3D"WORD-S=> >PACING: 0px=3D3B FONT: 12p=3D
>=3B >=3Bx Helvetica=3D3B TEXT-TRANSFO=> >RM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT=3D
>=3B >=> >=3B: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-C=> >OLLAPSE: =3D
>=3B >=3Bseparate">=3B<=3BSPAN class=3D3DEC_Apple-s=> >tyle-span style=3D3D"WORD-SPACING: 0px=3D3B F=3D
>=3B >=3BONT: 12px => >Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEX=> >=3D
>=3B >=3BT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPAC=> >ING: normal=3D3B BORDER-CO=3D
>=3B >=3BLLAPSE: separate">=3B<=3B=> >SPAN class=3D3DEC_Apple-style-span style=3D3D"WORD-SPACING: =3D
>=3B &=> >gt=3B0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rg=> >b(0=3D2C0=3D2C0=3D
>=3B >=3B)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE=> >: normal=3D3B LETTER-SPACING: normal=3D3B B=3D
>=3B >=3BORDER-COLLAP=> >SE: separate">=3B
>=3B >=3B<=3BDIV>=3BPoint taken. &=3Bnbsp=> >=3D3BWe live in a C universe and so need to interact. =3D
>=3B >=3B&=> >amp=3Bnbsp=3D3BI do think your work with the headers is useful=3D2C and I w=> >ant it to=3D
>=3B >=3B continue. &=3Bnbsp=3D3BEspecially in simpl=> >ifying ports.<=3B/DIV>=3B
>=3B >=3B<=3BDIV>=3B<=3BBR>=3B=> ><=3B/DIV>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/S=> >PAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=> >=3B<=3B/DI=3D
>=3B >=3BV>=3B<=3B/SPAN>=3B<=3B/DIV>=3B >>>=3B >=3B<=3BDIV>=3B
>=3B >=3B<=3BDIV>=3BOn 12 Jan 2009=> >=3D2C at 19:18=3D2C Jay wrote:<=3B/DIV>=3B<=3BBR class=3D3DEC_Apple-i=> >nt=3D
>=3B >=3Berchange-newline>=3B
>=3B >=3B<=3BBLOCKQUO=> >TE>=3B<=3BSPAN class=3D3DEC_Apple-style-span style=3D3D"WORD-SPACING: 0=> >px=3D3B=3D
>=3B >=3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=> >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B T=3D
>=3B >=3BEXT-INDENT: 0px=> >=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-=3D
&g=> >t=3B >=3BCOLLAPSE: separate">=3B
>=3B >=3B<=3BDIV class=3D3DEC=> >_hmmessage style=3D3D"FONT-SIZE: 10pt=3D3B FONT-FAMILY: Verdana"=3D
>=> >=3B >=3B>=3BI don't think a development system without C headers is int=> >eresting.. Is i=3D
>=3B >=3Bt really?<=3BBR>=3B&=3Bnbsp=3D3B&=> >lt=3BBR>=3BThe transform I apply at times is wherever there i=3D
>=> >=3B >=3Bs interaction with C code that is described by system-dependent h=> >eaders=3D2C =3D
>=3B >=3Bor perhaps even fairly system-independent h=> >eaders outside the Modula-3 tree=3D
>=3B >=3B=3D2C either write wrap=> >per functions for the functionality in the headers (e.=3D
>=3B >=3Bg=> >. stat=3D2C waitpid)=3D2C which&=3Bnbsp=3D3Bcan be done in a system-inde=> >pendent way=3D
>=3B >=3B=3D2C&=3Bnbsp=3D3Bor move the Modula-3&am=> >p=3Blt=3D3B-&=3Bgt=3D3BC transition higher=3D2C which is=3D
>=3B &g=> >t=3B also usually system-independent=3D2C e.g. ThreadPThreadC_SetupHandlers=> >.<=3BBR>=3B&=3B=3D
>=3B >=3Bnbsp=3D3B<=3BBR>=3BIt is eith=> >er that or clone the headers=3D2C which seems like the w=3D
>=3B >=> >=3Borse evil.<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3BThere is always go=> >ing to be a Modula-3&=3Blt=3D3B-&=3Bgt=3D
>=3B >=3B=3D3BC tran=> >sition=3D2C it is just a matter of where it occurs.<=3BBR>=3B&=3Bnbs=> >p=3D3B<=3BBR>=3B&=3B=3D
>=3B >=3Bnbsp=3D3B- Jay<=3BBR>=3B=> ><=3BBR>=3B
>=3B >=3B<=3BHR id=3D3DEC_stopSpelling>=3B
>=> >=3B >=3B<=3BBR>=3BCC:<=3BSPAN class=3D3DEC_Apple-converted-space>=> >=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BA href=3D3D"mai=3D
>=3B >=> >=3Blto:m3devel at elegosoft.com">=3Bm3devel at elegosoft.com<=3B/A>=3B<=> >=3BBR>=3BFrom:<=3BSPAN class=3D3D=3D
>=3B >=3BEC_Apple-converted=> >-space>=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BA href=3D3D"mailto:hoski=> >ng at cs.purdue=3D
>=3B >=3B.edu">=3Bhosking at cs.purdue.edu<=3B/A>=> >=3B<=3BBR>=3BTo:<=3BSPAN class=3D3DEC_Apple-converted-spac=3D
>=> >=3B >=3Be>=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BA href=3D3D"mailto:=> >jay.krell at cornell.edu">=3Bjay.krell at cornell=3D
>=3B >=3B.edu<=3B=> >/A>=3B<=3BBR>=3BSubject: Re: [M3devel] declaring a type's existance b=> >ut not eno=3D
>=3B >=3Bugh to instantiate it?<=3BBR>=3BDate: Mon=> >=3D2C 12 Jan 2009 12:32:15 +1100<=3BBR>=3B<=3BBR>=3B<=3BB=3D
&=> >gt=3B >=3BR>=3B
>=3B <=3BDIV>=3B<=3BSPAN class=3D3DEC_EC_App=> >le-style-span style=3D3D"WORD-SPACING: 0px=3D3B FON=3D
>=3B >=3BT: 1=> >2px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B=> > TEXT-=3D
>=3B >=3BINDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-=> >SPACING: normal=3D3B BORDER-COLL=3D
>=3B >=3BAPSE: separate">=3B >R>>=3B >=3B<=3BDIV style=3D3D"WORD-WRAP: break-word">=3B<=3BSPAN => >class=3D3DEC_EC_Apple-style-span s=3D
>=3B >=3Btyle=3D3D"WORD-SPACIN=> >G: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D
>=3B >=> >=3B=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: => >normal=3D3B LET=3D
>=3B >=3BTER-SPACING: normal=3D3B BORDER-COLLAPSE=> >: separate">=3B<=3BSPAN class=3D3DEC_EC_Apple=3D
>=3B >=3B-style=> >-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRAN=> >=3D
>=3B >=3BSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-IN=> >DENT: 0px=3D3B WHITE-SPACE: no=3D
>=3B >=3Brmal=3D3B LETTER-SPACING:=> > normal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=3D3D=3D
&g=> >t=3B >=3BEC_EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 1=> >2px Helvetica=3D
>=3B >=3B=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb=> >(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WH=3D
>=3B >=3BITE-SPACE:=> > normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate">=3B&l=> >t=3B=3D
>=3B >=3BSPAN class=3D3DEC_EC_Apple-style-span style=3D3D"WO=> >RD-SPACING: 0px=3D3B FONT: 12p=3D
>=3B >=3Bx Helvetica=3D3B TEXT-TRA=> >NSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT=3D
>=3B &=> >gt=3B: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER=> >-COLLAPSE: =3D
>=3B >=3Bseparate">=3B<=3BSPAN class=3D3DEC_EC_Ap=> >ple-style-span style=3D3D"WORD-SPACING: 0px=3D
>=3B >=3B=3D3B FONT: => >12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D<=> >BR>>=3B >=3B=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER=> >-SPACING: normal=3D3B BO=3D
>=3B >=3BRDER-COLLAPSE: separate">=3B&=> >lt=3BSPAN class=3D3DEC_EC_Apple-style-span style=3D3D"WORD=3D
>=3B >=> >=3B-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B C=> >OLOR: rgb=3D
>=3B >=3B(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHI=> >TE-SPACE: normal=3D3B LETTER-SPACING: n=3D
>=3B >=3Bormal=3D3B BORDE=> >R-COLLAPSE: separate">=3B<=3BSPAN class=3D3DEC_EC_Apple-style-span st=> >=3D
>=3B >=3Byle=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D=> >3B TEXT-TRANSFORM: none=3D3B=3D
>=3B >=3B COLOR: rgb(0=3D2C0=3D2C0)=> >=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER=3D
>=3B &g=> >t=3B-SPACING: normal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=> >=3D3DEC_EC_Apple-st=3D
>=3B >=3Byle-span style=3D3D"WORD-SPACING: 0p=> >x=3D3B FONT: 12px Helvetica=3D3B TEXT-TRANSFO=3D
>=3B >=3BRM: none=> >=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: nor=> >ma=3D
>=3B >=3Bl=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: s=> >eparate">=3B
>=3B >=3B<=3BDIV>=3BJay=3D2C I really think you a=> >re bending over backwards too far just to b=3D
>=3B >=3Be able to sh=> >oe-horn things into C. &=3Bnbsp=3D3BI *like* having the transpar of =3D<=> >BR>>=3B >=3BC header files expressed in Modula-3=3D2C *particularly* fo=> >r system calls=3D2C =3D
>=3B >=3Bwhere you might even be trying to b=> >uild on a system that does not have the =3D
>=3B >=3BC header files => >installed=3D2C even though the libraries exist and can be link=3D
>=3B=> > >=3Bed to. &=3Bnbsp=3D3BFundamentally=3D2C I think anytime the Modula=> >-3 code is made l=3D
>=3B >=3Bess transparent you should think hard => >about what you are doing. &=3Bnbsp=3D3BThe=3D
>=3B >=3B same with=> > the change of constants to variables.<=3B/DIV>=3B
>=3B >=3B<=> >=3BDIV>=3B<=3BBR>=3B<=3B/DIV>=3B
>=3B >=3B<=3BDIV>=3BI=> > am getting very nervous that the changes you are making are destroyi=3D >>>=3B >=3Bng the clarity of the Modula-3 run-time code.<=3B/DIV>=3B=> >
>=3B >=3B<=3BDIV>=3B<=3BBR>=3B<=3B/DIV>=3B
>=3B &g=> >t=3B<=3BDIV>=3BIn this particular case=3D2C you are wanting to use a Mo=> >dula-3 parameter=3D
>=3B >=3B passing mechanism on something that is=> > not declared in Modula-3. &=3Bnbsp=3D3BS=3D
>=3B >=3Beems kind o=> >f dubious to me. &=3Bnbsp=3D3BAlso=3D2C I really don't like the idea of=> >=3D
>=3B >=3B accessing external variables in C.<=3B/DIV>=3B
=> >>=3B >=3B<=3BDIV>=3B<=3BBR>=3B<=3B/DIV>=3B
>=3B >=3B=> ><=3BDIV>=3B-- Tony<=3B/DIV>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=> >=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPA=> >N>=3B<=3B/SPAN>=3B<=3B=3D
>=3B >=3B/DIV>=3B<=3B/SPAN>=> >=3B<=3B/DIV>=3B<=3BBR>=3B
>=3B >=3B<=3BDIV>=3B
>=3B=> > >=3B<=3BDIV>=3BOn 12 Jan 2009=3D2C at 11:55=3D2C Jay wrote:<=3B/DI=> >V>=3B<=3BBR class=3D3DEC_EC_Apple-=3D
>=3B >=3Binterchange-newli=> >ne>=3B
>=3B >=3B<=3BBLOCKQUOTE>=3B<=3BSPAN class=3D3DEC_EC_A=> >pple-style-span style=3D3D"WORD-SPACING: 0px=3D
>=3B >=3B=3D3B FONT:=> > 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D=> >
>=3B >=3B=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTE=> >R-SPACING: normal=3D3B BO=3D
>=3B >=3BRDER-COLLAPSE: separate">=3B=> >
>=3B >=3B<=3BDIV class=3D3DEC_EC_hmmessage style=3D3D"FONT-SIZE: => >10pt=3D3B FONT-FAMILY: Verda=3D
>=3B >=3Bna">=3BI considered ADDRE=> >SS.<=3BBR>=3BHowever I think it still doesn't satisfy.<=3BBR>=3B&am=> >p=3B=3D
>=3B >=3Bnbsp=3D3B<=3BBR>=3BI want to be able to do this=> >:<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3BTYPE&=3Bnbsp=3D3BFoo_t =3D<=> >BR>>=3B >=3B=3D3D something=3D3B<=3BBR>=3B&=3Blt=3D3B* EXTERNAL => >*&=3Bgt=3D3B VAR Foo1=3D2C Foo2:Foo_t=3D3B<=3BBR>=3B&=3B=3D
&g=> >t=3B >=3Blt=3D3B* EXTERNAL *&=3Bgt=3D3B PROCEDURE&=3Bnbsp=3D3BUseFo=> >o(READONLY (* or VAR *) foo:F=3D
>=3B >=3Boo_t)=3D3B<=3BBR>=3B&a=> >mp=3Bnbsp=3D3B<=3BBR>=3B(* Modula-3=3D2C not external *)<=3BBR>=3BP=> >ROCEDURE x()=3D3D<=3B=3D
>=3B >=3BBR>=3BBEGIN<=3BBR>=3B&=> >=3Bnbsp=3D3B UseFoo(Foo1)=3D3B<=3BBR>=3B&=3Bnbsp=3D3B UseFoo(Foo2)=> >=3D3B<=3BBR>=3BEND x=3D
>=3B >=3B=3D3B<=3BBR>=3B&=3Bnbsp=> >=3D3B<=3BBR>=3BAND I want any use of:<=3BBR>=3BVAR Foo3:Foo3_t=3D3B=> > (* Modula-3=3D
>=3B >=3B=3D2C not external *)<=3BBR>=3B<=3BBR=> >>=3Bto error. This is sem_t and sigset_t in particul=3D
>=3B >=3Ba=> >r.<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3BPossibly renaming is the thin=> >g.<=3BBR>=3BThey used to be decla=3D
>=3B >=3Bred in Modula-3=3D=> >2C system-dependently=3D2C but<=3BBR>=3BI moved them to portable C.=3D<=> >BR>>=3B >=3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3BI could remove => >the types entirely and change UseFoo to take=3D
>=3B >=3B an address=> >=3D2C<=3BBR>=3Band declare mask and ackSem to be integers or I guess.&l=> >t=3BBR=3D
>=3B >=3B>=3B&=3Blt=3D3B*EXTERNAL&=3Bgt=3D3B VAR a=> >ckSem&=3Bnbsp=3D3B: RECORD END=3D3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BB=> >R>=3BTha=3D
>=3B >=3Bt would satisfy but I thought it might be nic=> >er to still provide the named<=3B=3D
>=3B >=3BBR>=3Btypes to ref=> >er to the external variables.<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B&a=> >mp=3Bnbsp=3D3B- Jay<=3BB=3D
>=3B >=3BR>=3B<=3BBR>=3B
>=> >=3B >=3B<=3BHR id=3D3DEC_EC_stopSpelling>=3B
>=3B >=3B<=3BBR=> >>=3BFrom:<=3BSPAN class=3D3DEC_EC_Apple-converted-space>=3B&=3Bnbs=> >p=3D3B<=3B/SPAN>=3B<=3BA href=3D
>=3B >=3B=3D3D"mailto:hosking=> >@cs.purdue.edu">=3Bhosking at cs.purdue.edu<=3B/A>=3B<=3BBR>=3BTo:&l=> >t=3BSPAN cla=3D
>=3B >=3Bss=3D3DEC_EC_Apple-converted-space>=3B&am=> >p=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BA href=3D3D"mailto:jay.krell=3D
>=> >=3B >=3B at cornell.edu">=3Bjay.krell at cornell.edu<=3B/A>=3B<=3BBR>=> >=3BDate: Mon=3D2C 12 Jan 2009 11:13:0=3D
>=3B >=3B0 +1100<=3BBR>=> >=3BCC:<=3BSPAN class=3D3DEC_EC_Apple-converted-space>=3B&=3Bnbsp=3D3=> >B<=3B/SPAN>=3B<=3BA h=3D
>=3B >=3Bref=3D3D"mailto:m3devel at eleg=> >osoft.com">=3Bm3devel at elegosoft.com<=3B/A>=3B<=3BBR>=3BSubject: => >=3D
>=3B >=3BRe: [M3devel] declaring a type's existance but not enou=> >gh to instantiate it=3D
>=3B >=3B?<=3BBR>=3B<=3BBR>=3BWhat's=> > wrong with using ADDRESS for references to opaque values? &=3B=3D
&g=> >t=3B >=3Bnbsp=3D3BIf sigset_t is never instantiated in Modula-3=3D2C then=> > why do you nee=3D
>=3B >=3Bd it declared there?<=3BBR>=3B
&g=> >t=3B >=3B<=3BDIV>=3B<=3BBR>=3B
>=3B >=3B<=3BDIV>=3B<=> >=3BSPAN class=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D=> >3B =3D
>=3B >=3BFONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B => >COLOR: rgb(0=3D2C0=3D2C0)=3D3B TE=3D
>=3B >=3BXT-INDENT: 0px=3D3B WH=> >ITE-SPACE: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-C=3D
>=3B &g=> >t=3BOLLAPSE: separate">=3B
>=3B >=3B<=3BDIV style=3D3D"WORD-WRAP=> >: break-word">=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-spa=3D
>=> >=3B >=3Bn style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEX=> >T-TRANSFORM: non=3D
>=3B >=3Be=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B T=> >EXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LE=3D
>=3B >=3BTTER-SP=> >ACING: normal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=3D3DEC_=> >EC_EC_A=3D
>=3B >=3Bpple-style-span style=3D3D"WORD-SPACING: 0px=3D3=> >B FONT: 12px Helvetica=3D3B TEXT-=3D
>=3B >=3BTRANSFORM: none=3D3B C=> >OLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE=3D
>=> >=3B >=3B: normal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separa=> >te">=3B<=3BSPAN clas=3D
>=3B >=3Bs=3D3DEC_EC_EC_Apple-style-span=> > style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helv=3D
>=3B >=3Betica=> >=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT:=> > 0px=3D
>=3B >=3B=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: norm=> >al=3D3B BORDER-COLLAPSE: separ=3D
>=3B >=3Bate">=3B<=3BSPAN clas=> >s=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B =3D
&g=> >t=3B >=3BFONT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=> >=3D2C0=3D2C0)=3D3B TE=3D
>=3B >=3BXT-INDENT: 0px=3D3B WHITE-SPACE: n=> >ormal=3D3B LETTER-SPACING: normal=3D3B BORDER-C=3D
>=3B >=3BOLLAPSE:=> > separate">=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-span style=3D3D"W=> >ORD-SP=3D
>=3B >=3BACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-TR=> >ANSFORM: none=3D3B COLOR: rgb(0=3D
>=3B >=3B=3D2C0=3D2C0)=3D3B TEXT-=> >INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: nor=3D
>=3B => >>=3Bmal=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=3D3DEC_EC_E=> >C_Apple-style-span s=3D
>=3B >=3Btyle=3D3D"WORD-SPACING: 0px=3D3B FO=> >NT: 12px Helvetica=3D3B TEXT-TRANSFORM: none=3D
>=3B >=3B=3D3B COLOR=> >: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LE=> >T=3D
>=3B >=3BTER-SPACING: normal=3D3B BORDER-COLLAPSE: separate">=> >=3B<=3BSPAN class=3D3DEC_EC_EC_Ap=3D
>=3B >=3Bple-style-span style=> >=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px Helvetica=3D3B TEXT-T=3D
>=3B => >>=3BRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=> >=3D3B WHITE-SPACE:=3D
>=3B >=3B normal=3D3B LETTER-SPACING: normal=> >=3D3B BORDER-COLLAPSE: separate">=3B<=3BSPAN class=3D
>=3B >=3B=> >=3D3DEC_EC_EC_Apple-style-span style=3D3D"WORD-SPACING: 0px=3D3B FONT: 12px=> > Helve=3D
>=3B >=3Btica=3D3B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=> >=3D2C0=3D2C0)=3D3B TEXT-INDENT: 0px=3D
>=3B >=3B=3D3B WHITE-SPACE: n=> >ormal=3D3B LETTER-SPACING: normal=3D3B BORDER-COLLAPSE: separ=3D
>=3B => >>=3Bate">=3B
>=3B >=3B<=3BDIV>=3B<=3BFONT class=3D3DEC_EC_=> >EC_Apple-style-span color=3D3D#0000ff>=3B<=3BFONT class=3D3D=3D
>=> >=3B >=3BEC_EC_EC_Apple-style-span face=3D3D"Gill Sans">=3B<=3BSPAN cl=> >ass=3D3DEC_EC_EC_Apple-s=3D
>=3B >=3Btyle-span style=3D3D"COLOR: rgb=> >(0=3D2C0=3D2C255)=3D3B FONT-FAMILY: 'Gill Sans'">=3B<=3BSP=3D
>=3B=> > >=3BAN class=3D3DEC_EC_EC_Apple-style-span style=3D3D"COLOR: rgb(0=3D2C0=> >=3D2C255)=3D3B FO=3D
>=3B >=3BNT-FAMILY: 'Gill Sans'">=3BAntony Ho=> >sking<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/FONT>=3B<=3B/FONT>=3B&l=> >t=3BFONT cla=3D
>=3B >=3Bss=3D3DEC_EC_EC_Apple-style-span face=3D3D"=> >Gill Sans">=3B<=3BSPAN class=3D3DEC_EC_EC_Ap=3D
>=3B >=3Bple-sty=> >le-span style=3D3D"FONT-FAMILY: 'Gill Sans'">=3B<=3BSPAN class=3D3DEC_E=> >C_EC_Ap=3D
>=3B >=3Bple-style-span style=3D3D"FONT-FAMILY: 'Gill San=> >s'">=3B<=3BSPAN class=3D3DEC_EC_Apple=3D
>=3B >=3B-converted-spa=> >ce>=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B|<=3BSPAN class=3D3DEC_EC_Apple-=> >converted-space>=3B=3D
>=3B >=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B&=> >lt=3B/SPAN>=3B<=3B/SPAN>=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-=> >span style=3D
>=3B >=3B=3D3D"FONT-FAMILY: 'Gill Sans'">=3B<=3BSP=> >AN class=3D3DEC_EC_EC_Apple-style-span style=3D
>=3B >=3B=3D3D"FONT-=> >FAMILY: 'Gill Sans'">=3BAssociate Professor<=3B/SPAN>=3B<=3B/SPAN&g=> >t=3B<=3BSPAN class=3D
>=3B >=3B=3D3DEC_EC_EC_Apple-style-span styl=> >e=3D3D"FONT-FAMILY: 'Gill Sans'">=3B<=3BSPAN class=3D
>=3B >=3B=> >=3D3DEC_EC_EC_Apple-style-span style=3D3D"FONT-FAMILY: 'Gill Sans'">=3B&a=> >mp=3Bnbsp=3D3B| C=3D
>=3B >=3Bomputer Science | Purdue University<=> >=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/FONT>=3B<=3B/DIV>=3B
>=3B => >>=3B<=3BDIV>=3B<=3BFONT class=3D3DEC_EC_EC_Apple-style-span face=3D=> >3DGillSans-Light>=3B<=3BSPAN cl=3D
>=3B >=3Bass=3D3DEC_EC_EC_App=> >le-style-span style=3D3D"FONT-FAMILY: GillSans-Light">=3B305 N=3D
>=> >=3B >=3B. University Street | West Lafayette | IN 47907 | USA<=3B/SPAN&=> >gt=3B<=3B/FONT>=3B<=3B/DIV>=3B
>=3B >=3B<=3BDIV>=3B<=> >=3BFONT class=3D3DEC_EC_EC_Apple-style-span face=3D3D"Gill Sans" color=3D3D=> >#00=3D
>=3B >=3B00ff>=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-=> >span style=3D3D"COLOR: rgb(0=3D2C0=3D2C25=3D
>=3B >=3B5)=3D3B FONT-F=> >AMILY: 'Gill Sans'">=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-span sty=> >=3D
>=3B >=3Ble=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=3D3B FONT-FAMILY: '=> >Gill Sans'">=3BOffice<=3B/SPAN>=3B<=3B/S=3D
>=3B >=3BPAN>=> >=3B<=3B/FONT>=3B<=3BFONT class=3D3DEC_EC_EC_Apple-style-span face=3D3=> >DGillSans-Light>=3B<=3BS=3D
>=3B >=3BPAN class=3D3DEC_EC_EC_Appl=> >e-style-span style=3D3D"FONT-FAMILY: GillSans-Light"=3D
>=3B >=3B>=> >=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-span style=3D3D"FONT-FAMILY: G=> >illSans-Lig=3D
>=3B >=3Bht">=3B&=3Bnbsp=3D3B+1 765 494 6001 |&l=> >t=3BSPAN class=3D3DEC_EC_Apple-converted-space>=3B&=3Bnbs=3D
>=3B=> > >=3Bp=3D3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/FONT=> >>=3B<=3BFONT class=3D3DEC_EC_EC_Apple-style-span fac=3D
>=3B >=> >=3Be=3D3D"Gill Sans" color=3D3D#0000ff>=3B<=3BSPAN class=3D3DEC_EC_EC_A=> >pple-style-span sty=3D
>=3B >=3Ble=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=> >=3D3B FONT-FAMILY: 'Gill Sans'">=3B<=3BSPAN class=3D3DEC=3D
>=3B &=> >gt=3B_EC_EC_Apple-style-span style=3D3D"COLOR: rgb(0=3D2C0=3D2C255)=3D3B FO=> >NT-FAMILY: 'G=3D
>=3B >=3Bill Sans'">=3BMobile<=3B/SPAN>=3B<=> >=3B/SPAN>=3B<=3B/FONT>=3B<=3BFONT class=3D3DEC_EC_EC_Apple-style-sp=> >=3D
>=3B >=3Ban face=3D3DGillSans-Light>=3B<=3BSPAN class=3D3DEC=> >_EC_EC_Apple-style-span style=3D3D"F=3D
>=3B >=3BONT-FAMILY: GillSan=> >s-Light">=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-span style=3D
&g=> >t=3B >=3B=3D3D"FONT-FAMILY: GillSans-Light">=3B<=3BSPAN class=3D3DEC_=> >EC_Apple-converted-space>=3B=3D
>=3B >=3B&=3Bnbsp=3D3B<=3B/SP=> >AN>=3B+1 765 427 5484<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/FONT>=3B&=> >lt=3B/DIV>=3B
>=3B >=3B<=3BDIV>=3B<=3BFONT class=3D3DEC_EC_E=> >C_Apple-style-span face=3D3DGillSans-Light>=3B<=3BBR clas=3D
>=3B => >>=3Bs=3D3DEC_EC_EC_khtml-block-placeholder>=3B<=3B/FONT>=3B<=3B/D=> >IV>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SP=3D
=> >>=3B >=3BAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=3B/SPAN>=3B<=> >=3BBR class=3D3DEC_EC_EC_Apple-interchange-newline>=3B<=3B/SP=3D
>=> >=3B >=3BAN>=3B<=3B/DIV>=3B<=3B/SPAN>=3B<=3B/DIV>=3B<=3BBR=> >>=3B
>=3B >=3B<=3BDIV>=3B
>=3B >=3B<=3BDIV>=3BOn 12=> > Jan 2009=3D2C at 01:44=3D2C Jay wrote:<=3B/DIV>=3B<=3BBR class=3D3DE=> >C_EC_EC_App=3D
>=3B >=3Ble-interchange-newline>=3B
>=3B >=> >=3B<=3BBLOCKQUOTE>=3B<=3BSPAN class=3D3DEC_EC_EC_Apple-style-span sty=> >le=3D3D"WORD-SPACING: =3D
>=3B >=3B0px=3D3B FONT: 12px Helvetica=3D3=> >B TEXT-TRANSFORM: none=3D3B COLOR: rgb(0=3D2C0=3D2C0=3D
>=3B >=3B)=> >=3D3B TEXT-INDENT: 0px=3D3B WHITE-SPACE: normal=3D3B LETTER-SPACING: normal=> >=3D3B B=3D
>=3B >=3BORDER-COLLAPSE: separate">=3B
>=3B >=3B=> ><=3BDIV class=3D3DEC_EC_EC_hmmessage style=3D3D"FONT-SIZE: 10pt=3D3B FONT=> >-FAMILY: Ve=3D
>=3B >=3Brdana">=3BIs there a way in Modula-3 to de=> >clare that&=3Bnbsp=3D3Ba type exists=3D2C a=3D
>=3B >=3Bnd there => >are &=3Blt=3D3B*external*&=3Bgt=3D3B instances of it=3D2C without "fu=> >lly" decl=3D
>=3B >=3Baring it=3D2C so that no Modula-3 can instanti=> >ate it?<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3BI have d=3D
>=3B &g=> >t=3Bone this for sigset_t and sem_t=3D2C but they could erroneously be inst=> >antiat=3D
>=3B >=3Bed by Modula-3 and I'd like to remove that abilit=> >y to mess up so easily.<=3BBR=3D
>=3B >=3B>=3B&=3Bnbsp=3D3B&l=> >t=3BBR>=3B(* This type is not declared correctly. It is only instantiate=> >=3D
>=3B >=3Bd in C code. *)<=3BBR>=3B&=3Bnbsp=3D3B sigset_t => >=3D3D RECORD END=3D3B<=3BBR>=3B<=3BBR>=3B(* This type =3D
>=3B=> > >=3Bis not declared correctly. It is only instantiated in C code. *)<=> >=3BBR>=3B&=3Bnbsp=3D
>=3B >=3B=3D3B sem_t =3D3D RECORD END=3D3B=> ><=3BBR>=3B<=3BBR>=3BIn C I believe you can do this=3D2C like:<=3B=> >=3D
>=3B >=3BBR>=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3Btypedef struct => >foo foo_t=3D3B&=3Bnbsp=3D3B<=3BSPAN class=3D3DEC_EC_E=3D
>=3B >=> >=3BC_Apple-converted-space>=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BBR&g=> >t=3B&=3Bnbsp=3D3B&=3Bnbsp=3D3Bextern foo_t foo=3D
>=3B >=3B=3D=> >3B&=3Bnbsp=3D3B<=3BSPAN class=3D3DEC_EC_EC_Apple-converted-space>=3B=> >&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BBR>=3B=3D
>=3B >=3B&=3Bn=> >bsp=3D3B<=3BBR>=3B&=3Bnbsp=3D3Bvoid UseFoo(foo_t*)=3D3B<=3BSPAN cl=> >ass=3D3DEC_EC_EC_Apple-conv=3D
>=3B >=3Berted-space>=3B&=3Bnbsp=> >=3D3B<=3B/SPAN>=3B<=3BBR>=3B&=3Bnbsp=3D3B foo_t* GetFoo(void)=3D=> >3B<=3BSPAN class=3D
>=3B >=3B=3D3DEC_EC_EC_Apple-converted-space&g=> >t=3B&=3Bnbsp=3D3B<=3B/SPAN>=3B<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR=> >>=3BThanks=3D2C<=3B=3D
>=3B >=3BBR>=3B&=3Bnbsp=3D3B- Jay<=> >=3BBR>=3B<=3BBR>=3B<=3BBR>=3B<=3BBR>=3B<=3B/DIV>=3B<=3B=> >/SPAN>=3B<=3B/BLOCKQUOTE>=3B<=3B/DIV>=3B<=3BBR>=3B<=3B/DIV&=> >gt=3B<=3B=3D
>=3B >=3B/DIV>=3B<=3B/SPAN>=3B<=3BBR class=3D=> >3DEC_EC_Apple-interchange-newline>=3B<=3B/BLOCKQUOTE>=3B<=3B/DIV>=> >=3B=3D
>=3B >=3B<=3BBR>=3B<=3B/DIV>=3B<=3B/SPAN>=3B<=> >=3BBR class=3D3DEC_Apple-interchange-newline>=3B<=3B/BLOCKQUOTE>=3B&l=> >t=3B/DI=3D
>=3B >=3BV>=3B<=3BBR>=3B<=3B/body>=3B
>=3B=> > >=3B<=3B/html>=3B=3D
>=3B >=3B
>=3B >=3B--_6117a048-91=> >85-4c03-badb-ef8f93402268_--

> >=> >> >--_2e194b09-14b6-4301-9116-a9e4d1e522b4_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 12:45:23 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 11:45:23 +0000 Subject: [M3devel] map/def files to limit exports to only functions in interfaces Message-ID: On Windows, a "def" file lists extra linker parameters, mainly a list of functions to export. On most Posix systems, a "map" serves the same purpose. On Windows, a "map" file is actually a linker output, that is roughly, a text file with some symbol information. On Windows, the default set of functions to export is empty. You can either decorate your source code with __declspec(dllexport), or write a .def file. Some build systems -- including cm3 -- grovel .obj files and put every symbol in the .def file. Typical Unix behavior is to export all symbols. More so, typical Unix behavior is to try to make "shared objects" very much like "objects". In particular, to treat all the shared objects within a process as containing one global/pooled namespace. Therefore, the first shared object loaded that exports a function named "open", is the target of any unresolved links to the symbol "open". This is a feature. It lets folks "interpose" and/or "preload" their own special shared object that implements whatever function in its own special way. Such dynamic resolution occurs by default for all non-static symbols. I'm not sure how it works out, but two shared objects might contain a function foo, that they each call, expecting to their own, but as I understand, they might both call the first loaded one. You can control linking presumably by declaring functions static, but that doesn't work if you have multiple source files in your shared object and want to call between them. There are some details I am uncertain of, to be sure. > This is a feature.. But, I believe it is more broadly understood to be a mistake. At some early point, like around 10.2, Apple changed from a "flat namespace" to "two level namespace". That is, when I link, on the development machine, "open" was found in e.g. "libc.so", so in my foo.exe, not just the symbol "open" is recorded, but "libc" is associated with it. So at load time, "open" is not looked at in all shared objects, but only in "libc" (could there be more than one, in different directories, I don't know). Is this just a "hint" or it "must be so"? I'm not sure. Solaris linker man pages give the "export everything" as the historical default, but not the recommended practise. There is a paper by the Linux ld.so maintainer -- Ulrich Drepper -- with advise I believe compatible with my thinking. Limit exports to only what you intend. Bind symbols locally that you implement. Don't leave all symbols "interposable", only ones you intend to import from somewhere else. When I was debugging AMD64_LINUX months ago, I found that even nested functions were exported and interposable, and the delayed resolution of them trashed the static link. So at the time I changed just their behavior. There is new syntax and command line flags to gcc to control what they call "visibility". Historical default, everything is visible/exported. Current guidance is, switch the default to not exported, and "decorate" source code with "__attribute__" or a wrapper macro thereof. SO...... Today we export "every" function -- including functions not defined in an .i3 file. This is inefficient. I strongly propose that we generate "def" files for Win32 and "map" files for "everyone else" (being sure to read up on the Solaris linker, GNU linker, BSD linkers, and later Irix, AIX, HP-UX, OSF, etc.) that list only functions in .i3 files, and the module_m3 and/or _i3 symbols, whatever is needed. I've already done some initial investigation here. It is doable in the front end but I believe m3linker is the right place. The front end visits interface/module at a time, whereas this work needs to be done once per "package" or "library", and cannot really be done incrementally, and it is small anyway. We don't need signatures, just lists of functions (and, on some systems..variables) in interfaces. Actually, I think this work could lead to "fixing data imports on Win32", but that's another subject and it is likely avoidable (you would change all cross-interface variable references to go through pointers, in case they are imported, then linker can synthesize the pointers if ends up not imported, kind of backwards from the way importing functions where, where the default is a direct call and linker can synthesize thunks for imports). Reasonable? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 15:05:34 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 14:05:34 +0000 Subject: [M3devel] a note on user thread -- *context not 'universal' Message-ID: just a note, that make/get/set/swapcontext are not available on Darwin (10.4) and OpenBSD.I didn't check NetBSD. It is on Linux, Solaris, FreeBSD. A "dual" approach where some ports use setjmp/longjmp, some use *context, probably reasonable. Another approach that would probably work is you double up the jmpbuf.Always make a copy before setjmp and setjmp to the copy.That way if longjmp "scrambles" it, no matter.If you can't even copy them, well, setjmp to the "original", copy it away, and thenrecopy before any setjmp. However, this is inefficient and using *context is probably better, where it is available. question: On Windows, you can "reserve" virtual memory, and "commit" it."reserve" is allocating just the address space."commit" I think is ensuring there is room in a pagefile.Reserve is cheaper. You can overrreserve but I guess not long-term overcommit.Usually stacks are only ever at first reserved, and then commited gradually,like a page at a time. Whatever *context documentation I could find, didn't talk about this.They either used a local char array, or a called mmap.On at least some platforms, there a flag to mmap to indicate you are creating a stack. Do we really need the assembly _fpsetjmp? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Jan 12 15:30:20 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 12 Jan 2009 15:30:20 +0100 Subject: [M3devel] a note on user thread -- *context not 'universal' In-Reply-To: References: Message-ID: <20090112153020.qff8fc7eioc8kocs@mail.elegosoft.com> Quoting Jay : > Do we really need the assembly _fpsetjmp? IIRC, I introduced fpsetjmp/fplongjmp when I made the first FreeBSD code, as FreeBSD does not care about storing the floating point state, and spurious FP errors occured when switching threads by longjmp. I think Bruce Evans contributed the FreeBSD assembler code. It may be that Darwin, which is derived from FreeBSD in certain areas, has inherited this problem (I don't remember offhand, and I haven't done much BSD or M3 programming in recent months). I think no other systems needed to use specially crafted setjmp/longjmp pairs to accomodate the M3 user threads. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Mon Jan 12 22:04:02 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 13 Jan 2009 08:04:02 +1100 Subject: [M3devel] a note on user thread -- *context not 'universal' In-Reply-To: <20090112153020.qff8fc7eioc8kocs@mail.elegosoft.com> References: <20090112153020.qff8fc7eioc8kocs@mail.elegosoft.com> Message-ID: <9C37CD59-A42F-4B4F-BE9D-2295817B1C71@cs.purdue.edu> makecontext/getcontext/setcontext and friends are both available on Darwin and should do FP state properly. On 13 Jan 2009, at 01:30, Olaf Wagner wrote: > Quoting Jay : > >> Do we really need the assembly _fpsetjmp? > > IIRC, I introduced fpsetjmp/fplongjmp when I made the first FreeBSD > code, > as FreeBSD does not care about storing the floating point state, > and spurious FP errors occured when switching threads by longjmp. > I think Bruce Evans contributed the FreeBSD assembler code. > > It may be that Darwin, which is derived from FreeBSD in certain areas, > has inherited this problem (I don't remember offhand, and I haven't > done much BSD or M3 programming in recent months). I think no other > systems needed to use specially crafted setjmp/longjmp pairs to > accomodate the M3 user threads. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hosking at cs.purdue.edu Mon Jan 12 22:01:33 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 13 Jan 2009 08:01:33 +1100 Subject: [M3devel] a note on user thread -- *context not 'universal' In-Reply-To: References: Message-ID: <19C99B21-4997-4ABB-8BD2-4992FD0513AE@cs.purdue.edu> They *are* available on Darwin 10.5 and I am pretty sure they were there on 10.4. Have you installed the developer kit (with man pages)? On 13 Jan 2009, at 01:05, Jay wrote: > just a note, that make/get/set/swapcontext are not available on > Darwin (10.4) and OpenBSD. > I didn't check NetBSD. It is on Linux, Solaris, FreeBSD. > > > A "dual" approach where some ports use setjmp/longjmp, some use > *context, probably reasonable. > > > Another approach that would probably work is you double up the jmpbuf. > Always make a copy before setjmp and setjmp to the copy. > That way if longjmp "scrambles" it, no matter. > If you can't even copy them, well, setjmp to the "original", copy it > away, and then > recopy before any setjmp. > > > However, this is inefficient and using *context is probably better, > where it is available. > > > question: > > > On Windows, you can "reserve" virtual memory, and "commit" it. > "reserve" is allocating just the address space. > "commit" I think is ensuring there is room in a pagefile. > Reserve is cheaper. You can overrreserve but I guess not long-term > overcommit. > Usually stacks are only ever at first reserved, and then commited > gradually, > like a page at a time. > > > Whatever *context documentation I could find, didn't talk about this. > They either used a local char array, or a called mmap. > On at least some platforms, there a flag to mmap to indicate you are > creating a stack. > > > Do we really need the assembly _fpsetjmp? > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 23:20:24 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 22:20:24 +0000 Subject: [M3devel] a note on user thread -- *context not 'universal' In-Reply-To: <19C99B21-4997-4ABB-8BD2-4992FD0513AE@cs.purdue.edu> References: <19C99B21-4997-4ABB-8BD2-4992FD0513AE@cs.purdue.edu> Message-ID: They really don't seem to be there, on 10.4. I haven't check the libs yet but they are not in the headers or man pages. Do you have installed the "multiple SDKs" (headers/libs for multiple OS versions)? Look at in /Developer/SDKs. Anyway, they also aren't on OpenBSD so a dual approach will be needed which I think is ok. Heck, probably one set of Modula-3 but #ifdefed C. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Tue, 13 Jan 2009 08:01:33 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] a note on user thread -- *context not 'universal' They *are* available on Darwin 10.5 and I am pretty sure they were there on 10.4. Have you installed the developer kit (with man pages)? On 13 Jan 2009, at 01:05, Jay wrote: just a note, that make/get/set/swapcontext are not available on Darwin (10.4) and OpenBSD.I didn't check NetBSD. It is on Linux, Solaris, FreeBSD. A "dual" approach where some ports use setjmp/longjmp, some use *context, probably reasonable. Another approach that would probably work is you double up the jmpbuf.Always make a copy before setjmp and setjmp to the copy.That way if longjmp "scrambles" it, no matter.If you can't even copy them, well, setjmp to the "original", copy it away, and thenrecopy before any setjmp. However, this is inefficient and using *context is probably better, where it is available. question: On Windows, you can "reserve" virtual memory, and "commit" it."reserve" is allocating just the address space."commit" I think is ensuring there is room in a pagefile.Reserve is cheaper. You can overrreserve but I guess not long-term overcommit.Usually stacks are only ever at first reserved, and then commited gradually,like a page at a time. Whatever *context documentation I could find, didn't talk about this.They either used a local char array, or a called mmap.On at least some platforms, there a flag to mmap to indicate you are creating a stack. Do we really need the assembly _fpsetjmp? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 12 23:39:01 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 12 Jan 2009 22:39:01 +0000 Subject: [M3devel] cygwin/pthread still broken fyi Message-ID: Just fyi, I tried cygwin with pthreads and it crashes in "startup" (well, it gets as far as sysutils entry which is pretty far) Switched back to Wni32 threads, no crash. I will debug more later. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Jan 13 00:23:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 13 Jan 2009 10:23:36 +1100 Subject: [M3devel] a note on user thread -- *context not 'universal' In-Reply-To: References: <19C99B21-4997-4ABB-8BD2-4992FD0513AE@cs.purdue.edu> Message-ID: <8FA8E456-79FB-40CE-A7CA-D53DE0E88980@cs.purdue.edu> Hmm, weird -- I am sure I looked at that a long time back. On 13 Jan 2009, at 09:20, Jay wrote: > They really don't seem to be there, on 10.4. > I haven't check the libs yet but they are not in the headers or man > pages. > Do you have installed the "multiple SDKs" (headers/libs for multiple > OS versions)? > Look at in /Developer/SDKs. > Anyway, they also aren't on OpenBSD so a dual approach will be needed > which I think is ok. > Heck, probably one set of Modula-3 but #ifdefed C. > > - Jay > > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 13 Jan 2009 08:01:33 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] a note on user thread -- *context not > 'universal' > > > They *are* available on Darwin 10.5 and I am pretty sure they were > there on 10.4. Have you installed the developer kit (with man pages)? > > On 13 Jan 2009, at 01:05, Jay wrote: > > just a note, that make/get/set/swapcontext are not available on > Darwin (10.4) and OpenBSD. > I didn't check NetBSD. It is on Linux, Solaris, FreeBSD. > > > A "dual" approach where some ports use setjmp/longjmp, some use > *context, probably reasonable. > > > Another approach that would probably work is you double up the jmpbuf. > Always make a copy before setjmp and setjmp to the copy. > That way if longjmp "scrambles" it, no matter. > If you can't even copy them, well, setjmp to the "original", copy it > away, and then > recopy before any setjmp. > > > However, this is inefficient and using *context is probably better, > where it is available. > > > question: > > > On Windows, you can "reserve" virtual memory, and "commit" it. > "reserve" is allocating just the address space. > "commit" I think is ensuring there is room in a pagefile. > Reserve is cheaper. You can overrreserve but I guess not long-term > overcommit. > Usually stacks are only ever at first reserved, and then commited > gradually, > like a page at a time. > > > Whatever *context documentation I could find, didn't talk about this. > They either used a local char array, or a called mmap. > On at least some platforms, there a flag to mmap to indicate you are > creating a stack. > > > Do we really need the assembly _fpsetjmp? > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eiserlohpp at yahoo.com Tue Jan 13 08:31:27 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Mon, 12 Jan 2009 23:31:27 -0800 (PST) Subject: [M3devel] dynamic chose between user/kernel threads? Message-ID: <486480.21981.qm@web56801.mail.re3.yahoo.com> >> [Jay] Some programs "better" with user threads >> [Tony] Is this still true for modern kernel thread systems? > >I really don't know. >Olaf /kind of/ indicated so (just in saying that it'd be a nice option to have). > >> [Jay] small stacks for many threads vs. larger stacks for calls to "the system" >> [Tony] In a systems programming language like Modula-3 shouldn't threads have a relationship to the system? >> Is it a boolean or an enum? >> Cygwin might conceivably get pthreads support (Cygwin has it, but >> Modula-3/Cygwin does not). >> Therefore, is the choice among "posix" threads, "pthreads" and "NT" >> threads? >> Or just user vs. kernel? > >I would argue for user vs. kernel. Correct me if I am wrong, but don't user threads all run in the same process, and therefore, can't make use of multi-processors (ie, SMP machines). Many people now even have dual core machines, or even quad core, let alone motherboards with many processors on them. At least with Linux, the old system thread library (I forgot its name, it been a number of years) used user level threads. Then Linus invented the clone() system call, which acted similarly to a fork(), but kept the same virtual memory and file contexts. This allowed threads to act like processes, and migrate to other processors of an SMP machine. This is what the Linux implementation of the pthread library currently uses, to take advantage of modern machine architectures. This is a kernel thread under Linux. This should be significant reason for prefering the pthread threading library, and should probably be the default. Default to "kernel" theads. Allow "user" threads. Don't make it a binary choice. If a port wants to make available a third (or fourth) threading option they should be able to do so. Just don't expect many people to jump up and down for joy. If a platform does not support kernel threads, (eg, PalmOS) uh ... (what we don't support it yet), then only support user threads. If a port were to be built that ran on bare hardware (such as the "SPIN" OS) they would have to implement their own thread mechanism, and must not include any support for a thread library which expects to be in user space with a kernel providing OS support. BTW: I think putting IF statements in all the threading code looks ugly. Couldn't you implement it as an OBJECT ThreadMechanism, and derive the specific mechanisms: ThreadUserMechanism, ThreadPThreadMechanism, ThreadWinNTMechanism, ThreadDoItYourselfMechanism. The startup code would choose which one to instantiate. All thread and mutex calls would use that object to perform its action. +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From jay.krell at cornell.edu Tue Jan 13 09:19:17 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 13 Jan 2009 08:19:17 +0000 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: <486480.21981.qm@web56801.mail.re3.yahoo.com> References: <486480.21981.qm@web56801.mail.re3.yahoo.com> Message-ID: > Terminology wrong, but your point is correct. A "process" is an "address space" and isolation boundary for security. A thread is a unit of scheduling, a stack and register context. "Straightforward" user threads indeed, you would only ever run one at a time, per process, even on a multi threaded systems. People speak of N:M 1:1 or N:1 One number is number of user threads. The other is kernel threads. You can have a hybrid where some number of user threads are scheduled on some smaller number of kernel threads. You can have one to one. You can have one kernel thread (e.g. on a system without kernel threads-- just processes) that you use to run multiple user threads. Historically N:1 was the only option. Then some people moved to N:M. Such as older releases of Solaris. These days almost everything is 1:1. However some people still don't think this is clearly and always best. And on rare occasion, perhaps it is not. N:M is an interesting hybrid, it gives user threads a chance to scale on a multiprocessor. But it is probably the most difficult to implement. If you read near the beginning of the 2nd edition of "Solaris Internals" they talk about some of this, and how Solaris 10 (9?) improved things by making it all "1:1". I consider user threads extremely uninteresting but folks here are vocally interested in them. And right there are systems without kernel threads. Like, I've been thinking of making a I386_MSDOS_DJGPP or such release. It appears to have sufficient support for the user threads -- alarm(). > IF looks ugly. Couldn't you implement it as an OBJECT I said function pointers at one point. Same thing. If it was IF, it'd be an extra layer outside all of the "real" code and so wouldn't be ugly at all. But maybe slower. Something I've been meaning to ask. The old Linux library was "LinuxThreads". "NPTL" is the Native PThread Library. Modula-3 only seemed to switch to pthreads with NPTL widely available. But I assume the pthreads interface was implemented over LinuxThreads? Couldn't Modula-3 have used that, earlier? That is, couldn't Modula-3 using pthreads claim to work to older versions?There's a comment in thread/m3makefile that suggests NPTL is required. I guess it is moot. NPTL is here and nobody probably runs the older stuff?? (I ran Modula-3/LINUXELF briefly on 1.2. Imho binary compatibility mandates that it should still work... certainly I continue to use Windows software from the same time period every day.) - Jay> Date: Mon, 12 Jan 2009 23:31:27 -0800> From: eiserlohpp at yahoo.com> To: m3devel at elegosoft.com> Subject: [M3devel] dynamic chose between user/kernel threads?> > >> [Jay] Some programs "better" with user threads> >> [Tony] Is this still true for modern kernel thread systems?> >> >I really don't know.> >Olaf /kind of/ indicated so (just in saying that it'd be a nice option to have).> >> >> [Jay] small stacks for many threads vs. larger stacks for calls to "the system"> >> [Tony] In a systems programming language like Modula-3 shouldn't threads have a relationship to the system?> > > >> Is it a boolean or an enum?> >> Cygwin might conceivably get pthreads support (Cygwin has it, but > >> Modula-3/Cygwin does not).> >> Therefore, is the choice among "posix" threads, "pthreads" and "NT" > >> threads?> >> Or just user vs. kernel?> >> >I would argue for user vs. kernel.> > > Correct me if I am wrong, but don't user threads all run> in the same process, and therefore, can't make use of> multi-processors (ie, SMP machines). Many people now even> have dual core machines, or even quad core, let alone > motherboards with many processors on them.> > At least with Linux, the old system thread library (I> forgot its name, it been a number of years) used user> level threads. Then Linus invented the clone() system> call, which acted similarly to a fork(), but kept the> same virtual memory and file contexts. This allowed> threads to act like processes, and migrate to other> processors of an SMP machine.> > This is what the Linux implementation of the pthread> library currently uses, to take advantage of modern> machine architectures. This is a kernel thread under> Linux.> > This should be significant reason for prefering the pthread> threading library, and should probably be the default.> > Default to "kernel" theads. Allow "user" threads. Don't> make it a binary choice. If a port wants to make available> a third (or fourth) threading option they should be able> to do so. Just don't expect many people to jump up and> down for joy.> > If a platform does not support kernel threads, (eg, PalmOS)> uh ... (what we don't support it yet), then only support> user threads. > > If a port were to be built that ran on bare hardware (such> as the "SPIN" OS) they would have to implement their own> thread mechanism, and must not include any support for a> thread library which expects to be in user space with a> kernel providing OS support.> > BTW: I think putting IF statements in all the threading> code looks ugly. Couldn't you implement it as an OBJECT> ThreadMechanism, and derive the specific mechanisms:> ThreadUserMechanism, > ThreadPThreadMechanism, > ThreadWinNTMechanism,> ThreadDoItYourselfMechanism.> > The startup code would choose which one to instantiate.> All thread and mutex calls would use that object to > perform its action.> > > +--------------------------------------------------------+> | Peter P. Eiserloh |> +--------------------------------------------------------+> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jan 13 15:54:38 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 13 Jan 2009 14:54:38 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: > fix for old compilers that can't compile LONGINT: define LongRep.T = INTEGER Is that what bootstrapping should do? Automate that little patch for the first pass and undo it in the second? Then always building in dependency order? Tonight I was trying to build from PPC_DARWIN 5.5.0. I figured, heck, maybe it supports LONGINT already, maybe I should just try building up in dependency order. But then I hit the problem of Compiler.i3 mismatch due to new targets. So...is that correct? Does building in dependency order predictably fail if compiler has fewer targets than runtime? But starting with existing m3core/libm3 and first building the compiler against them predictably works? I've added targets a bunch and usually don't have a problem, but I can't say for certain what order I do things when I do this. Certainly "upgrade.py skipgcc" is something I run fairly often. It is very fast on NT386 (and unlike upgrade.sh, it doesn't build all of std). For now I put in two small hacks to sysutils, so it works with old m3core. I was stuck otherwise. The hacks are: - assume kernel threads or "single threaded" That is -- always pass 0 for the waitpid option. If sysutils client is multithreaded (always the case), and parent threads depend on child processes (not always the case), and user threads (really not always the case), then there risk of deadlock. - if status is non zero but lower 8 bits are zero, set it to 1, to ensure non-zero in lower bits This could be done correctly by copying the current Uexec code into sysutils. Maybe Compiler.i3 can somehow be implemented to "just work"? And eliminate the redundancy as well? Have the compiler inject its definition into m3core/libm3? - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Mon, 12 Jan 2009 19:22:13 +1100 CC: jkrell at elego.de; m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 I think there is a straightforward fix for old compilers that can't compile LONGINT: define LongRep.T = INTEGER. Most everything should compile from there. That's what I recall doing to upgrade my compiler to handle LONGINT. LONGINT is not used anywhere else in m3core, so nothing depends on it working. On 12 Jan 2009, at 19:02, Jay wrote:If old compiler can't build m3core, such as if old compiler predates LONGINT. You already know this. Are we "past" such compilers? - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Mon, 12 Jan 2009 18:51:08 +1100 CC: jkrell at elego.de; m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Why do you not build in the following order to get a new compiler? (You may need to downgrade Compiler.tmpl for use with an old compiler so that you don't get a mismatch between m3core and libm3, but otherwise the following sequence should work). m3corelibm3sysutilsm3middlem3objfilem3linkerm3backm3frontm3quakecm3 On 12 Jan 2009, at 18:25, Jay wrote:The compiler uses sysutils. The first pass builds against an old package store, which might not have sysutils at all, if it is that old. Again, once new m3core is around, no problem. I could/should have put in the m3core change and just waited on the sysutils change, rather than go ahead and do the quake stuff, and we can do that now (or your change that moots it, which I haven't looked into yet). I was browsing the docs and it appears there is an "import_pkg" directive for like, copying in a package contents, instead of linking. That might also solve this. I found that relatively late and never looked into it. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Mon, 12 Jan 2009 18:19:55 +1100 CC: jkrell at elego.de; m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Not true. sysutils should be built against the m3core with which it will be linked. I don't think this is correct. On 12 Jan 2009, at 17:58, Jay wrote:To bootstrap I believe. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Mon, 12 Jan 2009 17:53:02 +1100 CC: jkrell at elego.de; m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Why does sysutils need to be compatible with both old and new versions of m3core? On 12 Jan 2009, at 17:39, Jay wrote:ThreadPosix is basically unaffected -- I never provided user threads on Cygwin. I guess it got a slight reduction regarding DoesWaitPidYield, but its SchedulerPosix implementation was unchanged. The code in ThreadPosix is similar to but different than ThreadPThread. It is possible they could be merged but it wasn't trivial so I left ThreadPosix alone. > You are smearing implementation details across multiple files and directories You really think it is bad to have SchedulerPosix implemented in a small separate file? On top of what happens to be common implementation details of ThreadPThread.m3 and ThreadWin32.m3? ThreadPScheduler.m3 is just basically three functions: IOWait, IOAlertWait, XIOWait Plus the little internal utility, UTimeFromTime, the one liner DoesWaitPidYield, and non-trivial functions nested in XIOWait: TestFDS, CallSelect. I mean, you know, an alternative is to copy out very large chunks of ThreadWin32.m3 and ThreadPThread.m3 and merge them into ThreadCygwin.m3. That would be worse imho. "Directories" hardly. Or I can try debugging cygwin pthreads again. - Jay CC: jkrell at elego.de; m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Date: Mon, 12 Jan 2009 12:46:54 +1100 You are smearing implementation details across multiple files and directories. Up until now, ThreadPThread has been nicely self-contained, and captured all the basic pieces of the thread implementation. Also, how does all of this fit with the ThreadPosix implementation? On 12 Jan 2009, at 12:19, Jay wrote:btw, I don't think it's that hairy, I merely split it into two or three files, and added interfaces so they can reuse code with each other. Movement between files is hard to track though (depending on version control, but with all I've used). The SchedulerPosix implementation moved to ThreadPScheduler.m3. What is shared between it and ThreadPThread/Win32.m3 is ThreadInternal.i3, which maybe should be in ThreadF.i3, though that's exposed outside m3core, and ThreadInternal.i3 includes a variable. I can try again to debug Cygwin pthreads though. - Jay > From: hosking at cs.purdue.edu > To: jkrell at elego.de > Date: Mon, 12 Jan 2009 11:03:33 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Jay, > > Can you remind me again why Cygwin was unable to use pthreads? It > seems you have introduced a bunch of hair into the PTHREADS > implementation to deal with broken Cygwin pthreads. As many of us > have already pointed out, Cygwin should be a port that tries as much > as possible to be like a standard POSIX platform (pthread-based) as > opposed to a weird Windows/POSIX hybrid. > > I have a bunch of code that will be going into the PTHREADS base that > I am now at a loss to integrate with the changes you have made. > > Help! > > -- Tony > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Jan 13 16:06:21 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 13 Jan 2009 16:06:21 +0100 Subject: [M3devel] dynamic chose between user/kernel threads? In-Reply-To: References: <486480.21981.qm@web56801.mail.re3.yahoo.com> Message-ID: <20090113160621.07cnshm5cgc0s0w8@mail.elegosoft.com> If I remember correctly, until Antony Hosking provided the PThreads implementation, M3 only used its own user-level threads on all POSIX platforms (but not on Windows). The ability to use system pthread libraries has been added rather late. (M3's) user level threads are extremely fast and use little resources (configurable stack sizes). External system threads have a little more overhead due to the extra user/kernel mode switches for all scheduling related activies. They have got the advantage that they can be used for scaling across multiple processors (which wasn't possible with M3 on Unix until recently). I agree that these days kernel threads should be the default, as they are available on almost every system and usually reasonably stable and fast (which was not so when M3 was created). Nonetheless M3's user level threads can have advantages for certain uses and should not be discarded, as they have proven to be mature and useful. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Jan 13 16:08:45 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 13 Jan 2009 16:08:45 +0100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: <20090113160845.y5ucq4et28o484cs@mail.elegosoft.com> Quoting Jay : > > > fix for old compilers that can't compile LONGINT: define > LongRep.T = INTEGER > > Is that what bootstrapping should do? > Automate that little patch for the first pass and undo it in the second? > Then always building in dependency order? > > > Tonight I was trying to build from PPC_DARWIN 5.5.0. > I figured, heck, maybe it supports LONGINT already, maybe I should just try > building up in dependency order. > But then I hit the problem of Compiler.i3 mismatch due to new targets. > > > So...is that correct? > Does building in dependency order predictably fail if compiler has > fewer targets than runtime? > But starting with existing m3core/libm3 and first building the > compiler against them predictably works? As far as I remember it has always been this way with (C)M3. Runtime and compiler must agree wrt. target platforms. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Jan 13 19:45:43 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 13 Jan 2009 18:45:43 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20090113160845.y5ucq4et28o484cs@mail.elegosoft.com> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> <20090113160845.y5ucq4et28o484cs@mail.elegosoft.com> Message-ID: > As far as I remember it has always been this way with (C)M3.> Runtime and compiler must agree wrt. target platforms.> > Olaf I /think/ they can disagree, as long as you don't build the runtime. That is, when you add new platforms, you build the updated compiler first, against an old runtime, then build the updated runtime. I'm just speculating though based on my being stuck last night trying to build m3core first, vs. that I often build the compiler first. I also wonder if it must be this way -- if the compiler can't inject into the runtime its list of targets. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 14 00:11:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 14 Jan 2009 10:11:36 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: On 14 Jan 2009, at 01:54, Jay wrote: > > fix for old compilers that can't compile LONGINT: define > LongRep.T = INTEGER > > Is that what bootstrapping should do? > Automate that little patch for the first pass and undo it in the > second? > Then always building in dependency order? I would prefer to get all the bootstrap archives LONGINT-capable. Just do the patch by hand to build the initial archives and then forget about it. > Tonight I was trying to build from PPC_DARWIN 5.5.0. > I figured, heck, maybe it supports LONGINT already, maybe I should > just try > building up in dependency order. > But then I hit the problem of Compiler.i3 mismatch due to new targets. > So...is that correct? > Does building in dependency order predictably fail if compiler has > fewer targets than runtime? > But starting with existing m3core/libm3 and first building the > compiler against them predictably works? Yes, it works. > I've added targets a bunch and usually don't have a problem, but I > can't say for certain what > order I do things when I do this. > Certainly "upgrade.py skipgcc" is something I run fairly often. > It is very fast on NT386 (and unlike upgrade.sh, it doesn't build > all of std). Sounds like your upgrade script > For now I put in two small hacks to sysutils, so it works with old > m3core. No! I did not want to do have this hack. Let's just fix the boot archives to handle new m3core and have sysutils work as expected. The alternative is to fold sysutils into m3core, where it can be used directly. That might be a better solution given the dependency. Thoughts? > I was stuck otherwise. > > > The hacks are: > - assume kernel threads or "single threaded" > That is -- always pass 0 for the waitpid option. > If sysutils client is multithreaded (always the case), > and parent threads depend on child processes (not always the > case), > and user threads (really not always the case), > then there risk of deadlock. > > - if status is non zero but lower 8 bits are zero, set it to 1, to > ensure non-zero in lower bits > This could be done correctly by copying the current Uexec code > into sysutils. > > > Maybe Compiler.i3 can somehow be implemented to "just work"? > And eliminate the redundancy as well? > Have the compiler inject its definition into m3core/libm3? > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 19:22:13 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > I think there is a straightforward fix for old compilers that can't > compile LONGINT: define LongRep.T = INTEGER. Most everything should > compile from there. That's what I recall doing to upgrade my > compiler to handle LONGINT. LONGINT is not used anywhere else in > m3core, so nothing depends on it working. > > On 12 Jan 2009, at 19:02, Jay wrote: > > If old compiler can't build m3core, such as if old compiler predates > LONGINT. > You already know this. > Are we "past" such compilers? > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 18:51:08 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > Why do you not build in the following order to get a new compiler? > (You may need to downgrade Compiler.tmpl for use with an old > compiler so that you don't get a mismatch between m3core and libm3, > but otherwise the following sequence should work). > > m3core > libm3 > sysutils > m3middle > m3objfile > m3linker > m3back > m3front > m3quake > cm3 > > On 12 Jan 2009, at 18:25, Jay wrote: > > The compiler uses sysutils. The first pass builds against an old > package store, which might not have sysutils at all, if it is that > old. > > Again, once new m3core is around, no problem. > I could/should have put in the m3core change and just waited on the > sysutils change, rather than go ahead and do the quake stuff, and we > can do that now (or your change that moots it, which I haven't > looked into yet). > > I was browsing the docs and it appears there is an "import_pkg" > directive for like, copying in a package contents, instead of > linking. That might also solve this. I found that relatively late > and never looked into it. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 18:19:55 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Not true. sysutils should be built against the m3core with which it > will be linked. I don't think this is correct. > > On 12 Jan 2009, at 17:58, Jay wrote: > > To bootstrap I believe. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 12 Jan 2009 17:53:02 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Why does sysutils need to be compatible with both old and new > versions of m3core? > > On 12 Jan 2009, at 17:39, Jay wrote: > > ThreadPosix is basically unaffected -- I never provided user threads > on Cygwin. > I guess it got a slight reduction regarding DoesWaitPidYield, but > its SchedulerPosix implementation was unchanged. > > The code in ThreadPosix is similar to but different than > ThreadPThread. > It is possible they could be merged but it wasn't trivial so I left > ThreadPosix alone. > > > You are smearing implementation details across multiple files and > directories > > You really think it is bad to have SchedulerPosix implemented in a > small separate file? > On top of what happens to be common implementation details of > ThreadPThread.m3 and ThreadWin32.m3? > > ThreadPScheduler.m3 is just basically three functions: IOWait, > IOAlertWait, XIOWait > Plus the little internal utility, UTimeFromTime, the one liner > DoesWaitPidYield, and non-trivial functions nested in XIOWait: > TestFDS, CallSelect. > > I mean, you know, an alternative is to copy out very large chunks of > ThreadWin32.m3 and ThreadPThread.m3 and merge them into > ThreadCygwin.m3. That would be worse imho. > > "Directories" hardly. > > Or I can try debugging cygwin pthreads again. > > - Jay > > > CC: jkrell at elego.de; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Mon, 12 Jan 2009 12:46:54 +1100 > > You are smearing implementation details across multiple files and > directories. Up until now, ThreadPThread has been nicely self- > contained, and captured all the basic pieces of the thread > implementation. Also, how does all of this fit with the ThreadPosix > implementation? > > On 12 Jan 2009, at 12:19, Jay wrote: > > btw, I don't think it's that hairy, I merely split it into two or > three files, and added interfaces so they can reuse code with each > other. Movement between files is hard to track though (depending on > version control, but with all I've used). > > The SchedulerPosix implementation moved to ThreadPScheduler.m3. > What is shared between it and ThreadPThread/Win32.m3 is > ThreadInternal.i3, which maybe should be in ThreadF.i3, though > that's exposed outside m3core, and ThreadInternal.i3 includes a > variable. > > I can try again to debug Cygwin pthreads though. > > - Jay > > > > From: hosking at cs.purdue.edu > > To: jkrell at elego.de > > Date: Mon, 12 Jan 2009 11:03:33 +1100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay, > > > > Can you remind me again why Cygwin was unable to use pthreads? It > > seems you have introduced a bunch of hair into the PTHREADS > > implementation to deal with broken Cygwin pthreads. As many of us > > have already pointed out, Cygwin should be a port that tries as much > > as possible to be like a standard POSIX platform (pthread-based) as > > opposed to a weird Windows/POSIX hybrid. > > > > I have a bunch of code that will be going into the PTHREADS base > that > > I am now at a loss to integrate with the changes you have made. > > > > Help! > > > > -- Tony > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jan 14 01:09:03 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 14 Jan 2009 00:09:03 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: > Sounds like your upgrade script Based on someone else's upgrade.sh. > The alternative is to fold sysutils into m3core, where it can be used directly Merging sysutils into m3core doesn't quite work, again only or due to bootstrapping from older builds. The compiler uses sysutils. Older builds don't have it at all, and can't build m3core...but maybe again, make that hand patch Long.Rep = INTEGER? Or have an up to date compiler. Pointless statement I'm making though, it devolves to: - have an up to date m3core in bootstrap - or have sysutils in bootstrap, which implies up to date m3core - or merge sysutils with m3core, which implies up to date m3core (and the second) => "have an up to date m3core" (and LONGINT capable compiler) And I think merging them is a fine idea. I generally like fewer larger pieces of reusable code, though the counterpoint is to have more smaller independently changable pieces. Probably the scripts and/or m3makefiles should probe the compiler version and/or m3core version and/or sysutils presence and error clearly if it is too old/absent. Possibly some "feature detection" feature is needed. The compiler can just define Quake variables willy/nilly. if defined("HAS_LONGINT") Less clear how to probe m3core capability. Can try compiling a little program against the old WaitProcess signature. I'm leary of anything that resembles autoconf though (though I have autoconf-ish stuff in my config files already, probing some cm3cg and cm3 behavior). Oh...I looked at WaitProcess history. It looks like I introduced it, in 2008. So..while it never returned the full status word, there also wasn't much history to change. Compiler could expose m3core functionality via variables too, though that..is wrong. It could only expose the m3core it is linked to, not the one it is building. I guess the only way really is to define a version or date constant and folks can write constant expressions based on it, though that doesn't get you very far. Less clear how to correctly probe for package existance. Easy to do ad-hoc by probing package store files, not sure what is the right way. I also want to try this "import_pkg" directive I see in the docs. It might help a lot here, if I understand it, and if it actually exists and resembles the doc I read. It sounds like it recompiles a package's source as part of another package, statically linking it. It would be bloating in the absence of build_standalone(), but not in its presence. > No! I did not want to do have this hack Are the hacks this time in sysutils really so bad? m3core is left unadulterated. sysutils assumes waitpid(0) won't deadlock, which is true of kernel threads and cm3's use. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Wed, 14 Jan 2009 10:11:36 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3 On 14 Jan 2009, at 01:54, Jay wrote: > fix for old compilers that can't compile LONGINT: define LongRep.T = INTEGERIs that what bootstrapping should do? Automate that little patch for the first pass and undo it in the second? Then always building in dependency order? I would prefer to get all the bootstrap archives LONGINT-capable. Just do the patch by hand to build the initial archives and then forget about it. Tonight I was trying to build from PPC_DARWIN 5.5.0.I figured, heck, maybe it supports LONGINT already, maybe I should just trybuilding up in dependency order.But then I hit the problem of Compiler.i3 mismatch due to new targets. So...is that correct?Does building in dependency order predictably fail if compiler has fewer targets than runtime?But starting with existing m3core/libm3 and first building the compiler against them predictably works? Yes, it works. I've added targets a bunch and usually don't have a problem, but I can't say for certain whatorder I do things when I do this.Certainly "upgrade.py skipgcc" is something I run fairly often.It is very fast on NT386 (and unlike upgrade.sh, it doesn't build all of std). Sounds like your upgrade script For now I put in two small hacks to sysutils, so it works with old m3core. No! I did not want to do have this hack. Let's just fix the boot archives to handle new m3core and have sysutils work as expected. The alternative is to fold sysutils into m3core, where it can be used directly. That might be a better solution given the dependency. Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 14 02:49:41 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 14 Jan 2009 12:49:41 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> Message-ID: <2FFBEA2D-98BF-4268-977C-4A4B38664B08@cs.purdue.edu> The current hack is not so bad, I suppose. I would prefer to come up with a solution that simply defines Process.Wait and System.Wait as returning a BOOLEAN indicating if the process terminated successfully or not. Are there any clients of these procedures that decode the bits in any more detail than simply testing non-zero? On 14 Jan 2009, at 11:09, Jay wrote: > > Sounds like your upgrade script > > Based on someone else's upgrade.sh. > > > > The alternative is to fold sysutils into m3core, where it can be > used directly > > Merging sysutils into m3core doesn't quite work, > again only or due to bootstrapping from older builds. > > The compiler uses sysutils. Older builds don't have it at all, > and can't build m3core...but maybe again, make that hand patch > Long.Rep = INTEGER? Or have an up to date compiler. > > > > Pointless statement I'm making though, it devolves to: > > > - have an up to date m3core in bootstrap > - or have sysutils in bootstrap, which implies up to date m3core > - or merge sysutils with m3core, which implies up to date m3core > (and the second) > => "have an up to date m3core" (and LONGINT capable compiler) > > And I think merging them is a fine idea. > I generally like fewer larger pieces of reusable code, though > the counterpoint is to have more smaller independently changable > pieces. > > > Probably the scripts and/or m3makefiles should probe the compiler > version > and/or m3core version and/or sysutils presence and error clearly if > it is too old/absent. > > Possibly some "feature detection" feature is needed. > > The compiler can just define Quake variables willy/nilly. > if defined("HAS_LONGINT") > Less clear how to probe m3core capability. > Can try compiling a little program against the old WaitProcess > signature. > I'm leary of anything that resembles autoconf though (though I > have autoconf-ish > stuff in my config files already, probing some cm3cg and cm3 > behavior). > Oh...I looked at WaitProcess history. It looks like I introduced > it, in 2008. > So..while it never returned the full status word, there also > wasn't much history > to change. > Compiler could expose m3core functionality via variables too, > though that..is wrong. > It could only expose the m3core it is linked to, not the one it > is building. > I guess the only way really is to define a version or date > constant and folks > can write constant expressions based on it, though that doesn't > get you very far. > > Less clear how to correctly probe for package existance. > Easy to do ad-hoc by probing package store files, not sure what is > the right way. > > > I also want to try this "import_pkg" directive I see in the docs. > It might help a lot here, > if I understand it, and if it actually exists and resembles the > doc I read. > It sounds like it recompiles a package's source as part of another > package, statically > linking it. It would be bloating in the absence of > build_standalone(), but not in its presence. > > > > No! I did not want to do have this hack > > Are the hacks this time in sysutils really so bad? > m3core is left unadulterated. > sysutils assumes waitpid(0) won't deadlock, which is true of kernel > threads and cm3's use. > > - Jay > > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Wed, 14 Jan 2009 10:11:36 +1100 > CC: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > On 14 Jan 2009, at 01:54, Jay wrote: > > > fix for old compilers that can't compile LONGINT: define > LongRep.T = INTEGER > > Is that what bootstrapping should do? > Automate that little patch for the first pass and undo it in the > second? > Then always building in dependency order? > > I would prefer to get all the bootstrap archives LONGINT-capable. > Just do the patch by hand to build the initial archives and then > forget about it. > > Tonight I was trying to build from PPC_DARWIN 5.5.0. > I figured, heck, maybe it supports LONGINT already, maybe I should > just try > building up in dependency order. > But then I hit the problem of Compiler.i3 mismatch due to new targets. > > So...is that correct? > Does building in dependency order predictably fail if compiler has > fewer targets than runtime? > But starting with existing m3core/libm3 and first building the > compiler against them predictably works? > > Yes, it works. > > I've added targets a bunch and usually don't have a problem, but I > can't say for certain what > order I do things when I do this. > Certainly "upgrade.py skipgcc" is something I run fairly often. > It is very fast on NT386 (and unlike upgrade.sh, it doesn't build > all of std). > > Sounds like your upgrade script > > For now I put in two small hacks to sysutils, so it works with old > m3core. > > No! I did not want to do have this hack. Let's just fix the boot > archives to handle new m3core and have sysutils work as expected. > The alternative is to fold sysutils into m3core, where it can be > used directly. That might be a better solution given the > dependency. Thoughts? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jan 14 03:33:53 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 14 Jan 2009 02:33:53 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <2FFBEA2D-98BF-4268-977C-4A4B38664B08@cs.purdue.edu> References: <20090111135057.EDEFD10D5DA3@birch.elegosoft.com> <601C9855-A4F5-47FC-BEEE-2899FA8A169E@cs.purdue.edu> <32A163F4-96C2-4B9B-A5C6-341D61E6D876@cs.purdue.edu> <2FFBEA2D-98BF-4268-977C-4A4B38664B08@cs.purdue.edu> Message-ID: I /think/ cm3/quake exposes the integer but I'll try to peek around, and at the other clients, and my own uses of try_exec/q_exec. There is /some/ validity to a "rich" exit code, more than 1 bit, but I realize it is controversial. Windows has a 32 bit exit code. Perl on Windows truncates it to 8 bits. When a process exits with a negative exit code, Perl on Windows gets confused and issues a strange error or runs it a second time (as if negative means CreateProcess failed, for a possible reason that the path was wrong.) - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Wed, 14 Jan 2009 12:49:41 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3 The current hack is not so bad, I suppose. I would prefer to come up with a solution that simply defines Process.Wait and System.Wait as returning a BOOLEAN indicating if the process terminated successfully or not. Are there any clients of these procedures that decode the bits in any more detail than simply testing non-zero? On 14 Jan 2009, at 11:09, Jay wrote: > Sounds like your upgrade script Based on someone else's upgrade.sh. > The alternative is to fold sysutils into m3core, where it can be used directly Merging sysutils into m3core doesn't quite work, again only or due to bootstrapping from older builds. The compiler uses sysutils. Older builds don't have it at all, and can't build m3core...but maybe again, make that hand patch Long.Rep = INTEGER? Or have an up to date compiler. Pointless statement I'm making though, it devolves to: - have an up to date m3core in bootstrap - or have sysutils in bootstrap, which implies up to date m3core - or merge sysutils with m3core, which implies up to date m3core (and the second) => "have an up to date m3core" (and LONGINT capable compiler) And I think merging them is a fine idea.I generally like fewer larger pieces of reusable code, thoughthe counterpoint is to have more smaller independently changable pieces. Probably the scripts and/or m3makefiles should probe the compiler version and/or m3core version and/or sysutils presence and error clearly if it is too old/absent. Possibly some "feature detection" feature is needed. The compiler can just define Quake variables willy/nilly. if defined("HAS_LONGINT") Less clear how to probe m3core capability. Can try compiling a little program against the old WaitProcess signature. I'm leary of anything that resembles autoconf though (though I have autoconf-ish stuff in my config files already, probing some cm3cg and cm3 behavior). Oh...I looked at WaitProcess history. It looks like I introduced it, in 2008. So..while it never returned the full status word, there also wasn't much history to change. Compiler could expose m3core functionality via variables too, though that..is wrong. It could only expose the m3core it is linked to, not the one it is building. I guess the only way really is to define a version or date constant and folks can write constant expressions based on it, though that doesn't get you very far. Less clear how to correctly probe for package existance. Easy to do ad-hoc by probing package store files, not sure what is the right way. I also want to try this "import_pkg" directive I see in the docs. It might help a lot here, if I understand it, and if it actually exists and resembles the doc I read. It sounds like it recompiles a package's source as part of another package, statically linking it. It would be bloating in the absence of build_standalone(), but not in its presence. > No! I did not want to do have this hack Are the hacks this time in sysutils really so bad? m3core is left unadulterated. sysutils assumes waitpid(0) won't deadlock, which is true of kernel threads and cm3's use. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Wed, 14 Jan 2009 10:11:36 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3 On 14 Jan 2009, at 01:54, Jay wrote: > fix for old compilers that can't compile LONGINT: define LongRep.T = INTEGERIs that what bootstrapping should do? Automate that little patch for the first pass and undo it in the second? Then always building in dependency order? I would prefer to get all the bootstrap archives LONGINT-capable. Just do the patch by hand to build the initial archives and then forget about it. Tonight I was trying to build from PPC_DARWIN 5.5.0.I figured, heck, maybe it supports LONGINT already, maybe I should just trybuilding up in dependency order.But then I hit the problem of Compiler.i3 mismatch due to new targets. So...is that correct?Does building in dependency order predictably fail if compiler has fewer targets than runtime?But starting with existing m3core/libm3 and first building the compiler against them predictably works? Yes, it works. I've added targets a bunch and usually don't have a problem, but I can't say for certain whatorder I do things when I do this.Certainly "upgrade.py skipgcc" is something I run fairly often.It is very fast on NT386 (and unlike upgrade.sh, it doesn't build all of std). Sounds like your upgrade script For now I put in two small hacks to sysutils, so it works with old m3core. No! I did not want to do have this hack. Let's just fix the boot archives to handle new m3core and have sysutils work as expected. The alternative is to fold sysutils into m3core, where it can be used directly. That might be a better solution given the dependency. Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jan 14 03:57:51 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 14 Jan 2009 02:57:51 +0000 Subject: [M3devel] building all platforms regularly? Message-ID: Hi. On my system I can cd m3-sys/m3cc cm3 -DM3CC_TARGET=platform cd scripts/python ./do-cm3-all.py realclean skipgcc ./do-cm3-std.py platform boot skipgcc ./boot1.py platform and for pretty much "any" platform it pretty much works. Ok, on a 32bit host with a 64bit target, there is an error in JV.i3 or such because, like TextLiteralF.i3, there is a declaration of a maximally sized integer. This is an easy to fix compiler bug, soon. Ratchet it down to just "min" and it works more, since JV.i3 isn't there. The result of this is a .tar.gz containing assembly source for all the Modula-3 code, some .h and .c files, and a Makefile and alternate make.sh. One can takes this to the target system, with a C development environment, and finish the build, giving you a current cm3, which you can then use to build cm3cg, and so on. (Some source files are also in the archive and updatesource.sh, but that's not relevant to this email; they are typically edited files when doing a new port.) So, my point is, maybe this should be run kind of like the Tinderboxes? Spitting out current archives of all "active" platforms, regularly? It is not as "good" as the Tinderbox. There might still be errors in the C, link errors, test failures. But it is pretty good. It gets a bit more testing across platforms and provides a good up to date start. And then, the list of "active" targets needs to be identified. Oh, I forgot to mention, this only currently works for platforms for which there is m3-sys/cminstall/src/config-no-install/platform, and NT386. The others give an error about not liking the "unconfigured" config files in the neighboring config directory. Also, the .tar.gz is presently put at the root, which isn't right. It works ok on Windows. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jan 14 05:16:43 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 14 Jan 2009 04:16:43 +0000 Subject: [M3devel] FW: building all platforms regularly? Message-ID: [was truncated] From: jayTo: m3develSubject: building all platforms regularly?Date: Wed, 14 Jan 2009 02:57:51 +0000 Hi. On my system I can cd m3-sys/m3cc cm3 -DM3CC_TARGET=platform cd scripts/python ./do-cm3-all.py realclean skipgcc ./do-cm3-std.py platform boot skipgcc ./boot1.py platform and for pretty much "any" platform it pretty much works.Ok, on a 32bit host with a 64bit target, there is an error in JV.i3 or such because,like TextLiteralF.i3, there is a declaration of a maximally sized integer.This is an easy to fix compiler bug, soon. Ratchet it down to just "min" and it works more, since JV.i3 isn't there. The result of this is a .tar.gz containing assembly source for all the Modula-3 code,some .h and .c files, and a Makefile and alternate make.sh.One can takes this to the target system, with a C development environment,and finish the build, giving you a current cm3, which you can then use to build cm3cg,and so on. (Some source files are also in the archive and updatesource.sh, but that'snot relevant to this email; they are typically edited files when doing a new port.) So, my point is, maybe this should be run kind of like the Tinderboxes?Spitting out current archives of all "active" platforms, regularly? It is not as "good" as the Tinderbox.There might still be errors in the C, link errors, test failures.But it is pretty good. It gets a bit more testing across platforms and provides a good up to date start. And then, the list of "active" targets needs to be identified. Oh, I forgot to mention, this only currently works for platforms for whichthere is m3-sys/cminstall/src/config-no-install/platform, and NT386.The others give an error about not liking the "unconfigured" config filesin the neighboring config directory. Also, the .tar.gz is presently put at the root, which isn't right.It works ok on Windows. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jan 14 07:53:08 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 14 Jan 2009 06:53:08 +0000 Subject: [M3devel] building all platforms regularly? Message-ID: On the other hand, this is increasingly redundant, what with the increased portability in the system and coming to the system :). And increasingly insufficient, since it doesn't test compilability of the C code. - Jay From: jay.krell at cornell.eduTo: m3devel at elegosoft.comSubject: FW: building all platforms regularly?Date: Wed, 14 Jan 2009 04:16:43 +0000 [was truncated] From: jayTo: m3develSubject: building all platforms regularly?Date: Wed, 14 Jan 2009 02:57:51 +0000 Hi. On my system I can cd m3-sys/m3cc cm3 -DM3CC_TARGET=platform cd scripts/python ./do-cm3-all.py realclean skipgcc ./do-cm3-std.py platform boot skipgcc ./boot1.py platform and for pretty much "any" platform it pretty much works.Ok, on a 32bit host with a 64bit target, there is an error in JV.i3 or such because,like TextLiteralF.i3, there is a declaration of a maximally sized integer.This is an easy to fix compiler bug, soon. Ratchet it down to just "min" and it works more, since JV.i3 isn't there. The result of this is a .tar.gz containing assembly source for all the Modula-3 code,some .h and .c files, and a Makefile and alternate make.sh.One can takes this to the target system, with a C development environment,and finish the build, giving you a current cm3, which you can then use to build cm3cg,and so on. (Some source files are also in the archive and updatesource.sh, but that'snot relevant to this email; they are typically edited files when doing a new port.) So, my point is, maybe this should be run kind of like the Tinderboxes?Spitting out current archives of all "active" platforms, regularly? It is not as "good" as the Tinderbox.There might still be errors in the C, link errors, test failures.But it is pretty good. It gets a bit more testing across platforms and provides a good up to date start. And then, the list of "active" targets needs to be identified. Oh, I forgot to mention, this only currently works for platforms for whichthere is m3-sys/cminstall/src/config-no-install/platform, and NT386.The others give an error about not liking the "unconfigured" config filesin the neighboring config directory. Also, the .tar.gz is presently put at the root, which isn't right.It works ok on Windows. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jan 14 10:14:19 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 14 Jan 2009 09:14:19 +0000 Subject: [M3devel] how to switch between user and kernel threads.. Message-ID: Are people really against using function pointers for this? Either changing the interface to have function pointer variables (I'm not sure Modula-3 allows this, but in C you can fairly transparently replace functions with function pointers; client code just keeps working; it breaks down in C++ with overloading), or having a set of functions that just call/jump through function pointers? There would be no if, no conditional branches. Dynamic linking on Windows always goes through function pointers already. So while yes it adds another instruction, it is already never getting inlined. Don't other platforms do that too? Or they patch every call site? I'm not sure otherwise of a simple method. Easiest might be to have a parallel directory structure to m3core, with just m3core files. That would wastefully rebuild all of m3core a second time, for just a small amount of variation. I think function pointers are the way to go here. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 14 11:31:22 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 14 Jan 2009 21:31:22 +1100 Subject: [M3devel] how to switch between user and kernel threads.. In-Reply-To: References: Message-ID: I don't want dynamic switching. A link-time switch is just fine. Also, please don't go messing about with this right now -- I have changes pending for the threads system that will be harder to integrate if you change with it further. On 14 Jan 2009, at 20:14, Jay wrote: > Are people really against using function pointers for this? > Either changing the interface to have function pointer variables > (I'm not sure Modula-3 allows this, but in C you can fairly > transparently replace functions with function pointers; client code > just keeps working; it breaks down in C++ with overloading), or > having a set of functions that just call/jump through function > pointers? There would be no if, no conditional branches. > > Dynamic linking on Windows always goes through function pointers > already. > So while yes it adds another instruction, it is already never > getting inlined. > Don't other platforms do that too? > Or they patch every call site? > > I'm not sure otherwise of a simple method. > Easiest might be to have a parallel directory structure to m3core, > with just m3core files. > That would wastefully rebuild all of m3core a second time, for just > a small amount of variation. > > I think function pointers are the way to go here. > > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jan 14 22:30:59 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 14 Jan 2009 21:30:59 +0000 Subject: [M3devel] how to switch between user and kernel threads.. In-Reply-To: References: Message-ID: I'll wait. So, build two different m3core.lib/a/so/dylib? m3core and m3coreuserthreads Compile both thread directories, if the platform supports it, and call quake make_lib twice with slightly different parameters? An m3core specific hack in the config file or cm3? Easy enough in the config file. Very m3core specific. I suppose you could argue that quake isn't a generic build system, but it is Modula-3's build system, and that m3core is really special. The result btw, would likely be no change at all to any *.i3 or *.m3 file. I still think function pointers are the way to go. Even with function pointers, the changes to *.i3 and *.m3 would be very minor. Just the export list would vary. And new *.i3 files introduced. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Wed, 14 Jan 2009 21:31:22 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] how to switch between user and kernel threads..I don't want dynamic switching. A link-time switch is just fine. Also, please don't go messing about with this right now -- I have changes pending for the threads system that will be harder to integrate if you change with it further. On 14 Jan 2009, at 20:14, Jay wrote: Are people really against using function pointers for this?Either changing the interface to have function pointer variables (I'm not sure Modula-3 allows this, but in C you can fairly transparently replace functions with function pointers; client code just keeps working; it breaks down in C++ with overloading), or having a set of functions that just call/jump through function pointers? There would be no if, no conditional branches. Dynamic linking on Windows always goes through function pointers already. So while yes it adds another instruction, it is already never getting inlined.Don't other platforms do that too?Or they patch every call site? I'm not sure otherwise of a simple method.Easiest might be to have a parallel directory structure to m3core, with just m3core files.That would wastefully rebuild all of m3core a second time, for just a small amount of variation. I think function pointers are the way to go here. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jan 14 22:34:20 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 14 Jan 2009 21:34:20 +0000 Subject: [M3devel] FW: how to switch between user and kernel threads.. In-Reply-To: References: Message-ID: [truncated again] From: jayTo: hoskingCC: m3develSubject: RE: [M3devel] how to switch between user and kernel threads..Date: Wed, 14 Jan 2009 21:30:59 +0000 I'll wait.So, build two different m3core.lib/a/so/dylib?m3core and m3coreuserthreads Compile both thread directories, if the platform supports it, andcall quake make_lib twice with slightly different parameters?An m3core specific hack in the config file or cm3?Easy enough in the config file.Very m3core specific.I suppose you could argue that quake isn't a generic build system,but it is Modula-3's build system, and that m3core is really special. The result btw, would likely be no change at all to any *.i3 or *.m3 file. I still think function pointers are the way to go.Even with function pointers, the changes to *.i3 and *.m3 would be very minor.Just the export list would vary.And new *.i3 files introduced. - Jay From: hoskingTo: jayDate: Wed, 14 Jan 2009 21:31:22 +1100CC: m3deveSubject: Re: [M3devel] how to switch between user and kernel threads..I don't want dynamic switching. A link-time switch is just fine. Also, please don't go messing about with this right now -- I have changes pending for the threads system that will be harder to integrate if you change with it further. On 14 Jan 2009, at 20:14, Jay wrote: Are people really against using function pointers for this?Either changing the interface to have function pointer variables (I'm not sure Modula-3 allows this, but in C you can fairly transparently replace functions with function pointers; client code just keeps working; it breaks down in C++ with overloading), or having a set of functions that just call/jump through function pointers? There would be no if, no conditional branches. Dynamic linking on Windows always goes through function pointers already. So while yes it adds another instruction, it is already never getting inlined.Don't other platforms do that too?Or they patch every call site? I'm not sure otherwise of a simple method.Easiest might be to have a parallel directory structure to m3core, with just m3core files.That would wastefully rebuild all of m3core a second time, for just a small amount of variation. I think function pointers are the way to go here. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jan 15 01:31:17 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 15 Jan 2009 11:31:17 +1100 Subject: [M3devel] how to switch between user and kernel threads.. In-Reply-To: References: Message-ID: <56CF4A94-6620-4A69-B4DC-D72268811AEA@cs.purdue.edu> No function pointers please. Let the installer decide whether to use native or user threads. On 15 Jan 2009, at 08:30, Jay wrote: > I'll wait. > So, build two different m3core.lib/a/so/dylib? > m3core and m3coreuserthreads > > Compile both thread directories, if the platform supports it, and > call quake make_lib twice with slightly different parameters? > An m3core specific hack in the config file or cm3? > Easy enough in the config file. > Very m3core specific. > I suppose you could argue that quake isn't a generic build system, > but it is Modula-3's build system, and that m3core is really special. > > The result btw, would likely be no change at all to any *.i3 or *.m3 > file. > > I still think function pointers are the way to go. > Even with function pointers, the changes to *.i3 and *.m3 would be > very minor. > Just the export list would vary. > And new *.i3 files introduced. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Wed, 14 Jan 2009 21:31:22 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] how to switch between user and kernel threads.. > > I don't want dynamic switching. A link-time switch is just fine. > > Also, please don't go messing about with this right now -- I have > changes pending for the threads system that will be harder to > integrate if you change with it further. > > On 14 Jan 2009, at 20:14, Jay wrote: > > Are people really against using function pointers for this? > Either changing the interface to have function pointer variables > (I'm not sure Modula-3 allows this, but in C you can fairly > transparently replace functions with function pointers; client code > just keeps working; it breaks down in C++ with overloading), or > having a set of functions that just call/jump through function > pointers? There would be no if, no conditional branches. > > Dynamic linking on Windows always goes through function pointers > already. > So while yes it adds another instruction, it is already never > getting inlined. > Don't other platforms do that too? > Or they patch every call site? > > I'm not sure otherwise of a simple method. > Easiest might be to have a parallel directory structure to m3core, > with just m3core files. > That would wastefully rebuild all of m3core a second time, for just > a small amount of variation. > > I think function pointers are the way to go here. > > - Jay > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 15 04:03:23 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 15 Jan 2009 03:03:23 +0000 Subject: [M3devel] how to switch between user and kernel threads.. In-Reply-To: <56CF4A94-6620-4A69-B4DC-D72268811AEA@cs.purdue.edu> References: <56CF4A94-6620-4A69-B4DC-D72268811AEA@cs.purdue.edu> Message-ID: The installer? I thought the granularity was at the time of linking an executable. I personally thought a command line parameter would be reasonable. Why not function pointers? It is a simple straightforward method to implement. It should add one instruction per call. It does reduce inlinability but I'm sure we aren't getting any such such inlinability anyway. Dynamic linking already kills inlinability, as does separate compilation of modules in most systems. I'm not sure how the types work out in such a scheme, but probably assuming Thread.T is already a reference type, it can become ADDRESS and then loopholed to ThreadPosix.T or ThreadPThread.T. Function pointers are also the easiest method to build. I'm not sure what the others are. I can try making m3-libs/m3coreuserthreads that contains only m3makefiles. Probably it can say: LibraryName = "m3coreuserthreads" include_dir("../m3core/m3makefile") and m3core/m3makefile can say if not defined("LibraryName") LibraryName = "m3core" end Library(LibraryName) If that works, not bad. And then cm3 or the config file can translate m3core to m3coreuserthreads at some point. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Thu, 15 Jan 2009 11:31:17 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] how to switch between user and kernel threads.. No function pointers please. Let the installer decide whether to use native or user threads. On 15 Jan 2009, at 08:30, Jay wrote: I'll wait.So, build two different m3core.lib/a/so/dylib?m3core and m3coreuserthreads Compile both thread directories, if the platform supports it, andcall quake make_lib twice with slightly different parameters?An m3core specific hack in the config file or cm3?Easy enough in the config file.Very m3core specific.I suppose you could argue that quake isn't a generic build system,but it is Modula-3's build system, and that m3core is really special. The result btw, would likely be no change at all to any *.i3 or *.m3 file. I still think function pointers are the way to go.Even with function pointers, the changes to *.i3 and *.m3 would be very minor.Just the export list would vary.And new *.i3 files introduced. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Wed, 14 Jan 2009 21:31:22 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] how to switch between user and kernel threads..I don't want dynamic switching. A link-time switch is just fine. Also, please don't go messing about with this right now -- I have changes pending for the threads system that will be harder to integrate if you change with it further. On 14 Jan 2009, at 20:14, Jay wrote: Are people really against using function pointers for this?Either changing the interface to have function pointer variables (I'm not sure Modula-3 allows this, but in C you can fairly transparently replace functions with function pointers; client code just keeps working; it breaks down in C++ with overloading), or having a set of functions that just call/jump through function pointers? There would be no if, no conditional branches. Dynamic linking on Windows always goes through function pointers already. So while yes it adds another instruction, it is already never getting inlined.Don't other platforms do that too?Or they patch every call site? I'm not sure otherwise of a simple method.Easiest might be to have a parallel directory structure to m3core, with just m3core files.That would wastefully rebuild all of m3core a second time, for just a small amount of variation. I think function pointers are the way to go here. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jan 15 04:18:16 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 15 Jan 2009 14:18:16 +1100 Subject: [M3devel] how to switch between user and kernel threads.. In-Reply-To: References: <56CF4A94-6620-4A69-B4DC-D72268811AEA@cs.purdue.edu> Message-ID: We do get inlining within modules by virtue of the gcc-backend at -O3. On 15 Jan 2009, at 14:03, Jay wrote: > The installer? > I thought the granularity was at the time of linking an executable. > I personally thought a command line parameter would be reasonable. > > > Why not function pointers? > It is a simple straightforward method to implement. > It should add one instruction per call. > It does reduce inlinability but I'm sure we aren't getting any such > such inlinability anyway. > Dynamic linking already kills inlinability, as does separate > compilation of modules in most systems. > > > I'm not sure how the types work out in such a scheme, but probably > assuming Thread.T is already a reference type, it can become ADDRESS > and then loopholed to ThreadPosix.T or ThreadPThread.T. > > > Function pointers are also the easiest method to build. I'm not sure > what the others are. > I can try making m3-libs/m3coreuserthreads that contains only > m3makefiles. > Probably it can say: > LibraryName = "m3coreuserthreads" > include_dir("../m3core/m3makefile") > > > and m3core/m3makefile can say > if not defined("LibraryName") > LibraryName = "m3core" > end > Library(LibraryName) > > > If that works, not bad. > > > And then cm3 or the config file can translate m3core to > m3coreuserthreads at some point. > > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Thu, 15 Jan 2009 11:31:17 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] how to switch between user and kernel threads.. > > > No function pointers please. Let the installer decide whether to > use native or user threads. > > On 15 Jan 2009, at 08:30, Jay wrote: > > I'll wait. > So, build two different m3core.lib/a/so/dylib? > m3core and m3coreuserthreads > > Compile both thread directories, if the platform supports it, and > call quake make_lib twice with slightly different parameters? > An m3core specific hack in the config file or cm3? > Easy enough in the config file. > Very m3core specific. > I suppose you could argue that quake isn't a generic build system, > but it is Modula-3's build system, and that m3core is really special. > > The result btw, would likely be no change at all to any *.i3 or *.m3 > file. > > I still think function pointers are the way to go. > Even with function pointers, the changes to *.i3 and *.m3 would be > very minor. > Just the export list would vary. > And new *.i3 files introduced. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Wed, 14 Jan 2009 21:31:22 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] how to switch between user and kernel threads.. > > I don't want dynamic switching. A link-time switch is just fine. > > Also, please don't go messing about with this right now -- I have > changes pending for the threads system that will be harder to > integrate if you change with it further. > > On 14 Jan 2009, at 20:14, Jay wrote: > > Are people really against using function pointers for this? > Either changing the interface to have function pointer variables > (I'm not sure Modula-3 allows this, but in C you can fairly > transparently replace functions with function pointers; client code > just keeps working; it breaks down in C++ with overloading), or > having a set of functions that just call/jump through function > pointers? There would be no if, no conditional branches. > > Dynamic linking on Windows always goes through function pointers > already. > So while yes it adds another instruction, it is already never > getting inlined. > Don't other platforms do that too? > Or they patch every call site? > > I'm not sure otherwise of a simple method. > Easiest might be to have a parallel directory structure to m3core, > with just m3core files. > That would wastefully rebuild all of m3core a second time, for just > a small amount of variation. > > I think function pointers are the way to go here. > > - Jay > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 15 05:15:43 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 15 Jan 2009 04:15:43 +0000 Subject: [M3devel] how to switch between user and kernel threads.. In-Reply-To: References: <56CF4A94-6620-4A69-B4DC-D72268811AEA@cs.purdue.edu> Message-ID: That would't affected here. All the calls within ThreadPThread to within ThreadPThread would remain direct and inlinable. They would be to the "ThreadPThread" interface, and not the "Thread" interface, would be my intent. How about across modules? I expect any call from outside ThreadPThread to within ThreadPThread to never be inlined, at least not when dynamic linking and with static linking (or within the package/library) not unless there is "whole program optimization" aka "link time code generation" with static linking, which does exist out there. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Thu, 15 Jan 2009 14:18:16 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] how to switch between user and kernel threads..We do get inlining within modules by virtue of the gcc-backend at -O3. On 15 Jan 2009, at 14:03, Jay wrote: The installer?I thought the granularity was at the time of linking an executable.I personally thought a command line parameter would be reasonable. Why not function pointers?It is a simple straightforward method to implement.It should add one instruction per call.It does reduce inlinability but I'm sure we aren't getting any such such inlinability anyway.Dynamic linking already kills inlinability, as does separate compilation of modules in most systems. I'm not sure how the types work out in such a scheme, but probably assuming Thread.T is already a reference type, it can become ADDRESS and then loopholed to ThreadPosix.T or ThreadPThread.T. Function pointers are also the easiest method to build. I'm not sure what the others are.I can try making m3-libs/m3coreuserthreads that contains only m3makefiles.Probably it can say:LibraryName = "m3coreuserthreads"include_dir("../m3core/m3makefile") and m3core/m3makefile can sayif not defined("LibraryName") LibraryName = "m3core"endLibrary(LibraryName) If that works, not bad. And then cm3 or the config file can translate m3core to m3coreuserthreads at some point. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Thu, 15 Jan 2009 11:31:17 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] how to switch between user and kernel threads.. No function pointers please. Let the installer decide whether to use native or user threads. On 15 Jan 2009, at 08:30, Jay wrote: I'll wait.So, build two different m3core.lib/a/so/dylib?m3core and m3coreuserthreads Compile both thread directories, if the platform supports it, andcall quake make_lib twice with slightly different parameters?An m3core specific hack in the config file or cm3?Easy enough in the config file.Very m3core specific.I suppose you could argue that quake isn't a generic build system,but it is Modula-3's build system, and that m3core is really special. The result btw, would likely be no change at all to any *.i3 or *.m3 file. I still think function pointers are the way to go.Even with function pointers, the changes to *.i3 and *.m3 would be very minor.Just the export list would vary.And new *.i3 files introduced. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Wed, 14 Jan 2009 21:31:22 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] how to switch between user and kernel threads..I don't want dynamic switching. A link-time switch is just fine. Also, please don't go messing about with this right now -- I have changes pending for the threads system that will be harder to integrate if you change with it further. On 14 Jan 2009, at 20:14, Jay wrote: Are people really against using function pointers for this?Either changing the interface to have function pointer variables (I'm not sure Modula-3 allows this, but in C you can fairly transparently replace functions with function pointers; client code just keeps working; it breaks down in C++ with overloading), or having a set of functions that just call/jump through function pointers? There would be no if, no conditional branches. Dynamic linking on Windows always goes through function pointers already. So while yes it adds another instruction, it is already never getting inlined.Don't other platforms do that too?Or they patch every call site? I'm not sure otherwise of a simple method.Easiest might be to have a parallel directory structure to m3core, with just m3core files.That would wastefully rebuild all of m3core a second time, for just a small amount of variation. I think function pointers are the way to go here. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinbishop at bellsouth.net Fri Jan 16 03:25:04 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Thu, 15 Jan 2009 20:25:04 -0600 Subject: [M3devel] Percent to REAL? Message-ID: <496FF000.1030506@bellsouth.net> I'm feeling silly, but I need to convert a percentage (stored as an INTEGER) into a REAL, so I tried FLOAT(num) / 100.0 but that doesn't work. I tried using FLOAT(num DIV 100) but that doesn't work either. I also tried FLOAT(num MOD 100) just to try everything, and that didn't work either. How can I convert a percentage into a REAL? For example, 70% -> 0.70 From rcoleburn at scires.com Fri Jan 16 03:47:54 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 15 Jan 2009 21:47:54 -0500 Subject: [M3devel] Percent to REAL? In-Reply-To: <496FF000.1030506@bellsouth.net> References: <496FF000.1030506@bellsouth.net> Message-ID: <496FAE9F.1E75.00D7.1@scires.com> Martin: The following works for me: VAR i: INTEGER; r: REAL; BEGIN i := 70; r := FLOAT(i) / 100.0; END; Regards, Randy >>> Martin Bishop 1/15/2009 9:25 PM >>> I'm feeling silly, but I need to convert a percentage (stored as an INTEGER) into a REAL, so I tried FLOAT(num) / 100.0 but that doesn't work. I tried using FLOAT(num DIV 100) but that doesn't work either. I also tried FLOAT(num MOD 100) just to try everything, and that didn't work either. How can I convert a percentage into a REAL? For example, 70% -> 0.70 -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinbishop at bellsouth.net Fri Jan 16 03:37:28 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Thu, 15 Jan 2009 20:37:28 -0600 Subject: [M3devel] Percent to REAL? In-Reply-To: <496FF000.1030506@bellsouth.net> References: <496FF000.1030506@bellsouth.net> Message-ID: <496FF2E8.5050801@bellsouth.net> Martin Bishop wrote: > I'm feeling silly, but I need to convert a percentage (stored as an > INTEGER) into a REAL, so I tried FLOAT(num) / 100.0 but that doesn't > work. I tried using FLOAT(num DIV 100) but that doesn't work either. I > also tried FLOAT(num MOD 100) just to try everything, and that didn't > work either. > > How can I convert a percentage into a REAL? For example, 70% -> 0.70 > Disregard that, I knew I was feeling silly, FLOAT(num) / 100.0 DOES work. From jay.krell at cornell.edu Fri Jan 16 10:28:46 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 16 Jan 2009 09:28:46 +0000 Subject: [M3devel] how to switch between user and kernel threads.. In-Reply-To: References: <56CF4A94-6620-4A69-B4DC-D72268811AEA@cs.purdue.edu> Message-ID: I was able to easily build this alternate library, just by creating one small m3makefile and optionally editing one other very little. I wasn't able to find a way to get it used, other than maybe shipping it on top of the "real" m3core. A compiler hack that knows to replace package "m3core" with "m3coreuserthreads" may be appropriate. I can look into that. But I still don't know why not function pointers. Plenty else to do in the meantime (Cygwin/pthreads, portability, a bunch of ports..). - Jay From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] how to switch between user and kernel threads..Date: Thu, 15 Jan 2009 04:15:43 +0000 That would't affected here. All the calls within ThreadPThread to within ThreadPThread would remain direct and inlinable. They would be to the "ThreadPThread" interface, and not the "Thread" interface, would be my intent. How about across modules? I expect any call from outside ThreadPThread to within ThreadPThread to never be inlined, at least not when dynamic linking and with static linking (or within the package/library) not unless there is "whole program optimization" aka "link time code generation" with static linking, which does exist out there. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Thu, 15 Jan 2009 14:18:16 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] how to switch between user and kernel threads..We do get inlining within modules by virtue of the gcc-backend at -O3. On 15 Jan 2009, at 14:03, Jay wrote: The installer?I thought the granularity was at the time of linking an executable.I personally thought a command line parameter would be reasonable. Why not function pointers?It is a simple straightforward method to implement.It should add one instruction per call.It does reduce inlinability but I'm sure we aren't getting any such such inlinability anyway.Dynamic linking already kills inlinability, as does separate compilation of modules in most systems. I'm not sure how the types work out in such a scheme, but probably assuming Thread.T is already a reference type, it can become ADDRESS and then loopholed to ThreadPosix.T or ThreadPThread.T. Function pointers are also the easiest method to build. I'm not sure what the others are.I can try making m3-libs/m3coreuserthreads that contains only m3makefiles.Probably it can say:LibraryName = "m3coreuserthreads"include_dir("../m3core/m3makefile") and m3core/m3makefile can sayif not defined("LibraryName") LibraryName = "m3core"endLibrary(LibraryName) If that works, not bad. And then cm3 or the config file can translate m3core to m3coreuserthreads at some point. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Thu, 15 Jan 2009 11:31:17 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] how to switch between user and kernel threads.. No function pointers please. Let the installer decide whether to use native or user threads. On 15 Jan 2009, at 08:30, Jay wrote: I'll wait.So, build two different m3core.lib/a/so/dylib?m3core and m3coreuserthreads Compile both thread directories, if the platform supports it, andcall quake make_lib twice with slightly different parameters?An m3core specific hack in the config file or cm3?Easy enough in the config file.Very m3core specific.I suppose you could argue that quake isn't a generic build system,but it is Modula-3's build system, and that m3core is really special. The result btw, would likely be no change at all to any *.i3 or *.m3 file. I still think function pointers are the way to go.Even with function pointers, the changes to *.i3 and *.m3 would be very minor.Just the export list would vary.And new *.i3 files introduced. - Jay From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Wed, 14 Jan 2009 21:31:22 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] how to switch between user and kernel threads..I don't want dynamic switching. A link-time switch is just fine. Also, please don't go messing about with this right now -- I have changes pending for the threads system that will be harder to integrate if you change with it further. On 14 Jan 2009, at 20:14, Jay wrote: Are people really against using function pointers for this?Either changing the interface to have function pointer variables (I'm not sure Modula-3 allows this, but in C you can fairly transparently replace functions with function pointers; client code just keeps working; it breaks down in C++ with overloading), or having a set of functions that just call/jump through function pointers? There would be no if, no conditional branches. Dynamic linking on Windows always goes through function pointers already. So while yes it adds another instruction, it is already never getting inlined.Don't other platforms do that too?Or they patch every call site? I'm not sure otherwise of a simple method.Easiest might be to have a parallel directory structure to m3core, with just m3core files.That would wastefully rebuild all of m3core a second time, for just a small amount of variation. I think function pointers are the way to go here. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jan 16 14:05:17 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 16 Jan 2009 13:05:17 +0000 Subject: [M3devel] "new old" ports, or no ports at all? Message-ID: Would people mind "new" ports like: HPPA32_HPUX (HPPA_HPUX? There is "HPPA")I386_FREEBSD (There is FreeBSD4.)I386_NETBSD (There is NetBSD2_i386.)MIPS32_IRIX (MIPS_IRIX? There is IRIX5.)ALPHA_FREEBSD (There FBSD_ALPHA.) and then for that matter:SPARC32_SOLARIS, I386_LINUX Or some mix?This is not hypothetical. I do now have HPPA, Alpha, SGI hardware. :) I can either do the little bit of correct testable valid small etc. work of using my "more portable" approach to these platforms, which gets things up and running easily and fast and perfectly acceptably, or I could "proofread" all the gunk, I mean cloned headers, fix them for current system, worry if they break old system, or delete them, possibly doing some hypothetical damage to the old ports. It seems easier and a better result to "start over" and leave the old stuff alone, maybe delete it, depending on what people think of history preservation and history vs. deletes (deleted stuff isn't very visible). Or maybe hardly any of this matters. Nobody uses these platforms or anything like them? (I recall Randy saying he is still using 4.1 on HP-UX though. I'm on a fun little long running errand here of getting not ancient but not current systems.. :) ) The "4", "2", "5" in FreeBSD4, NetBSD2_i386, IRIX5 make them seen somewhat "wrong". The "4" in FreeBSD4 (err, in i686-freebsd4) does have a surprising semantic, in the backend..but maybe not. C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(53): builtin_define_with_int_value ("__FreeBSD__", FBSD_MAJOR); \ C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(122):#if FBSD_MAJOR < 5 C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(141):#if FBSD_MAJOR < 6 though I think if you look closely, these don't matter to us.They affect the gcc driver and the C/C++ front end, but maybe not the m3cg backend. Even the "LIBC6" in "LINUXLIBC6" seems dubious, because, for example, I amtempted to make "ARM_LINUX_UCLIBC", which suggests either thatthere might be an "I386_LINUX_UCLIBC" or "generic" "I386_LINUX" thatis portable across libc6/uclibc/dietlibc/newlib either by seeingwhat they have in common, or skipping them and using the kernel interfacesmore directly. There is another angle here.To what extent is the compiler platform specific? (I mostly know the answer to this. It is a leading question.)Could ports go away?Almost? Historically there were a bunch of platform-specific .i3 files.That is dwindling much in some platforms and could dwindle much overall.A little more C code in the system and the Modula-3 .i3 files are all "portable". It ends up being, roughly, that there is: endian, and even this is often not an issue; I saw like one reference in the compiler to it, and there is a little bit in m3core/libm3 The byte swap functions and maybe the Float stuff (there is endian specific and generic stuff, not all is used). It would affect e.g. the layout of the Uexec types, but they are gone. Such endian-specificity could occur anywhere but maybe "cm3 -generic" errors for it? word size -- 32bit or 64bit. There is no escaping this, as long as there are any 32bit platforms. So ok, two ports, 32bit and 64bit. That's a small matrix. IEEE or not -- everything is IEEE now. I don't plan on getting a VAX. :) (The compiler seems suspicious here wrt cross building.) The name of setjmp. However this could be made the same everywhere -- m3_setjmp or M3Try or M3SaveState, and use an #ifdef .c file to decide. The size of the jmpbuf. Ah, there's the rub. A "generic" platform could blow up the size of the jmpbuf to something that works on all known platforms. Very very wasteful. Some platforms have tiny, some have huge. I'm not sure where stack layout is done. If the front end does it or not. You could imagine something like M3Try allocating the same..but this seems bad. If the front end defers enough work to the backend, you could introduce an abstracted notion of the jmpbuf and leave it to m3cg to fill in? Leave it to #ifdef on the target? m3cg, in its current form as gcc based is always going to have be configured to be target specific. Or all platforms could have stack walkers and this platform-specificity would go away. But that is a very long ways off, if ever. My point is, you know, can we in fact eliminate the notion of porting? At least of cm3 knowing anything about the target, and only m3cg? Because the system is nearly portable enough? All that is left is configuring gcc? It seems very close to possible. Like, "have gcc, will travel"?And nothing else changes?No value then in doing any porting work up front? You know..think of the author of hello world..some highly portable program. Or more realistic example such as bash, awk, make, ld and gcc on a particular host (not target), etc.They don't go around much and port to this or that or the other system. They do a mix of "just try to be portable" and "leave autoconf to figure out". Modula-3 is almost in the same boat? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Jan 16 17:04:53 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 16 Jan 2009 11:04:53 -0500 Subject: [M3devel] "new old" ports, or no ports at all? In-Reply-To: References: Message-ID: <49706962.1E75.00D7.1@scires.com> Jay: I do have some HP-UX machines that I could use to test whatever you come up with for HPPA. You are correct that right now I run cm3 v4.1 on these. I have not tried to move beyond 4.1 on them yet. Regards, Randy >>> Jay 1/16/2009 8:05 AM >>> Would people mind "new" ports like: HPPA32_HPUX (HPPA_HPUX? There is "HPPA") I386_FREEBSD (There is FreeBSD4.) I386_NETBSD (There is NetBSD2_i386.) MIPS32_IRIX (MIPS_IRIX? There is IRIX5.) ALPHA_FREEBSD (There FBSD_ALPHA.) and then for that matter: SPARC32_SOLARIS, I386_LINUX Or some mix? This is not hypothetical. I do now have HPPA, Alpha, SGI hardware. :) I can either do the little bit of correct testable valid small etc. work of using my "more portable" approach to these platforms, which gets things up and running easily and fast and perfectly acceptably, or I could "proofread" all the gunk, I mean cloned headers, fix them for current system, worry if they break old system, or delete them, possibly doing some hypothetical damage to the old ports. It seems easier and a better result to "start over" and leave the old stuff alone, maybe delete it, depending on what people think of history preservation and history vs. deletes (deleted stuff isn't very visible). Or maybe hardly any of this matters. Nobody uses these platforms or anything like them? (I recall Randy saying he is still using 4.1 on HP-UX though. I'm on a fun little long running errand here of getting not ancient but not current systems.. :) ) The "4", "2", "5" in FreeBSD4, NetBSD2_i386, IRIX5 make them seen somewhat "wrong". The "4" in FreeBSD4 (err, in i686-freebsd4) does have a surprising semantic, in the backend..but maybe not. C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(53): builtin_define_with_int_value ("__FreeBSD__", FBSD_MAJOR); \ C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(122):#if FBSD_MAJOR < 5 C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(141):#if FBSD_MAJOR < 6 though I think if you look closely, these don't matter to us. They affect the gcc driver and the C/C++ front end, but maybe not the m3cg backend. Even the "LIBC6" in "LINUXLIBC6" seems dubious, because, for example, I am tempted to make "ARM_LINUX_UCLIBC", which suggests either that there might be an "I386_LINUX_UCLIBC" or "generic" "I386_LINUX" that is portable across libc6/uclibc/dietlibc/newlib either by seeing what they have in common, or skipping them and using the kernel interfaces more directly. There is another angle here. To what extent is the compiler platform specific? (I mostly know the answer to this. It is a leading question.) Could ports go away? Almost? Historically there were a bunch of platform-specific .i3 files. That is dwindling much in some platforms and could dwindle much overall. A little more C code in the system and the Modula-3 .i3 files are all "portable". It ends up being, roughly, that there is: endian, and even this is often not an issue; I saw like one reference in the compiler to it, and there is a little bit in m3core/libm3 The byte swap functions and maybe the Float stuff (there is endian specific and generic stuff, not all is used). It would affect e.g. the layout of the Uexec types, but they are gone. Such endian-specificity could occur anywhere but maybe "cm3 -generic" errors for it? word size -- 32bit or 64bit. There is no escaping this, as long as there are any 32bit platforms. So ok, two ports, 32bit and 64bit. That's a small matrix. IEEE or not -- everything is IEEE now. I don't plan on getting a VAX. :) (The compiler seems suspicious here wrt cross building.) The name of setjmp. However this could be made the same everywhere -- m3_setjmp or M3Try or M3SaveState, and use an #ifdef .c file to decide. The size of the jmpbuf. Ah, there's the rub. A "generic" platform could blow up the size of the jmpbuf to something that works on all known platforms. Very very wasteful. Some platforms have tiny, some have huge. I'm not sure where stack layout is done. If the front end does it or not. You could imagine something like M3Try allocating the same..but this seems bad. If the front end defers enough work to the backend, you could introduce an abstracted notion of the jmpbuf and leave it to m3cg to fill in? Leave it to #ifdef on the target? m3cg, in its current form as gcc based is always going to have be configured to be target specific. Or all platforms could have stack walkers and this platform-specificity would go away. But that is a very long ways off, if ever. My point is, you know, can we in fact eliminate the notion of porting? At least of cm3 knowing anything about the target, and only m3cg? Because the system is nearly portable enough? All that is left is configuring gcc? It seems very close to possible. Like, "have gcc, will travel"? And nothing else changes? No value then in doing any porting work up front? You know..think of the author of hello world..some highly portable program. Or more realistic example such as bash, awk, make, ld and gcc on a particular host (not target), etc. They don't go around much and port to this or that or the other system. They do a mix of "just try to be portable" and "leave autoconf to figure out". Modula-3 is almost in the same boat? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Jan 17 05:06:18 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 17 Jan 2009 15:06:18 +1100 Subject: [M3devel] how to switch between user and kernel threads.. In-Reply-To: References: <56CF4A94-6620-4A69-B4DC-D72268811AEA@cs.purdue.edu> Message-ID: Please leave it the way it is as an install-time option. -DNOPTHREAD enables user threads. On 16 Jan 2009, at 20:28, Jay wrote: > I was able to easily build this alternate library, just by creating > one small m3makefile and optionally editing one other very little. > I wasn't able to find a way to get it used, other than maybe > shipping it on top of the "real" m3core. > A compiler hack that knows to replace package "m3core" with > "m3coreuserthreads" may be appropriate. > I can look into that. > But I still don't know why not function pointers. > Plenty else to do in the meantime (Cygwin/pthreads, portability, a > bunch of ports..). > > - Jay > > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] how to switch between user and kernel threads.. > Date: Thu, 15 Jan 2009 04:15:43 +0000 > > That would't affected here. > All the calls within ThreadPThread to within ThreadPThread would > remain direct and inlinable. > They would be to the "ThreadPThread" interface, and not the > "Thread" interface, would be my intent. > > How about across modules? > I expect any call from outside ThreadPThread to within > ThreadPThread to never be inlined, at least not when dynamic linking > and with static linking (or within the package/library) not unless > there is "whole program optimization" aka "link time code > generation" with static linking, which does exist out there. > > - Jay > > > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Thu, 15 Jan 2009 14:18:16 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] how to switch between user and kernel threads.. > > We do get inlining within modules by virtue of the gcc-backend at -O3. > > > On 15 Jan 2009, at 14:03, Jay wrote: > > The installer? > I thought the granularity was at the time of linking an executable. > I personally thought a command line parameter would be reasonable. > > > Why not function pointers? > It is a simple straightforward method to implement. > It should add one instruction per call. > It does reduce inlinability but I'm sure we aren't getting any such > such inlinability anyway. > Dynamic linking already kills inlinability, as does separate > compilation of modules in most systems. > > > I'm not sure how the types work out in such a scheme, but probably > assuming Thread.T is already a reference type, it can become ADDRESS > and then loopholed to ThreadPosix.T or ThreadPThread.T. > > > Function pointers are also the easiest method to build. I'm not sure > what the others are. > I can try making m3-libs/m3coreuserthreads that contains only > m3makefiles. > Probably it can say: > LibraryName = "m3coreuserthreads" > include_dir("../m3core/m3makefile") > > > and m3core/m3makefile can say > if not defined("LibraryName") > LibraryName = "m3core" > end > Library(LibraryName) > > > If that works, not bad. > > > And then cm3 or the config file can translate m3core to > m3coreuserthreads at some point. > > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Thu, 15 Jan 2009 11:31:17 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] how to switch between user and kernel threads.. > > > No function pointers please. Let the installer decide whether to > use native or user threads. > > On 15 Jan 2009, at 08:30, Jay wrote: > > I'll wait. > So, build two different m3core.lib/a/so/dylib? > m3core and m3coreuserthreads > > Compile both thread directories, if the platform supports it, and > call quake make_lib twice with slightly different parameters? > An m3core specific hack in the config file or cm3? > Easy enough in the config file. > Very m3core specific. > I suppose you could argue that quake isn't a generic build system, > but it is Modula-3's build system, and that m3core is really special. > > The result btw, would likely be no change at all to any *.i3 or *.m3 > file. > > I still think function pointers are the way to go. > Even with function pointers, the changes to *.i3 and *.m3 would be > very minor. > Just the export list would vary. > And new *.i3 files introduced. > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Wed, 14 Jan 2009 21:31:22 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] how to switch between user and kernel threads.. > > I don't want dynamic switching. A link-time switch is just fine. > > Also, please don't go messing about with this right now -- I have > changes pending for the threads system that will be harder to > integrate if you change with it further. > > On 14 Jan 2009, at 20:14, Jay wrote: > > Are people really against using function pointers for this? > Either changing the interface to have function pointer variables > (I'm not sure Modula-3 allows this, but in C you can fairly > transparently replace functions with function pointers; client code > just keeps working; it breaks down in C++ with overloading), or > having a set of functions that just call/jump through function > pointers? There would be no if, no conditional branches. > > Dynamic linking on Windows always goes through function pointers > already. > So while yes it adds another instruction, it is already never > getting inlined. > Don't other platforms do that too? > Or they patch every call site? > > I'm not sure otherwise of a simple method. > Easiest might be to have a parallel directory structure to m3core, > with just m3core files. > That would wastefully rebuild all of m3core a second time, for just > a small amount of variation. > > I think function pointers are the way to go here. > > - Jay > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinbishop at bellsouth.net Sat Jan 17 06:19:51 2009 From: martinbishop at bellsouth.net (Martin Bishop) Date: Fri, 16 Jan 2009 23:19:51 -0600 Subject: [M3devel] What is M3SU? Message-ID: <49716A77.60405@bellsouth.net> I was reading the FAQ for Modula-3, and noticed they mentioned a program called "m3su". The link they give to an ftp server is no longer available, but with a little poking around I found where it is located at, however they do not have 'm3su' on it anymore. What is (or was?) m3su? From hosking at cs.purdue.edu Sat Jan 17 12:03:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 17 Jan 2009 22:03:19 +1100 Subject: [M3devel] "new old" ports, or no ports at all? In-Reply-To: References: Message-ID: <715A8E4A-CDC4-453B-96F8-67E377E8EDF2@cs.purdue.edu> Historically, there have been non-gcc-based backends. We would not want to preclude those. On 17 Jan 2009, at 00:05, Jay wrote: > Would people mind "new" ports like: > > > HPPA32_HPUX (HPPA_HPUX? There is "HPPA") > I386_FREEBSD (There is FreeBSD4.) > I386_NETBSD (There is NetBSD2_i386.) > MIPS32_IRIX (MIPS_IRIX? There is IRIX5.) > ALPHA_FREEBSD (There FBSD_ALPHA.) > and then for that matter: > SPARC32_SOLARIS, I386_LINUX > > > Or some mix? > This is not hypothetical. I do now have HPPA, Alpha, SGI hardware. :) > > > I can either do the little bit of correct testable valid small etc. > work > of using my "more portable" approach to these platforms, which > gets things up and running easily and fast and perfectly acceptably, > or I could "proofread" all the gunk, I mean cloned headers, fix them > for current system, worry if they break old system, or delete them, > possibly doing some hypothetical damage to the old ports. > > > It seems easier and a better result to "start over" and leave the > old stuff alone, > maybe delete it, depending on what people think of history > preservation and > history vs. deletes (deleted stuff isn't very visible). > > > Or maybe hardly any of this matters. Nobody uses these platforms or > anything like them? > (I recall Randy saying he is still using 4.1 on HP-UX though. I'm on > a fun little > long running errand here of getting not ancient but not current > systems.. :) ) > > > The "4", "2", "5" in FreeBSD4, NetBSD2_i386, IRIX5 make them seen > somewhat "wrong". > > > The "4" in FreeBSD4 (err, in i686-freebsd4) does have a surprising > semantic, in the backend..but maybe not. > C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(53): > builtin_define_with_int_value ("__FreeBSD__", FBSD_MAJOR); \ > C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(122):#if > FBSD_MAJOR < 5 > C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(141):#if > FBSD_MAJOR < 6 > > > though I think if you look closely, these don't matter to us. > They affect the gcc driver and the C/C++ front end, but maybe not > the m3cg backend. > > > Even the "LIBC6" in "LINUXLIBC6" seems dubious, because, for > example, I am > tempted to make "ARM_LINUX_UCLIBC", which suggests either that > there might be an "I386_LINUX_UCLIBC" or "generic" "I386_LINUX" that > is portable across libc6/uclibc/dietlibc/newlib either by seeing > what they have in common, or skipping them and using the kernel > interfaces > more directly. > > > There is another angle here. > To what extent is the compiler platform specific? > (I mostly know the answer to this. It is a leading question.) > Could ports go away? > Almost? > > > Historically there were a bunch of platform-specific .i3 files. > That is dwindling much in some platforms and could dwindle much > overall. > A little more C code in the system and the Modula-3 .i3 files are > all "portable". > > > It ends up being, roughly, that there is: > > > endian, and even this is often not an issue; I saw like > one reference in the compiler to it, and there is a little bit in > m3core/libm3 > The byte swap functions and maybe the Float stuff (there is > endian specific > and generic stuff, not all is used). > It would affect e.g. the layout of the Uexec types, but they are > gone. > Such endian-specificity could occur anywhere but maybe "cm3 - > generic" errors for it? > > > word size -- 32bit or 64bit. There is no escaping this, as long as > there are any 32bit platforms. > So ok, two ports, 32bit and 64bit. That's a small matrix. > > > IEEE or not -- everything is IEEE now. I don't plan on getting a > VAX. :) > (The compiler seems suspicious here wrt cross building.) > > > The name of setjmp. > However this could be made the same everywhere -- m3_setjmp or > M3Try or M3SaveState, > and use an #ifdef .c file to decide. > > > The size of the jmpbuf. Ah, there's the rub. > A "generic" platform could blow up the size of the jmpbuf to > something that works > on all known platforms. Very very wasteful. Some platforms have > tiny, some have huge. > > > I'm not sure where stack layout is done. If the front end does it > or not. > You could imagine something like M3Try allocating the same..but > this seems bad. > If the front end defers enough work to the backend, you could > introduce an abstracted > notion of the jmpbuf and leave it to m3cg to fill in? Leave it to > #ifdef on the target? > m3cg, in its current form as gcc based is always going to have be > configured to be > target specific. > > > Or all platforms could have stack walkers and this platform- > specificity would go away. > But that is a very long ways off, if ever. > > > My point is, you know, can we in fact eliminate the notion of > porting? > At least of cm3 knowing anything about the target, and only m3cg? > Because the system is nearly portable enough? All that is left is > configuring gcc? > It seems very close to possible. > > > Like, "have gcc, will travel"? > And nothing else changes? > No value then in doing any porting work up front? > > > You know..think of the author of hello world..some highly portable > program. > Or more realistic example such as bash, awk, make, ld and gcc on a > particular host (not target), etc. > They don't go around much and port to this or that or the other > system. > They do a mix of "just try to be portable" and "leave autoconf to > figure out". > > > Modula-3 is almost in the same boat? > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Jan 17 12:36:39 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 17 Jan 2009 11:36:39 +0000 Subject: [M3devel] "new old" ports, or no ports at all? In-Reply-To: <715A8E4A-CDC4-453B-96F8-67E377E8EDF2@cs.purdue.edu> References: <715A8E4A-CDC4-453B-96F8-67E377E8EDF2@cs.purdue.edu> Message-ID: Ah -- you mean if there more integrated backends written in Modula-3, then it would become "impossible" to push such knowledge of the target as its processor, endianness, etc. out of cm3? Or rather, it would be /possible/, but it would be counterproductive. That makes sense. Good point. But that could be added back. if platform = "nt386" UseIntegratedBackend(); else if ... ... else gcc backend handles it (almost) all ? No need, perhaps, for a big enum and switch. Just about. You know..as it stands..cm3 knows just a little about each target, and it doesn't even use all it knows kinda. Word size it uses in computing layout. Endianness it uses rarely I think. "aligned procedures" it uses in about one place. Some of the data in Target.i3 was unused and I removed it. I guess nevermind. I'm just thinking about, you know, declaring all ports either done, or so trivial that there is little point in doing one until someone needs it, merely tedium. That isn't actually the case yet -- there should be C program(s) to generate the "residue", Usysdep.i3, Csetjmp.i3, etc. The other backends are the NT386 one, and it adapted to Linux/x86, right? And maybe what used to generate C? (Can someone give me details as to why C generation isn't a great idea?) - Jay ________________________________ > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Subject: Re: [M3devel] "new old" ports, or no ports at all? > Date: Sat, 17 Jan 2009 22:03:19 +1100 > > Historically, there have been non-gcc-based backends. We would not want to preclude those. > > On 17 Jan 2009, at 00:05, Jay wrote: > > Would people mind "new" ports like: > > > HPPA32_HPUX (HPPA_HPUX? There is "HPPA") > I386_FREEBSD (There is FreeBSD4.) > I386_NETBSD (There is NetBSD2_i386.) > MIPS32_IRIX (MIPS_IRIX? There is IRIX5.) > ALPHA_FREEBSD (There FBSD_ALPHA.) > and then for that matter: > SPARC32_SOLARIS, I386_LINUX > > > Or some mix? > This is not hypothetical. I do now have HPPA, Alpha, SGI hardware. :) > > > I can either do the little bit of correct testable valid small etc. work > of using my "more portable" approach to these platforms, which > gets things up and running easily and fast and perfectly acceptably, > or I could "proofread" all the gunk, I mean cloned headers, fix them > for current system, worry if they break old system, or delete them, > possibly doing some hypothetical damage to the old ports. > > > It seems easier and a better result to "start over" and leave the old stuff alone, > maybe delete it, depending on what people think of history preservation and > history vs. deletes (deleted stuff isn't very visible). > > > Or maybe hardly any of this matters. Nobody uses these platforms or anything like them? > (I recall Randy saying he is still using 4.1 on HP-UX though. I'm on a fun little > long running errand here of getting not ancient but not current systems.. :) ) > > > The "4", "2", "5" in FreeBSD4, NetBSD2_i386, IRIX5 make them seen somewhat "wrong". > > > The "4" in FreeBSD4 (err, in i686-freebsd4) does have a surprising semantic, in the backend..but maybe not. > C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(53): builtin_define_with_int_value ("__FreeBSD__", FBSD_MAJOR); \ > C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(122):#if FBSD_MAJOR < 5 > C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(141):#if FBSD_MAJOR < 6 > > > though I think if you look closely, these don't matter to us. > They affect the gcc driver and the C/C++ front end, but maybe not the m3cg backend. > > > Even the "LIBC6" in "LINUXLIBC6" seems dubious, because, for example, I am > tempted to make "ARM_LINUX_UCLIBC", which suggests either that > there might be an "I386_LINUX_UCLIBC" or "generic" "I386_LINUX" that > is portable across libc6/uclibc/dietlibc/newlib either by seeing > what they have in common, or skipping them and using the kernel interfaces > more directly. > > > There is another angle here. > To what extent is the compiler platform specific? > (I mostly know the answer to this. It is a leading question.) > Could ports go away? > Almost? > > > Historically there were a bunch of platform-specific .i3 files. > That is dwindling much in some platforms and could dwindle much overall. > A little more C code in the system and the Modula-3 .i3 files are all "portable". > > > It ends up being, roughly, that there is: > > > endian, and even this is often not an issue; I saw like > one reference in the compiler to it, and there is a little bit in m3core/libm3 > The byte swap functions and maybe the Float stuff (there is endian specific > and generic stuff, not all is used). > It would affect e.g. the layout of the Uexec types, but they are gone. > Such endian-specificity could occur anywhere but maybe "cm3 -generic" errors for it? > > > word size -- 32bit or 64bit. There is no escaping this, as long as there are any 32bit platforms. > So ok, two ports, 32bit and 64bit. That's a small matrix. > > > IEEE or not -- everything is IEEE now. I don't plan on getting a VAX. :) > (The compiler seems suspicious here wrt cross building.) > > > The name of setjmp. > However this could be made the same everywhere -- m3_setjmp or M3Try or M3SaveState, > and use an #ifdef .c file to decide. > > > The size of the jmpbuf. Ah, there's the rub. > A "generic" platform could blow up the size of the jmpbuf to something that works > on all known platforms. Very very wasteful. Some platforms have tiny, some have huge. > > > I'm not sure where stack layout is done. If the front end does it or not. > You could imagine something like M3Try allocating the same..but this seems bad. > If the front end defers enough work to the backend, you could introduce an abstracted > notion of the jmpbuf and leave it to m3cg to fill in? Leave it to #ifdef on the target? > m3cg, in its current form as gcc based is always going to have be configured to be > target specific. > > > Or all platforms could have stack walkers and this platform-specificity would go away. > But that is a very long ways off, if ever. > > > My point is, you know, can we in fact eliminate the notion of porting? > At least of cm3 knowing anything about the target, and only m3cg? > Because the system is nearly portable enough? All that is left is configuring gcc? > It seems very close to possible. > > > Like, "have gcc, will travel"? > And nothing else changes? > No value then in doing any porting work up front? > > > You know..think of the author of hello world..some highly portable program. > Or more realistic example such as bash, awk, make, ld and gcc on a particular host (not target), etc. > They don't go around much and port to this or that or the other system. > They do a mix of "just try to be portable" and "leave autoconf to figure out". > > > Modula-3 is almost in the same boat? > > > - Jay > > From hosking at cs.purdue.edu Sat Jan 17 12:45:30 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 17 Jan 2009 22:45:30 +1100 Subject: [M3devel] What is M3SU? In-Reply-To: <49716A77.60405@bellsouth.net> References: <49716A77.60405@bellsouth.net> Message-ID: <1548D817-74A6-4411-8DBB-2CACA3C744CA@cs.purdue.edu> Never heard of it. 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 17 Jan 2009, at 16:19, Martin Bishop wrote: > I was reading the FAQ for Modula-3, and noticed they mentioned a > program > called "m3su". The link they give to an ftp server is no longer > available, but with a little poking around I found where it is located > at, however they do not have 'm3su' on it anymore. > > What is (or was?) m3su? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Jan 17 12:48:33 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 17 Jan 2009 22:48:33 +1100 Subject: [M3devel] "new old" ports, or no ports at all? In-Reply-To: References: <715A8E4A-CDC4-453B-96F8-67E377E8EDF2@cs.purdue.edu> Message-ID: <58149067-89DE-4D73-A4E4-BF48C1A9A776@cs.purdue.edu> There were BURS backends too. And C is not good for source-level debugging. On 17 Jan 2009, at 22:36, Jay wrote: > > Ah -- you mean if there more integrated backends written in > Modula-3, then it would become "impossible" to push such knowledge > of the target as its processor, endianness, etc. out of cm3? > Or rather, it would be /possible/, but it would be counterproductive. > That makes sense. Good point. > But that could be added back. > > > if platform = "nt386" > UseIntegratedBackend(); > else if ... > ... > else > gcc backend handles it (almost) all ? > > > No need, perhaps, for a big enum and switch. > Just about. > > > You know..as it stands..cm3 knows just a little about each target, > and it doesn't even use all it knows kinda. Word size it uses in > computing layout. Endianness it uses rarely I think. "aligned > procedures" it uses in about one place. Some of the data in > Target.i3 was unused and I removed it. I guess nevermind. I'm just > thinking about, you know, declaring all ports either done, or so > trivial that there is little point in doing one until someone needs > it, merely tedium. That isn't actually the case yet -- there should > be C program(s) to generate the "residue", Usysdep.i3, Csetjmp.i3, > etc. > > > The other backends are the NT386 one, and it adapted to Linux/x86, > right? > And maybe what used to generate C? > (Can someone give me details as to why C generation isn't a great > idea?) > > > - Jay > > > > ________________________________ >> CC: m3devel at elegosoft.com >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Subject: Re: [M3devel] "new old" ports, or no ports at all? >> Date: Sat, 17 Jan 2009 22:03:19 +1100 >> >> Historically, there have been non-gcc-based backends. We would not >> want to preclude those. >> >> On 17 Jan 2009, at 00:05, Jay wrote: >> >> Would people mind "new" ports like: >> >> >> HPPA32_HPUX (HPPA_HPUX? There is "HPPA") >> I386_FREEBSD (There is FreeBSD4.) >> I386_NETBSD (There is NetBSD2_i386.) >> MIPS32_IRIX (MIPS_IRIX? There is IRIX5.) >> ALPHA_FREEBSD (There FBSD_ALPHA.) >> and then for that matter: >> SPARC32_SOLARIS, I386_LINUX >> >> >> Or some mix? >> This is not hypothetical. I do now have HPPA, Alpha, SGI hardware. :) >> >> >> I can either do the little bit of correct testable valid small etc. >> work >> of using my "more portable" approach to these platforms, which >> gets things up and running easily and fast and perfectly acceptably, >> or I could "proofread" all the gunk, I mean cloned headers, fix them >> for current system, worry if they break old system, or delete them, >> possibly doing some hypothetical damage to the old ports. >> >> >> It seems easier and a better result to "start over" and leave the >> old stuff alone, >> maybe delete it, depending on what people think of history >> preservation and >> history vs. deletes (deleted stuff isn't very visible). >> >> >> Or maybe hardly any of this matters. Nobody uses these platforms or >> anything like them? >> (I recall Randy saying he is still using 4.1 on HP-UX though. I'm >> on a fun little >> long running errand here of getting not ancient but not current >> systems.. :) ) >> >> >> The "4", "2", "5" in FreeBSD4, NetBSD2_i386, IRIX5 make them seen >> somewhat "wrong". >> >> >> The "4" in FreeBSD4 (err, in i686-freebsd4) does have a surprising >> semantic, in the backend..but maybe not. >> C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(53): >> builtin_define_with_int_value ("__FreeBSD__", FBSD_MAJOR); \ >> C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(122):#if >> FBSD_MAJOR < 5 >> C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(141):#if >> FBSD_MAJOR < 6 >> >> >> though I think if you look closely, these don't matter to us. >> They affect the gcc driver and the C/C++ front end, but maybe not >> the m3cg backend. >> >> >> Even the "LIBC6" in "LINUXLIBC6" seems dubious, because, for >> example, I am >> tempted to make "ARM_LINUX_UCLIBC", which suggests either that >> there might be an "I386_LINUX_UCLIBC" or "generic" "I386_LINUX" that >> is portable across libc6/uclibc/dietlibc/newlib either by seeing >> what they have in common, or skipping them and using the kernel >> interfaces >> more directly. >> >> >> There is another angle here. >> To what extent is the compiler platform specific? >> (I mostly know the answer to this. It is a leading question.) >> Could ports go away? >> Almost? >> >> >> Historically there were a bunch of platform-specific .i3 files. >> That is dwindling much in some platforms and could dwindle much >> overall. >> A little more C code in the system and the Modula-3 .i3 files are >> all "portable". >> >> >> It ends up being, roughly, that there is: >> >> >> endian, and even this is often not an issue; I saw like >> one reference in the compiler to it, and there is a little bit in >> m3core/libm3 >> The byte swap functions and maybe the Float stuff (there is endian >> specific >> and generic stuff, not all is used). >> It would affect e.g. the layout of the Uexec types, but they are >> gone. >> Such endian-specificity could occur anywhere but maybe "cm3 - >> generic" errors for it? >> >> >> word size -- 32bit or 64bit. There is no escaping this, as long as >> there are any 32bit platforms. >> So ok, two ports, 32bit and 64bit. That's a small matrix. >> >> >> IEEE or not -- everything is IEEE now. I don't plan on getting a >> VAX. :) >> (The compiler seems suspicious here wrt cross building.) >> >> >> The name of setjmp. >> However this could be made the same everywhere -- m3_setjmp or >> M3Try or M3SaveState, >> and use an #ifdef .c file to decide. >> >> >> The size of the jmpbuf. Ah, there's the rub. >> A "generic" platform could blow up the size of the jmpbuf to >> something that works >> on all known platforms. Very very wasteful. Some platforms have >> tiny, some have huge. >> >> >> I'm not sure where stack layout is done. If the front end does it >> or not. >> You could imagine something like M3Try allocating the same..but >> this seems bad. >> If the front end defers enough work to the backend, you could >> introduce an abstracted >> notion of the jmpbuf and leave it to m3cg to fill in? Leave it to >> #ifdef on the target? >> m3cg, in its current form as gcc based is always going to have be >> configured to be >> target specific. >> >> >> Or all platforms could have stack walkers and this platform- >> specificity would go away. >> But that is a very long ways off, if ever. >> >> >> My point is, you know, can we in fact eliminate the notion of >> porting? >> At least of cm3 knowing anything about the target, and only m3cg? >> Because the system is nearly portable enough? All that is left is >> configuring gcc? >> It seems very close to possible. >> >> >> Like, "have gcc, will travel"? >> And nothing else changes? >> No value then in doing any porting work up front? >> >> >> You know..think of the author of hello world..some highly portable >> program. >> Or more realistic example such as bash, awk, make, ld and gcc on a >> particular host (not target), etc. >> They don't go around much and port to this or that or the other >> system. >> They do a mix of "just try to be portable" and "leave autoconf to >> figure out". >> >> >> Modula-3 is almost in the same boat? >> >> >> - Jay >> >> From eiserlohpp at yahoo.com Sun Jan 18 04:09:35 2009 From: eiserlohpp at yahoo.com (Peter Eiserloh) Date: Sat, 17 Jan 2009 19:09:35 -0800 (PST) Subject: [M3devel] Multiple CM3_ROOTs Message-ID: <495761.443.qm@web56802.mail.re3.yahoo.com> Hi Tony and Gang, The hypothetical scenario is a system providing multiple user accounts. The sysadmin will install a released version of CM3, not a daily snapshot. Any user should be able to install a daily snapshot, and old one, or a custom version, for their particular use. This would go within a directory of their choosing (within their personal HOME). These users, may have many customized versions of libm3 (and m3core), and hence many installations of an M3 compiler. A git repository has already been imported from the main CVS repository at elego. Any user (at the moment thats just me) may create any number of branches and play with the code. How can I ship to a different CM3_ROOT, than the one that built it? When using a different CM3_ROOT than the standard one, the user would obviously have to set their PATH and CM3 environment variables appropriately. How does the cm3 compiler frontend know the path to its config file? Does it walk argv[0] up the directory chain, and use the PATH to find itself, or is the path build-in? Does it use the environment variable CM3 if found? +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ From dabenavidesd at yahoo.es Sun Jan 18 05:50:16 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 17 Jan 2009 20:50:16 -0800 (PST) Subject: [M3devel] Multiple CM3_ROOTs In-Reply-To: <495761.443.qm@web56802.mail.re3.yahoo.com> Message-ID: <224644.55641.qm@web24707.mail.ird.yahoo.com> Hi Peter: what I learned is that the cm3 compiler finds it's config file in the same directory of the cm3 compiler executable, otherwise it reports an error (about it). I know from cm3 -? that: from http://www.opencm3.net/doc/help/cm3/cm3-quickref.html environment variables: M3CONFIG platform dependent configuration file to use (cm3.cfg) used if no suitable file is found in the local packageHowever I don't how can be used the compiler to ship and compile according the abstracted config files made by Jay specially in the NT386 and derived platforms (I guess would be nice to set that in the command itself like select to alternative not common configurations of graphic libs? or back ends, etc, ...) with the same libm3 and m3core. Thanks in advance --- El s?b, 17/1/09, Peter Eiserloh escribi?: De: Peter Eiserloh Asunto: [M3devel] Multiple CM3_ROOTs Para: m3devel at elegosoft.com Fecha: s?bado, 17 enero, 2009 10:09 Hi Tony and Gang, The hypothetical scenario is a system providing multiple user accounts. The sysadmin will install a released version of CM3, not a daily snapshot. Any user should be able to install a daily snapshot, and old one, or a custom version, for their particular use. This would go within a directory of their choosing (within their personal HOME). These users, may have many customized versions of libm3 (and m3core), and hence many installations of an M3 compiler. A git repository has already been imported from the main CVS repository at elego. Any user (at the moment thats just me) may create any number of branches and play with the code. How can I ship to a different CM3_ROOT, than the one that built it? When using a different CM3_ROOT than the standard one, the user would obviously have to set their PATH and CM3 environment variables appropriately. How does the cm3 compiler frontend know the path to its config file? Does it walk argv[0] up the directory chain, and use the PATH to find itself, or is the path build-in? Does it use the environment variable CM3 if found? +--------------------------------------------------------+ | Peter P. Eiserloh | +--------------------------------------------------------+ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 18 10:04:57 2009 From: jay.krell at cornell.edu (Jay) Date: Sun, 18 Jan 2009 09:04:57 +0000 Subject: [M3devel] Multiple CM3_ROOTs In-Reply-To: <224644.55641.qm@web24707.mail.ird.yahoo.com> References: <495761.443.qm@web56802.mail.re3.yahoo.com> <224644.55641.qm@web24707.mail.ird.yahoo.com> Message-ID: I didn't change how the compiler "starts", how it finds the first config file. Config files can go off and include others. The below sounds slightly wrong. I believe the M3CONFIG environment variable is checked before the cm3.cfg file "next to" cm3 is used. What I do is my cm3.cfg "next to" cm3 then goes and looks for the "real" config file. It is guided by - knowing where the source tree is, via the environment variable CM3_ROOT - knowing the host, via the HOST variable that I added to cm3 - if HOST isn't defined, it generally fails, except on NT it can use the OS environment variable. CM3_INSTALL or INSTALLROOT is the root of the cm3 installation. CM3_ROOT or ROOT is the root of the cm3 source tree. I don't find these names ideal, but I also am not super keen on changing them. Clearer and more consistent would be CM3_INSTALL_ROOT and CM3_SOURCE_ROOT. Within quake are available variables without the leading "CM3_". Environment variables with leading "CM3_" I think are the way to go. And that is /generally/ how it works, but not necessarily exactly. Also, my cm3.cfg sets INSTALLROOT based on its own location. To learn how to ship to another root... My make-dist.py accomplishes this. I think the way it works though is it copies cm3 out to a new location and runs it from there. And the cm3.cfg. INSTALLROOT or CM3_INSTALL is therefore the location of wherever cm3 is copied to and run from. Personally I think the system is somewhat misdesigned. Regarding link output and shipped output, there should just be one place. The only point in a two step link and ship/install is if you are installing over a live system. A simpler better approach is to always use a new or staging area for the link output, and if you are happy with it, you merely do a recursive copy on top of your live system. Or, you change PATH to point to the new cm3 and adopt it as your new system. This also addresses the problem that cm3 can't ship itself. This also could be part of giving an alternate location for the "intermediate" outputs that never shipped -- the .obj file. They should not litter the source tree. You know, on a package basis, Modula-3 is/was progressive in that not only does it support "out of source" builds, but it only supports them. And you can cons up arbitrary new intermediate locations on demand by changing BUILD_DIR. Though sometimes assumptions creep in that BUILD_DIR == TARGET. However, if you consider multiple packages, then the intermediate outputs actually are in the source tree. There aren't many very visible analogs in the world. However one is how gcc builds. It ties together multiple packages (optionally) and all the outputs go outside of the entire source tree. - Jay ________________________________ > Date: Sat, 17 Jan 2009 20:50:16 -0800 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com; eiserlohpp at yahoo.com > Subject: Re: [M3devel] Multiple CM3_ROOTs > > Hi Peter: > what I learned is that the cm3 compiler finds it's config file in the same directory of the cm3 compiler executable, otherwise it reports an error (about it). > I know from cm3 -? that: > from http://www.opencm3.net/doc/help/cm3/cm3-quickref.html > environment variables: > > M3CONFIG platform dependent configuration file to use (cm3.cfg) > used if no suitable file is found in the local package > > However I don't how can be used the compiler to ship and compile according the abstracted config files made by Jay specially in the NT386 and derived platforms (I guess would be nice to set that in the command itself like select to alternative not common configurations of graphic libs or back ends, etc, ...) with the same libm3 and m3core. > > Thanks in advance > --- El s?b, 17/1/09, Peter Eiserloh > escribi?: > De: Peter Eiserloh > Asunto: [M3devel] Multiple CM3_ROOTs > Para: m3devel at elegosoft.com > Fecha: s?bado, 17 enero, 2009 10:09 > > > Hi Tony and Gang, > > The hypothetical scenario is a system providing multiple > user accounts. The sysadmin will install a released > version of CM3, not a daily snapshot. Any user should be > able to install a daily snapshot, and old one, or a custom > version, for their particular use. This would go within > a directory of their choosing (within their personal HOME). > > These users, may have many customized versions of libm3 > (and m3core), and hence many installations of an M3 > compiler. > > A git repository has already been imported from the main > CVS repository at elego. Any user (at the moment > thats > just me) may create any number of branches and play with > the code. > > How can I ship to a different CM3_ROOT, than the one that > built it? > > When using a different CM3_ROOT than the standard one, the > user would obviously have to set their PATH and CM3 > environment variables appropriately. How does the cm3 > compiler frontend know the path to its config file? > Does it walk argv[0] up the directory chain, and use the > PATH to find itself, or is the path build-in? Does it use > the environment variable CM3 if found? > > > +--------------------------------------------------------+ > | Peter P. Eiserloh | > +--------------------------------------------------------+ > > > > > From jay.krell at cornell.edu Mon Jan 19 13:47:15 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 19 Jan 2009 12:47:15 +0000 Subject: [M3devel] "new old" ports, or no ports at all? In-Reply-To: <49706962.1E75.00D7.1@scires.com> References: <49706962.1E75.00D7.1@scires.com> Message-ID: I assume they can run 64bit? My system can/is. I have to research if 1.1 is 32bit, 2.0 is 64bit, or if there is a larger matrix. Any preference among "HPPA64_HPUX" vs. "PA64_HPUX" -- the double "HP" is kind of redundant. The minimum gcc configuration names I found to work are hppa64-hpux11 and presumably hppa-hpux11. The major version is required, else configure errors out "unsupported". Similarly: reusing existing "HPPA" or introduce "HPPA32_HPUX" or "PA32_HPUX"? My inclination is PA32_HPUX, PA64_HPUX, but any is ok. "PA" is shorter, but "HPPA64" is not record settingly long -- we have "SPARC64", and "SPARC32" that I introduced. The names will then apply to *_LINUX as well. Also you must have GNU as for this port. m3cc/src/m3makefile indicates that was already the case for the old HPPA. gcc 3.3.6 is ok with the HP assembler, though I don't remember if -g worked. But gcc 4.3.2 is not ok with the HP assembler. - Jay ________________________________ > Date: Fri, 16 Jan 2009 11:04:53 -0500 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] "new old" ports, or no ports at all? > > > > > > > > > > Jay: > > > > I do have some HP-UX machines that I could use to test whatever you come up with for HPPA. You are correct that right now I run cm3 v4.1 on these. I have not tried to move beyond 4.1 on them yet. > > > > Regards, > > Randy > >>>> Jay 1/16/2009 8:05 AM>>> > Would people mind "new" ports like: > > > HPPA32_HPUX (HPPA_HPUX? There is "HPPA") > I386_FREEBSD (There is FreeBSD4.) > I386_NETBSD (There is NetBSD2_i386.) > MIPS32_IRIX (MIPS_IRIX? There is IRIX5.) > ALPHA_FREEBSD (There FBSD_ALPHA.) > and then for that matter: > SPARC32_SOLARIS, I386_LINUX > > > Or some mix? > This is not hypothetical. I do now have HPPA, Alpha, SGI hardware. :) > > > I can either do the little bit of correct testable valid small etc. work > of using my "more portable" approach to these platforms, which > gets things up and running easily and fast and perfectly acceptably, > or I could "proofread" all the gunk, I mean cloned headers, fix them > for current system, worry if they break old system, or delete them, > possibly doing some hypothetical damage to the old ports. > > > It seems easier and a better result to "start over" and leave the old stuff alone, > maybe delete it, depending on what people think of history preservation and > history vs. deletes (deleted stuff isn't very visible). > > > Or maybe hardly any of this matters. Nobody uses these platforms or anything like them? > (I recall Randy saying he is still using 4.1 on HP-UX though. I'm on a fun little > long running errand here of getting not ancient but not current systems.. :) ) > > > The "4", "2", "5" in FreeBSD4, NetBSD2_i386, IRIX5 make them seen somewhat "wrong". > > > The "4" in FreeBSD4 (err, in i686-freebsd4) does have a surprising semantic, in the backend..but maybe not. > C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(53): builtin_define_with_int_value ("__FreeBSD__", FBSD_MAJOR); \ > C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(122):#if FBSD_MAJOR < 5 > C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(141):#if FBSD_MAJOR < 6 > > > though I think if you look closely, these don't matter to us. > They affect the gcc driver and the C/C++ front end, but maybe not the m3cg backend. > > > Even the "LIBC6" in "LINUXLIBC6" seems dubious, because, for example, I am > tempted to make "ARM_LINUX_UCLIBC", which suggests either that > there might be an "I386_LINUX_UCLIBC" or "generic" "I386_LINUX" that > is portable across libc6/uclibc/dietlibc/newlib either by seeing > what they have in common, or skipping them and using the kernel interfaces > more directly. > > > There is another angle here. > To what extent is the compiler platform specific? > (I mostly know the answer to this. It is a leading question.) > Could ports go away? > Almost? > > > Historically there were a bunch of platform-specific .i3 files. > That is dwindling much in some platforms and could dwindle much overall. > A little more C code in the system and the Modula-3 .i3 files are all "portable". > > > It ends up being, roughly, that there is: > > > endian, and even this is often not an issue; I saw like > one reference in the compiler to it, and there is a little bit in m3core/libm3 > The byte swap functions and maybe the Float stuff (there is endian specific > and generic stuff, not all is used). > It would affect e.g. the layout of the Uexec types, but they are gone. > Such endian-specificity could occur anywhere but maybe "cm3 -generic" errors for it? > > > word size -- 32bit or 64bit. There is no escaping this, as long as there are any 32bit platforms. > So ok, two ports, 32bit and 64bit. That's a small matrix. > > > IEEE or not -- everything is IEEE now. I don't plan on getting a VAX. :) > (The compiler seems suspicious here wrt cross building.) > > > The name of setjmp. > However this could be made the same everywhere -- m3_setjmp or M3Try or M3SaveState, > and use an #ifdef .c file to decide. > > > The size of the jmpbuf. Ah, there's the rub. > A "generic" platform could blow up the size of the jmpbuf to something that works > on all known platforms. Very very wasteful. Some platforms have tiny, some have huge. > > > I'm not sure where stack layout is done. If the front end does it or not. > You could imagine something like M3Try allocating the same..but this seems bad. > If the front end defers enough work to the backend, you could introduce an abstracted > notion of the jmpbuf and leave it to m3cg to fill in? Leave it to #ifdef on the target? > m3cg, in its current form as gcc based is always going to have be configured to be > target specific. > > > Or all platforms could have stack walkers and this platform-specificity would go away. > But that is a very long ways off, if ever. > > > My point is, you know, can we in fact eliminate the notion of porting? > At least of cm3 knowing anything about the target, and only m3cg? > Because the system is nearly portable enough? All that is left is configuring gcc? > It seems very close to possible. > > > Like, "have gcc, will travel"? > And nothing else changes? > No value then in doing any porting work up front? > > > You know..think of the author of hello world..some highly portable program. > Or more realistic example such as bash, awk, make, ld and gcc on a particular host (not target), etc. > They don't go around much and port to this or that or the other system. > They do a mix of "just try to be portable" and "leave autoconf to figure out". > > > Modula-3 is almost in the same boat? > > > - Jay > From wagner at elegosoft.com Mon Jan 19 16:09:21 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 19 Jan 2009 16:09:21 +0100 Subject: [M3devel] What is M3SU? In-Reply-To: <49716A77.60405@bellsouth.net> References: <49716A77.60405@bellsouth.net> Message-ID: <20090119160921.s5v4nsv3j4g4g0oo@mail.elegosoft.com> Quoting Martin Bishop : > I was reading the FAQ for Modula-3, and noticed they mentioned a program > called "m3su". The link they give to an ftp server is no longer > available, but with a little poking around I found where it is located > at, however they do not have 'm3su' on it anymore. > > What is (or was?) m3su? The FAQ says it is an emcas macro package; I've never used it AFAIK. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jan 19 23:39:34 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 19 Jan 2009 22:39:34 +0000 Subject: [M3devel] move to version 5.7.1? Message-ID: 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 rcoleburn at scires.com Tue Jan 20 00:50:40 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 19 Jan 2009 18:50:40 -0500 Subject: [M3devel] move to version 5.7.1? In-Reply-To: References: Message-ID: <4974CB61.1E75.00D7.1@scires.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jan 20 03:28:07 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 20 Jan 2009 02:28:07 +0000 Subject: [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: 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 jay.krell at cornell.edu Tue Jan 20 07:03:09 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 20 Jan 2009 06:03:09 +0000 Subject: [M3devel] ship vs. where build outputs go, etc.? In-Reply-To: References: <4974CB61.1E75.00D7.1@scires.com> Message-ID: > [was truncated and forward to m3commit instead of m3devel, now more content/drivel..] ps: >> 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. "Clean" doesn't really work imho..I guess it deletes the output files that the compiler knows about? Perhaps it is a bug when the config file doesn't tell it about all the outputs? "realclean" deletes the entire output directory, no matter what files it thinks it produced. It does assume they are all in the particular directory that they strongly tend to be in. It's dumb imho. Clean should probably be fixed. The m3-sys/m3cc directory and probably m3gdb also have their own special in-between state of "configure having been one", that they create a marker file to indicate. And then there is an environment variable to override that. Quake is a fairly general purpose language including the ability to read environment variables, so various directories are free to do whatever they want. m3cc and m3gdb are two of the longest to build package and configuration is also a slow step, that "rarely" has different output, so going back only to this "partly built" state perhaps is interesting. I rarely do that, at least on purpose. The Linux kernel and ucLibc (an alternative C runtime) do something similar. They store their configuration in file starting with a dot, so that on Unix rm -rf * won't delete it, because it skips "hidden" "dot" files. As well you can define arbitrary things on the cm3 command line, to guide arbitrary decisions around the tree, such as kernel vs. user threads. Given foo\src build outputs are generally in foo\target where "outputs" include "intermediate" files such as object files and "final" outputs such as executables and .dlls. You know...really I think, it's just that the Modula-3 folks knew/thought they were smarter than everyone else and made up their own terminology. In many other projects you have "make" and "make install". "ship" is "make install". I think that is all people need to know: "ship" == "install". It copies some of the outputs from foo\target to the installroot. Just as "make install" copies some of the outputs from the "intermediate" tree to the "live" tree. They can both be "dangerous" on a live system, and they can both be pointed at "new" empty location for safety (typical GNU make/automake/autoconf install option is make install DESTDIR=somewhere). I propose a different model. Always put the "final" outputs directly in a "live" tree, BUT for the case where you are doing something "risky" and would not immediately "ship" / "install", you would be encouraged to define a new clean output root, or an existing "test" root. "Actual install" would then be just a recursive copy from one root to another. Perhaps that is too inefficient? cm3 tries to do an incremental copy for example. I'm not sure if it is timestamp based or if they compare entire file contents. The downside to this proposal is that source files also get shipped, and doing that for every compile/link is wasteful. This is optional though and maybe can/should be turned off except when "making a distribution"? I'm not sure how optional it is. I'll try out turning it off locally. An upside to this proposal is it supercedes the "override" mechanism. You would never need to "override". "override" imho is broken because today, in order to keep "override" working, you are expected to encode the source tree structure all over the place. This seems redundant. Perhaps another idea would be for CM3_INSTALL to be colon/semicolon delimited? Search multiple package stores? That offers functionality not in the current model. A related proposal I have is that even the intermediate files be relocated. As I said, on a package-by-package basis, they are not in the source tree. Good. But on a multi-package basis, they are. Not good. I want the source tree to have no outputs, to stay "clean", unless I edit a file. Concretely this all looks like: 1) There is already the CM3_INSTALL environment variable. That is where "binaries" should be output, in the same structure that "ship" uses today. 2) There shall be a new environment variable, something like CM3_OBJECT_ROOT. 3) The existing CM3_ROOT that is the root of the source tree shall come into play. Given building in CM3_ROOT/foo/bar output shall go into: CM3_OBJECT_ROOT/foo/bar/target or maybe CM3_OBJECT_ROOT/target/foo/bar or maybe CM3_OBJECT_ROOT/foo/bar instead of CM3_ROOT/foo/bar/target. If you are not building under CM3_ROOT, there are a few viable options. 1) Do things as they are today. 2) Form up a form of CM3_OBJECT_ROOT/the path you are building that is valid and predictable. For example, in Windows, given a full path with a colon in it, remove the colon and you have a valid relative path you can append to another root. 3) Give user a way to specify what their "root" or "relative path from root" is. Because outputs litter the source tree today..unless you engage in changing BUILD_DIR, which maybe is the way in a few ways actually..you can't do multiple concurrent builds of the same target, such as with a different %PATH% to a different cm3.exe. Now, there is already BUILD_DIR. Perhaps all this is as simple as a change in the config file, changing BUILD_DIR to something like CM3_ROOT/path_of(foo.m3)/TARGET. I'll try that later. Maybe it just works. ? I'm not confident it'll work but maybe. Am I crazy? Wrong? Too disruptive? Most likely the last. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3commit at elegosoft.com; rcoleburn at scires.com > Date: Tue, 20 Jan 2009 05:40:07 +0000 > Subject: [M3commit] FW: [M3devel] move to version 5.7.1? > > > [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 jay.krell at cornell.edu Tue Jan 20 13:20:03 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 20 Jan 2009 12:20:03 +0000 Subject: [M3devel] win32 vs. Posix struct_linger code backwards?? Message-ID: Isn't this highly suspicious? It looks like Win32 turns "linger" off, and Posix turns it on. Win32: PROCEDURE InitSock (sock: WinSock.SOCKET) = (* We assume that the runtime ignores SIGPIPE signals *) (* LL = mu *) VAR one := 1; linger := WinSock.struct_linger{0, 0}; BEGIN (***** EVAL WinSock.setsockopt (sock, WinSock.SOL_SOCKET, WinSock.SO_SNDBUF, ADR(SysSendBufSize), BYTESIZE(SysSendBufSize)); EVAL WinSock.setsockopt (sock, WinSock.SOL_SOCKET, WinSock.SO_RCVBUF, ADR(SysRcvBufSize), BYTESIZE(SysRcvBufSize)); ******) EVAL WinSock.setsockopt (sock, WinSock.SOL_SOCKET, WinSock.SO_LINGER, ADR(linger), BYTESIZE(linger)); (**** WinSock documentation warns that this may cause problems ****) EVAL WinSock.setsockopt (sock, WinSock.IPPROTO_TCP, WinSock.TCP_NODELAY, ADR(one), BYTESIZE(one)); END InitSock; Posix: PROCEDURE InitStream (fd: CARDINAL) RAISES {OSError.E} = (* We assume that the runtime ignores SIGPIPE signals *) VAR one := 1; linger := Usocket.struct_linger{1, 1}; BEGIN (***** EVAL Usocket.setsockopt(fd, Usocket.SOL_SOCKET, Usocket.SO_SNDBUF, ADR(SysSendBufSize), BYTESIZE(SysSendBufSize)); EVAL Usocket.setsockopt(fd, Usocket.SOL_SOCKET, Usocket.SO_RCVBUF, ADR(SysRcvBufSize), BYTESIZE(SysRcvBufSize)); ******) EVAL Usocket.setsockopt(fd, Usocket.SOL_SOCKET, Usocket.SO_LINGER, ADR(linger), BYTESIZE(linger)); EVAL Usocket.setsockopt(fd, Uin.IPPROTO_TCP, TCP_NODELAY, ADR(one), BYTESIZE(one)); MakeNonBlocking (fd); END InitStream; From jay.krell at cornell.edu Tue Jan 20 15:12:55 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 20 Jan 2009 14:12:55 +0000 Subject: [M3devel] chosing SIG_SUSPEND? Message-ID: What is the algorithm for chosing SIG_SUSPEND? Something like: #include #ifdef __APPLE__ /* nothing -- SIG_SUSPEND not used */ #elif defined(NSIG) #define SIG_SUSPEND (NSIG - 1) #elif defined(_NSIG) #define SIG_SUSPEND (_NSIG - 1) #elif defined(SIGRTMAX) #define SIG_SUSPEND SIGRTMAX #else #define SIG_SUSPEND SIGUSR2 #endif ? Whatever it is, I think it should be in RTSignalC.c. - Jay From mika at async.caltech.edu Tue Jan 20 15:39:20 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 20 Jan 2009 06:39:20 -0800 Subject: [M3devel] [M3commit] FW: move to version 5.7.1? In-Reply-To: Your message of "Tue, 20 Jan 2009 05:40:07 GMT." Message-ID: <200901201439.n0KEdKr0094091@camembert.async.caltech.edu> Jay writes: ... >---------------------------------------- >> 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 ... >> >> 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. How about in Scheme? I have written/am writing a Scheme interpreter in Modula-3 that I am happy to release with CM3; it's very easily extensible (that's sort of the point of it), so one can easily add low-level features to it as necessary. The system would be self-contained with that interpreter. Maybe writing scripts in Scheme is a little "weird"... (but I do it :-) ) Mika From hosking at cs.purdue.edu Tue Jan 20 17:42:01 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 21 Jan 2009 03:42:01 +1100 Subject: [M3devel] chosing SIG_SUSPEND? In-Reply-To: References: Message-ID: Choose SIGRTMAX first if defined, then SIGUSR2. I don't thing NSIG-1 is reliable, but just works on some systems. On 21 Jan 2009, at 01:12, Jay wrote: > > What is the algorithm for chosing SIG_SUSPEND? > > Something like: > > #include > > #ifdef __APPLE__ > /* nothing -- SIG_SUSPEND not used */ > #elif defined(NSIG) > #define SIG_SUSPEND (NSIG - 1) > #elif defined(_NSIG) > #define SIG_SUSPEND (_NSIG - 1) > #elif defined(SIGRTMAX) > #define SIG_SUSPEND SIGRTMAX > #else > #define SIG_SUSPEND SIGUSR2 > #endif > > ? > > Whatever it is, I think it should be in RTSignalC.c. > > - Jay From rcoleburn at scires.com Tue Jan 20 18:07:01 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 20 Jan 2009 12:07:01 -0500 Subject: [M3devel] ship vs. where build outputs go, etc.? In-Reply-To: References: <4974CB61.1E75.00D7.1@scires.com> Message-ID: <4975BE3A.1E75.00D7.1@scires.com> Jay: I think your email illustrates part of what I was trying to say in that there are a lot of things that aren't documented very well at this point that differ from the current documentation and practice that we've followed over the years. I'm not sure I agree with some of the proposals you offer. To be fair though, I think we should single out one proposal at a time for discussion. As for m3overrides and private vs. public repositories, I think you are going to get a lot of push-back on the idea to always ship everything to the public repository. I for one, don't like this idea. I do agree that the compiler's idea of certain options, e.g., clean, may not match what everyone expects. Of course, many of us have written scripts, etc. that invoke the compiler with certain options and that do other "stuff" using some of the same terminology (e.g. clean, ship, build, buildship, realclean, zap, etc.). I am arguing that the terminology should be standardized to have a consistent meaning across all of these. Depending on the definitions, some code will need to change make the implementation match the definition. Regards, Randy >>> Jay 1/20/2009 1:03 AM >>> > [was truncated and forward to m3commit instead of m3devel, now more content/drivel..] ps: >> 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. "Clean" doesn't really work imho..I guess it deletes the output files that the compiler knows about? Perhaps it is a bug when the config file doesn't tell it about all the outputs? "realclean" deletes the entire output directory, no matter what files it thinks it produced. It does assume they are all in the particular directory that they strongly tend to be in. It's dumb imho. Clean should probably be fixed. The m3-sys/m3cc directory and probably m3gdb also have their own special in-between state of "configure having been one", that they create a marker file to indicate. And then there is an environment variable to override that. Quake is a fairly general purpose language including the ability to read environment variables, so various directories are free to do whatever they want. m3cc and m3gdb are two of the longest to build package and configuration is also a slow step, that "rarely" has different output, so going back only to this "partly built" state perhaps is interesting. I rarely do that, at least on purpose. The Linux kernel and ucLibc (an alternative C runtime) do something similar. They store their configuration in file starting with a dot, so that on Unix rm -rf * won't delete it, because it skips "hidden" "dot" files. As well you can define arbitrary things on the cm3 command line, to guide arbitrary decisions around the tree, such as kernel vs. user threads. Given foo\src build outputs are generally in foo\target where "outputs" include "intermediate" files such as object files and "final" outputs such as executables and .dlls. You know...really I think, it's just that the Modula-3 folks knew/thought they were smarter than everyone else and made up their own terminology. In many other projects you have "make" and "make install". "ship" is "make install". I think that is all people need to know: "ship" == "install". It copies some of the outputs from foo\target to the installroot. Just as "make install" copies some of the outputs from the "intermediate" tree to the "live" tree. They can both be "dangerous" on a live system, and they can both be pointed at "new" empty location for safety (typical GNU make/automake/autoconf install option is make install DESTDIR=somewhere). I propose a different model. Always put the "final" outputs directly in a "live" tree, BUT for the case where you are doing something "risky" and would not immediately "ship" / "install", you would be encouraged to define a new clean output root, or an existing "test" root. "Actual install" would then be just a recursive copy from one root to another. Perhaps that is too inefficient? cm3 tries to do an incremental copy for example. I'm not sure if it is timestamp based or if they compare entire file contents. The downside to this proposal is that source files also get shipped, and doing that for every compile/link is wasteful. This is optional though and maybe can/should be turned off except when "making a distribution"? I'm not sure how optional it is. I'll try out turning it off locally. An upside to this proposal is it supercedes the "override" mechanism. You would never need to "override". "override" imho is broken because today, in order to keep "override" working, you are expected to encode the source tree structure all over the place. This seems redundant. Perhaps another idea would be for CM3_INSTALL to be colon/semicolon delimited? Search multiple package stores? That offers functionality not in the current model. A related proposal I have is that even the intermediate files be relocated. As I said, on a package-by-package basis, they are not in the source tree. Good. But on a multi-package basis, they are. Not good. I want the source tree to have no outputs, to stay "clean", unless I edit a file. Concretely this all looks like: 1) There is already the CM3_INSTALL environment variable. That is where "binaries" should be output, in the same structure that "ship" uses today. 2) There shall be a new environment variable, something like CM3_OBJECT_ROOT. 3) The existing CM3_ROOT that is the root of the source tree shall come into play. Given building in CM3_ROOT/foo/bar output shall go into: CM3_OBJECT_ROOT/foo/bar/target or maybe CM3_OBJECT_ROOT/target/foo/bar or maybe CM3_OBJECT_ROOT/foo/bar instead of CM3_ROOT/foo/bar/target. If you are not building under CM3_ROOT, there are a few viable options. 1) Do things as they are today. 2) Form up a form of CM3_OBJECT_ROOT/the path you are building that is valid and predictable. For example, in Windows, given a full path with a colon in it, remove the colon and you have a valid relative path you can append to another root. 3) Give user a way to specify what their "root" or "relative path from root" is. Because outputs litter the source tree today..unless you engage in changing BUILD_DIR, which maybe is the way in a few ways actually..you can't do multiple concurrent builds of the same target, such as with a different %PATH% to a different cm3.exe. Now, there is already BUILD_DIR. Perhaps all this is as simple as a change in the config file, changing BUILD_DIR to something like CM3_ROOT/path_of(foo.m3)/TARGET. I'll try that later. Maybe it just works. ? I'm not confident it'll work but maybe. Am I crazy? Wrong? Too disruptive? Most likely the last. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3commit at elegosoft.com; rcoleburn at scires.com > Date: Tue, 20 Jan 2009 05:40:07 +0000 > Subject: [M3commit] FW: [M3devel] move to version 5.7.1? > > > [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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jan 20 19:32:46 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 20 Jan 2009 18:32:46 +0000 Subject: [M3devel] FW: move to version 5.7.1? In-Reply-To: <200901201439.n0KEdKr0094091@camembert.async.caltech.edu> References: Your message of "Tue, 20 Jan 2009 05:40:07 GMT." <200901201439.n0KEdKr0094091@camembert.async.caltech.edu> Message-ID: If it is part of the cm3 tree then I (for one) am ok with it. It would have to be part of the "min" set. Will it work on Windows or is it Posix-specific? Working on Windows is kind of the point in question, since the *.sh files are fine for Unix. JScript, Python, and maybe Quake should also do. Possible problem with Quake and Scheme is it won't work for bootstrapping from older release. Problem with JScript is it'll be Windows specific. Therefore you are stuck still with two (or three or four!) sets of files. Best to have one set that work "everywhere". Bash and Python don't have these problems, they work with older cm3 and on all platforms. (I reluctantly lump Bash in with Python as being good because I still haven't gotten around to get Python to compile on my MIPS64_OPENBSD system and use the Bash files on it.) Bootstrapping eventually isn't an issue, eventually. - Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Tue, 20 Jan 2009 06:39:20 -0800 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] FW: move to version 5.7.1? > > > Jay writes: > ... >>---------------------------------------- >>> 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 > ... >>> >>> 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. > > How about in Scheme? I have written/am writing a Scheme interpreter > in Modula-3 that I am happy to release with CM3; it's very easily > extensible (that's sort of the point of it), so one can easily add > low-level features to it as necessary. The system would be > self-contained with that interpreter. Maybe writing scripts in > Scheme is a little "weird"... (but I do it :-) ) > > Mika > From jay.krell at cornell.edu Tue Jan 20 19:50:40 2009 From: jay.krell at cornell.edu (Jay) Date: Tue, 20 Jan 2009 18:50:40 +0000 Subject: [M3devel] ship vs. where build outputs go, etc.? In-Reply-To: <4975BE3A.1E75.00D7.1@scires.com> References: <4974CB61.1E75.00D7.1@scires.com> <4975BE3A.1E75.00D7.1@scires.com> Message-ID: The point is it would not always be the "public" repositoy. Today we have two places, the source tree and the repository. They have different structures. Instead, you could just have multiple repositories. They would all have the same structure. "Install" or "ship" is just recursive copy from a "private" repository to the "public" repository, instead of arbitrary rearrangement of files. OR merely "blessing" a private repository and making it the new public repository, such as by setting and an environment variable or possibly delete/rename. You could get something closer to the current experience by having two environment variables, CM3_PUBLIC, CM3_PRIVATE. cm3 -buildship would output to CM3_PUBLIC. cm3 -build would output to CM3_PRIVATE. Ideally it would do no extra writes vs. the current scheme. "Upgrade" would look like: set CM3_PRIVATE= some new temporary place build everything if successful rm -rf CM3_PUBLIC mv CM3_PUBLIC CM3_PRIVATE See, today "upgrade" writes over the live system and is therefore "dangerous". In this new scheme, "ship" would lose much of its danger. Rather than making changes as it goes, the final "commit" would not occur until the end, and would be easier to keep backups and such. Granted, if you look at what make-dist does, this is already possible today, by twiddling with CM3_INSTALL and always shipping. Though that costs extra I/O and you do have to prepopulate CM3_INSTALL..at least with a compiler, eh, just two files. Also with m3core/libm3 in some bootstrapping scenarios. (make-dist assumes so, though it usually is not the case). Along with an alternate root for intermediate outputs, this would enable multiple concurrent builds as well. A similar proposal is that "CM3_PUBLIC" could be colon or semicolon delimited -- a "search path" for reads, write to the first location. This would probably be confusing if it contained more than two paths though. publlic/private is "limited" in that it only supports two, but you can always use recursive copy to merge. Fixing clean would not take away realclean as an option if that is necessary for compat (I forget if compiler even implements realclean; the scripts implement it and I always use that version). I find it hard to believe that anyone depends on that clean leaves a few files around. Which files does it even leave around? I'm not sure what is documented or not. Could be that a lot is? - Jay ________________________________ > Date: Tue, 20 Jan 2009 12:07:01 -0500 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] ship vs. where build outputs go, etc.? > > > > > > > > Jay: > > > > I think your email illustrates part of what I was trying to say in that there are a lot of things that aren't documented very well at this point that differ from the current documentation and practice that we've followed over the years. > > > > I'm not sure I agree with some of the proposals you offer. To be fair though, I think we should single out one proposal at a time for discussion. > > > > As for m3overrides and private vs. public repositories, I think you are going to get a lot of push-back on the idea to always ship everything to the public repository. I for one, don't like this idea. > > > > I do agree that the compiler's idea of certain options, e.g., clean, may not match what everyone expects. Of course, many of us have written scripts, etc. that invoke the compiler with certain options and that do other "stuff" using some of the same terminology (e.g. clean, ship, build, buildship, realclean, zap, etc.). I am arguing that the terminology should be standardized to have a consistent meaning across all of these. Depending on the definitions, some code will need to change make the implementation match the definition. > > > > Regards, > > Randy > >>>> Jay 1/20/2009 1:03 AM>>> > >> [was truncated and forward to m3commit instead of m3devel, now more content/drivel..] > > ps: > > >>> 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. > > > > "Clean" doesn't really work imho..I guess it deletes the output files > that the compiler knows about? Perhaps it is a bug when the > config file doesn't tell it about all the outputs? > > > "realclean" deletes the entire output directory, no matter what files it thinks it produced. > It does assume they are all in the particular directory that they strongly tend to be in. > > > It's dumb imho. > Clean should probably be fixed. > > > The m3-sys/m3cc directory and probably m3gdb also have their own special > in-between state of "configure having been one", that they create a marker > file to indicate. And then there is an environment variable to override that. > Quake is a fairly general purpose language including the ability to read > environment variables, so various directories are free to do whatever they want. > > > m3cc and m3gdb are two of the longest to build package and configuration is also a slow step, that "rarely" has different output, so going back only to this "partly built" state perhaps is interesting. I rarely do that, at least on purpose. > > > The Linux kernel and ucLibc (an alternative C runtime) do something similar. > They store their configuration in file starting with a dot, so that on Unix rm -rf * won't delete it, because it skips "hidden" "dot" files. > > > > As well you can define arbitrary things on the cm3 command line, to guide > arbitrary decisions around the tree, such as kernel vs. user threads. > > > Given > foo\src > build outputs are generally in > foo\target > > > where "outputs" include "intermediate" files such as object files and "final" outputs such as executables and .dlls. > > > You know...really I think, it's just that the Modula-3 folks knew/thought they were smarter than everyone else and made up their own terminology. > > > In many other projects you have "make" and "make install". > "ship" is "make install". I think that is all people need to know: "ship" == "install". > > > It copies some of the outputs from foo\target to the installroot. > Just as "make install" copies some of the outputs from the "intermediate" tree to the "live" tree. They can both be "dangerous" on a live system, and they can both be pointed at "new" empty location for safety (typical GNU make/automake/autoconf install option is make install DESTDIR=somewhere). > > > I propose a different model. > Always put the "final" outputs directly in a "live" tree, BUT for the case where you are doing something "risky" and would not immediately "ship" / "install", you would be encouraged to define a new clean output root, or an existing "test" root. > > > "Actual install" would then be just a recursive copy from one root to another. > Perhaps that is too inefficient? cm3 tries to do an incremental copy for example. > I'm not sure if it is timestamp based or if they compare entire file contents. > > > The downside to this proposal is that source files also get shipped, and doing that for every compile/link is wasteful. This is optional though and maybe can/should be turned off except when "making a distribution"? I'm not sure how optional it is. I'll try out turning it off locally. > > > An upside to this proposal is it supercedes the "override" mechanism. > You would never need to "override". > "override" imho is broken because today, in order to keep "override" working, you are expected to encode the source tree structure all over the place. This seems redundant. > > > Perhaps another idea would be for CM3_INSTALL to be colon/semicolon delimited? > Search multiple package stores? > That offers functionality not in the current model. > > > A related proposal I have is that even the intermediate files be relocated. > As I said, on a package-by-package basis, they are not in the source tree. > Good. But on a multi-package basis, they are. Not good. > > > I want the source tree to have no outputs, to stay "clean", unless I edit a file. > > > Concretely this all looks like: > 1) There is already the CM3_INSTALL environment variable. That is where "binaries" should be output, in the same structure that "ship" uses today. > > > 2) There shall be a new environment variable, something like CM3_OBJECT_ROOT. > > 3) The existing CM3_ROOT that is the root of the source tree shall come into play. > > > Given building in > CM3_ROOT/foo/bar > > > output shall go into: > CM3_OBJECT_ROOT/foo/bar/target > or maybe CM3_OBJECT_ROOT/target/foo/bar > or maybe CM3_OBJECT_ROOT/foo/bar > > > instead of CM3_ROOT/foo/bar/target. > > > If you are not building under CM3_ROOT, there are a few viable options. > 1) Do things as they are today. > 2) Form up a form of CM3_OBJECT_ROOT/the path you are building that is valid and predictable. For example, in Windows, given a full path with a colon in it, remove the colon and you have a valid relative path you can append to another root. > 3) Give user a way to specify what their "root" or "relative path from root" is. > > > Because outputs litter the source tree today..unless you engage in changing BUILD_DIR, which maybe is the way in a few ways actually..you can't do multiple concurrent builds of the same target, such as with a different %PATH% to a different cm3.exe. > > > Now, there is already BUILD_DIR. > Perhaps all this is as simple as a change in the config file, changing BUILD_DIR to something like CM3_ROOT/path_of(foo.m3)/TARGET. I'll try that later. > Maybe it just works. ? > I'm not confident it'll work but maybe. > > > Am I crazy? Wrong? Too disruptive? > Most likely the last. > > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3commit at elegosoft.com; rcoleburn at scires.com >> Date: Tue, 20 Jan 2009 05:40:07 +0000 >> Subject: [M3commit] FW: [M3devel] move to version 5.7.1? >> >> >> [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 rodney.bates at wichita.edu Tue Jan 20 22:04:34 2009 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Tue, 20 Jan 2009 15:04:34 -0600 Subject: [M3devel] [M3commit] FW: move to version 5.7.1? In-Reply-To: <200901201439.n0KEdKr0094091@camembert.async.caltech.edu> References: <200901201439.n0KEdKr0094091@camembert.async.caltech.edu> Message-ID: <49763C62.8050509@wichita.edu> I like the Scheme interpreter idea. I think Modula-3 partially refutes the oft-repeated argument that every programming language has a narrow range of suitability. Among the imperative languages, there's not a lot around that can beat it, even for specific application areas. Builtin complex and non-integer fixed-point arithmetic are about the only things I can think of. But the functional languages are an area Modula-3 doesn't cover. Actually, you can write a lot of code in functional style in Modula-3, including, I think, some polymorphic stuff, but it's syntactically an awfully lot more ponderous than in a traditional functional language. With a true functional language tied into the implementation, we could claim very broad coverage. Mika Nystrom wrote: > Jay writes: > ... >> ---------------------------------------- >>> 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 > ... >>> 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. > > How about in Scheme? I have written/am writing a Scheme interpreter > in Modula-3 that I am happy to release with CM3; it's very easily > extensible (that's sort of the point of it), so one can easily add > low-level features to it as necessary. The system would be > self-contained with that interpreter. Maybe writing scripts in > Scheme is a little "weird"... (but I do it :-) ) > > Mika > From jay.krell at cornell.edu Wed Jan 21 14:37:53 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 21 Jan 2009 13:37:53 +0000 Subject: [M3devel] chosing SIG_SUSPEND? In-Reply-To: References: Message-ID: Solaris at least currently has SIGRTMAX. I want to switch RTSignalC.c to "something" here. I can preserve compat, like #ifdef __sun SIGUSR2 #else.. or..? I could do #ifdef SIGUSR2 #define SIG_SUSPEND SIGUSR2 #elif defined(SIGRTMAX) #define SIG_SUSPEND SIGRTMAX #else #error #endif I'll go with a compatible version for now and you can change it if you want. I'll test on Linux/x86, FreeBSD (AMD64, but hopefully there is gcc -m32), Linux/PPC, Solaris, Cygwin, Darwin/PPC (uh, actually, no, Darwin isn't really relevant, but I'll make sure the result does what is intended.) It looks like SIGRTMAX is a function call on Solaris. This stuff is like broken, right? I mean, there's a small number of signals and there's no arbitration. People just take them over and hope nobody else cares. There's no way to just queue a function call to a thread, in portable/general? Windows has QueueUserAPC or SuspendThread (SuspendThread is dangerous, thread could be doing anything), QueueUserAPC only interrupts at certain times. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Wed, 21 Jan 2009 03:42:01 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] chosing SIG_SUSPEND? > > Choose SIGRTMAX first if defined, then SIGUSR2. I don't thing NSIG-1 > is reliable, but just works on some systems. > > On 21 Jan 2009, at 01:12, Jay wrote: > >> >> What is the algorithm for chosing SIG_SUSPEND? >> >> Something like: >> >> #include >> >> #ifdef __APPLE__ >> /* nothing -- SIG_SUSPEND not used */ >> #elif defined(NSIG) >> #define SIG_SUSPEND (NSIG - 1) >> #elif defined(_NSIG) >> #define SIG_SUSPEND (_NSIG - 1) >> #elif defined(SIGRTMAX) >> #define SIG_SUSPEND SIGRTMAX >> #else >> #define SIG_SUSPEND SIGUSR2 >> #endif >> >> ? >> >> Whatever it is, I think it should be in RTSignalC.c. >> >> - Jay > From jay.krell at cornell.edu Wed Jan 21 15:37:53 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 21 Jan 2009 14:37:53 +0000 Subject: [M3devel] FW: chosing SIG_SUSPEND? In-Reply-To: References: Message-ID: [truncated again] I'm almost done with this change..just trying to decide to put the constants in a new runtime/common/RTConstants.c or the existing unix/common/Uconstants.c. At first I had them in thread/PTHREAD/ThreadPThreadC.c, but that isn't compiled on user-thread only platforms. :( - Jay ---------------------------------------- > From: jay > To: hosking > CC: m3devel > Subject: RE: [M3devel] chosing SIG_SUSPEND? > Date: Wed, 21 Jan 2009 13:37:53 +0000 > > > Solaris at least currently has SIGRTMAX. > I want to switch RTSignalC.c to "something" here. > I can preserve compat, like > > #ifdef __sun > SIGUSR2 > #else.. > > or..? > > I could do > #ifdef SIGUSR2 > #define SIG_SUSPEND SIGUSR2 > #elif defined(SIGRTMAX) > #define SIG_SUSPEND SIGRTMAX > #else > #error > #endif > > I'll go with a compatible version for now and you can change it if you want. > I'll test on Linux/x86, FreeBSD (AMD64, but hopefully there is gcc -m32), > Linux/PPC, Solaris, Cygwin, Darwin/PPC (uh, actually, no, Darwin isn't > really relevant, but I'll make sure the result does what is intended.) > > It looks like SIGRTMAX is a function call on Solaris. > > This stuff is like broken, right? > I mean, there's a small number of signals and there's no arbitration. > People just take them over and hope nobody else cares. > > > There's no way to just queue a function call to a thread, in portable/general? > Windows has QueueUserAPC or SuspendThread (SuspendThread is dangerous, > thread could be doing anything), QueueUserAPC only interrupts at certain times. > > > - Jay > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Wed, 21 Jan 2009 03:42:01 +1100 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] chosing SIG_SUSPEND? >> >> Choose SIGRTMAX first if defined, then SIGUSR2. I don't thing NSIG-1 >> is reliable, but just works on some systems. >> >> On 21 Jan 2009, at 01:12, Jay wrote: >> >>> >>> What is the algorithm for chosing SIG_SUSPEND? >>> >>> Something like: >>> >>> #include >>> >>> #ifdef __APPLE__ >>> /* nothing -- SIG_SUSPEND not used */ >>> #elif defined(NSIG) >>> #define SIG_SUSPEND (NSIG - 1) >>> #elif defined(_NSIG) >>> #define SIG_SUSPEND (_NSIG - 1) >>> #elif defined(SIGRTMAX) >>> #define SIG_SUSPEND SIGRTMAX >>> #else >>> #define SIG_SUSPEND SIGUSR2 >>> #endif >>> >>> ? >>> >>> Whatever it is, I think it should be in RTSignalC.c. >>> >>> - Jay >> From jay.krell at cornell.edu Wed Jan 21 15:48:26 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 21 Jan 2009 14:48:26 +0000 Subject: [M3devel] FW: chosing SIG_SUSPEND? In-Reply-To: References: Message-ID: Oh partially nevermind -- user threads doesn't use SIG_SUSPEND. SIG_SUSPEND will go away and ThreadPThreadC.c will define SIG, which will be used by it and ThreadPThread.i3. No RTConstants.c, no change in Uconstants.c. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Date: Wed, 21 Jan 2009 14:37:53 +0000 > Subject: [M3devel] FW: chosing SIG_SUSPEND? > > > [truncated again] > > > I'm almost done with this change..just trying to decide > to put the constants in a new runtime/common/RTConstants.c > or the existing unix/common/Uconstants.c. > > At first I had them in thread/PTHREAD/ThreadPThreadC.c, > but that isn't compiled on user-thread only platforms. :( > > - Jay > > ---------------------------------------- >> From: jay >> To: hosking >> CC: m3devel >> Subject: RE: [M3devel] chosing SIG_SUSPEND? >> Date: Wed, 21 Jan 2009 13:37:53 +0000 >> >> >> Solaris at least currently has SIGRTMAX. >> I want to switch RTSignalC.c to "something" here. >> I can preserve compat, like >> >> #ifdef __sun >> SIGUSR2 >> #else.. >> >> or..? >> >> I could do >> #ifdef SIGUSR2 >> #define SIG_SUSPEND SIGUSR2 >> #elif defined(SIGRTMAX) >> #define SIG_SUSPEND SIGRTMAX >> #else >> #error >> #endif >> >> I'll go with a compatible version for now and you can change it if you want. >> I'll test on Linux/x86, FreeBSD (AMD64, but hopefully there is gcc -m32), >> Linux/PPC, Solaris, Cygwin, Darwin/PPC (uh, actually, no, Darwin isn't >> really relevant, but I'll make sure the result does what is intended.) >> >> It looks like SIGRTMAX is a function call on Solaris. >> >> This stuff is like broken, right? >> I mean, there's a small number of signals and there's no arbitration. >> People just take them over and hope nobody else cares. >> >> >> There's no way to just queue a function call to a thread, in portable/general? >> Windows has QueueUserAPC or SuspendThread (SuspendThread is dangerous, >> thread could be doing anything), QueueUserAPC only interrupts at certain times. >> >> >> - Jay >> >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Wed, 21 Jan 2009 03:42:01 +1100 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] chosing SIG_SUSPEND? >>> >>> Choose SIGRTMAX first if defined, then SIGUSR2. I don't thing NSIG-1 >>> is reliable, but just works on some systems. >>> >>> On 21 Jan 2009, at 01:12, Jay wrote: >>> >>>> >>>> What is the algorithm for chosing SIG_SUSPEND? >>>> >>>> Something like: >>>> >>>> #include >>>> >>>> #ifdef __APPLE__ >>>> /* nothing -- SIG_SUSPEND not used */ >>>> #elif defined(NSIG) >>>> #define SIG_SUSPEND (NSIG - 1) >>>> #elif defined(_NSIG) >>>> #define SIG_SUSPEND (_NSIG - 1) >>>> #elif defined(SIGRTMAX) >>>> #define SIG_SUSPEND SIGRTMAX >>>> #else >>>> #define SIG_SUSPEND SIGUSR2 >>>> #endif >>>> >>>> ? >>>> >>>> Whatever it is, I think it should be in RTSignalC.c. >>>> >>>> - Jay >>> From wagner at elegosoft.com Wed Jan 21 15:49:36 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 21 Jan 2009 15:49:36 +0100 Subject: [M3devel] ship vs. where build outputs go, etc.? In-Reply-To: References: <4974CB61.1E75.00D7.1@scires.com> <4975BE3A.1E75.00D7.1@scires.com> Message-ID: <20090121154936.64zgzaj280g884o0@mail.elegosoft.com> Quoting Jay : > > The point is it would not always be the "public" repositoy. > > > Today we have two places, the source tree and the repository. > They have different structures. > > > Instead, you could just have multiple repositories. > They would all have the same structure. > > > "Install" or "ship" is just recursive copy from a "private" > repository to the "public" repository, instead of > arbitrary rearrangement of files. This does only work reliably if you keep exact version info for all files in the derived package pools (I'd like to reserve the term repository for source repository). A repository contains the source code (complete with history), while package pools contain derived files (intermediate results). A third (complementing) notion would be a deployable package (an installable archive or package). CM3 checks the consistency of one build wrt. a package pool and allows shipping into this pool only if everything is OK. Thus any override must inhibit any shipping, as it is not guaranteed that the overriden packages are available in the pool (in this version). If you ship packages from one pool to the other, there is no consistency check at all, unless you know exactly what versions of packages are in both pools. > OR merely "blessing" a private repository and making it the new > public repository, such as by setting and an environment variable > or possibly delete/rename. > > You could get something closer to the current experience by having > two environment variables, CM3_PUBLIC, CM3_PRIVATE. > cm3 -buildship would output to CM3_PUBLIC. > cm3 -build would output to CM3_PRIVATE. > Ideally it would do no extra writes vs. the current scheme. I've got no problem with multiple package pools, but we need to consider carefully what operations will be needed and which ones are safe. > "Upgrade" would look like: > > set CM3_PRIVATE= some new temporary place > build everything > if successful > rm -rf CM3_PUBLIC > mv CM3_PUBLIC CM3_PRIVATE > > See, today "upgrade" writes over the live system and is therefore > "dangerous". In this new scheme, "ship" would lose much of its > danger. Rather than making changes as it goes, the final "commit" > would not occur until the end, and would be easier to keep backups > and such. Granted, if you look at what make-dist does, this is > already possible today, by twiddling with CM3_INSTALL and always > shipping. Though that costs extra I/O and you do have to prepopulate > CM3_INSTALL..at least with a compiler, eh, just two files. > Also with m3core/libm3 in some bootstrapping scenarios. > (make-dist assumes so, though it usually is not the case). You mix concepts from the base CM3 builder with concepts from the maintenance scripts. I never intended these scripts to be used as a general build system for the everyday M3 user. Indeed it does not keep any of the guarantees that M3 gives. > Along with an alternate root for intermediate outputs, this would > enable multiple concurrent builds as well. > > A similar proposal is that "CM3_PUBLIC" could be colon or semicolon > delimited -- a "search path" for reads, write to the first location. > This would probably be confusing if it contained more than two paths though. > publlic/private is "limited" in that it only supports two, but you can > always use recursive copy to merge. I could imagine the following extensions (without deep consideration of the consequences): o allow to ship to more than one package pool (but keep it consistent with the builds) o allow multiple package pools for imports (e.g. by using a package pool path) o allow shipping only if all imports come from the destination package pool (as it is now) > Fixing clean would not take away realclean as an option if that is necessary > for compat (I forget if compiler even implements realclean; the scripts > implement it and I always use that version). I find it hard to believe > that anyone depends on that clean leaves a few files around. > Which files does it even leave around? > > I'm not sure what is documented or not. Could be that a lot is? cm3 -clean should be correct insofar as it removes all derived files (that the compiler knows of). It only works if all imports can be found, which also means that cleaning must be done in the correct order. As the builder currently doesn't work on package sets but only on one package this turns out to be little useful for large projects. Thus the maintenance scripts introduced the realclean command. Again, this was not intended as a general end user solution. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Wed Jan 21 15:42:38 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 21 Jan 2009 09:42:38 -0500 Subject: [M3devel] chosing SIG_SUSPEND? In-Reply-To: References: Message-ID: <46D5FC1C-7F28-4C9B-83CD-8FE0E4290A56@cs.purdue.edu> Yes, we want a signal no-one else is using to stop the threads. On 21 Jan 2009, at 08:37, Jay wrote: > > Solaris at least currently has SIGRTMAX. > I want to switch RTSignalC.c to "something" here. > I can preserve compat, like > > #ifdef __sun > SIGUSR2 > #else.. > > or..? > > I could do > #ifdef SIGUSR2 > #define SIG_SUSPEND SIGUSR2 > #elif defined(SIGRTMAX) > #define SIG_SUSPEND SIGRTMAX > #else > #error > #endif > > I'll go with a compatible version for now and you can change it if > you want. > I'll test on Linux/x86, FreeBSD (AMD64, but hopefully there is gcc - > m32), > Linux/PPC, Solaris, Cygwin, Darwin/PPC (uh, actually, no, Darwin isn't > really relevant, but I'll make sure the result does what is intended.) > > It looks like SIGRTMAX is a function call on Solaris. > > This stuff is like broken, right? > I mean, there's a small number of signals and there's no arbitration. > People just take them over and hope nobody else cares. > > > There's no way to just queue a function call to a thread, in > portable/general? > Windows has QueueUserAPC or SuspendThread (SuspendThread is dangerous, > thread could be doing anything), QueueUserAPC only interrupts at > certain times. > > > - Jay > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Wed, 21 Jan 2009 03:42:01 +1100 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] chosing SIG_SUSPEND? >> >> Choose SIGRTMAX first if defined, then SIGUSR2. I don't thing NSIG-1 >> is reliable, but just works on some systems. >> >> On 21 Jan 2009, at 01:12, Jay wrote: >> >>> >>> What is the algorithm for chosing SIG_SUSPEND? >>> >>> Something like: >>> >>> #include >>> >>> #ifdef __APPLE__ >>> /* nothing -- SIG_SUSPEND not used */ >>> #elif defined(NSIG) >>> #define SIG_SUSPEND (NSIG - 1) >>> #elif defined(_NSIG) >>> #define SIG_SUSPEND (_NSIG - 1) >>> #elif defined(SIGRTMAX) >>> #define SIG_SUSPEND SIGRTMAX >>> #else >>> #define SIG_SUSPEND SIGUSR2 >>> #endif >>> >>> ? >>> >>> Whatever it is, I think it should be in RTSignalC.c. >>> >>> - 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: [M3devel] m3commit not working? Message-ID: I'm not seeing m3commit mail. - Jay From jay.krell at cornell.edu Thu Jan 22 02:19:43 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 22 Jan 2009 01:19:43 +0000 Subject: [M3devel] dependency on platform list removed Message-ID: I removed the dependency libm3 had on the list of platforms that the compiler has. This should make the system easier to build. You'll no longer get the error about SocketPosix and Compiler disagreeing. I thought m3core had a dependency that would harder to remove but I'm not sure. The SOLgnu Tinderbox had been failing due to this dependency but about the time I made the change, it started succeeding. (I thought Tinderbox ran "upgrade.sh" first, which gets around this.) Removing the dependency should actually be a /little/ more efficient as well, not noticably. A bunch of unused strings are removed from libm3. Even the ones remaining are a dubious error fallback. This could be viewed as a bad thing, since before there was a "check" that you had things up to date. Now more mixes can be used, for better or worse. - Jay From jay.krell at cornell.edu Thu Jan 22 02:34:38 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 22 Jan 2009 01:34:38 +0000 Subject: [M3devel] chosing SIG_SUSPEND? In-Reply-To: <46D5FC1C-7F28-4C9B-83CD-8FE0E4290A56@cs.purdue.edu> References: <46D5FC1C-7F28-4C9B-83CD-8FE0E4290A56@cs.purdue.edu> Message-ID: The code is now: #define SIG_SUSPEND ThreadPThreadC_SIG_SUSPEND /* expected values for compat, if compat matters: Solaris: 17 (at least 32bit SPARC?) Cygwin: 19 -- er, but maybe that's wrong Linux: 64 FreeBSD: 31 OpenBSD: 31 HPUX: 44 Look at the history of Usignal and RTMachine to find more values. There was RTMachine.SIG_SUSPEND and SIG was aliased to it. Both SIG and SIG_SUSPEND were only defined for systems using pthreads. SIG was shorthand. */ #if defined(__APPLE__) const int SIG_SUSPEND = 0; #elif defined(__sun) || defined(__CYGWIN__) || defined(__FreeBSD__) const int SIG_SUSPEND = SIGUSR2; #elif defined(__linux) const int SIG_SUSPEND = NSIG - 1; #elif defined(SIGRTMAX) /* This might be a function call, in which case try _SIGRTMAX or initializing it somewhere. */ const int SIG_SUSPEND = SIGRTMAX; #elif defined(SIGUSR2) const int SIG_SUSPEND = SIGUSR2; #else #error Unable to determine SIG_SUSPEND. #endif Compatible but perhaps not ideal. It'll automatically port to "something" now, less per-machine work. The #ifdefs are overly broad, since __sun and __FreeBSD__ will cover more than just older platforms but also newer ones -- need to check processor. "SIG" is gone, it was private and I think merely "shorthand", not important. Uses say SIG_SUSPEND. SIG_SUSPEND gone from RTMachine.i3 and in ThreadPThreadC.{c,i3} - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Wed, 21 Jan 2009 09:42:38 -0500 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] chosing SIG_SUSPEND? > > Yes, we want a signal no-one else is using to stop the threads. > > On 21 Jan 2009, at 08:37, Jay wrote: > >> >> Solaris at least currently has SIGRTMAX. >> I want to switch RTSignalC.c to "something" here. >> I can preserve compat, like >> >> #ifdef __sun >> SIGUSR2 >> #else.. >> >> or..? >> >> I could do >> #ifdef SIGUSR2 >> #define SIG_SUSPEND SIGUSR2 >> #elif defined(SIGRTMAX) >> #define SIG_SUSPEND SIGRTMAX >> #else >> #error >> #endif >> >> I'll go with a compatible version for now and you can change it if >> you want. >> I'll test on Linux/x86, FreeBSD (AMD64, but hopefully there is gcc - >> m32), >> Linux/PPC, Solaris, Cygwin, Darwin/PPC (uh, actually, no, Darwin isn't >> really relevant, but I'll make sure the result does what is intended.) >> >> It looks like SIGRTMAX is a function call on Solaris. >> >> This stuff is like broken, right? >> I mean, there's a small number of signals and there's no arbitration. >> People just take them over and hope nobody else cares. >> >> >> There's no way to just queue a function call to a thread, in >> portable/general? >> Windows has QueueUserAPC or SuspendThread (SuspendThread is dangerous, >> thread could be doing anything), QueueUserAPC only interrupts at >> certain times. >> >> >> - Jay >> >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Wed, 21 Jan 2009 03:42:01 +1100 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] chosing SIG_SUSPEND? >>> >>> Choose SIGRTMAX first if defined, then SIGUSR2. I don't thing NSIG-1 >>> is reliable, but just works on some systems. >>> >>> On 21 Jan 2009, at 01:12, Jay wrote: >>> >>>> >>>> What is the algorithm for chosing SIG_SUSPEND? >>>> >>>> Something like: >>>> >>>> #include >>>> >>>> #ifdef __APPLE__ >>>> /* nothing -- SIG_SUSPEND not used */ >>>> #elif defined(NSIG) >>>> #define SIG_SUSPEND (NSIG - 1) >>>> #elif defined(_NSIG) >>>> #define SIG_SUSPEND (_NSIG - 1) >>>> #elif defined(SIGRTMAX) >>>> #define SIG_SUSPEND SIGRTMAX >>>> #else >>>> #define SIG_SUSPEND SIGUSR2 >>>> #endif >>>> >>>> ? >>>> >>>> Whatever it is, I think it should be in RTSignalC.c. >>>> >>>> - Jay >>> > 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: [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: [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 jay.krell at cornell.edu Fri Jan 23 08:09:40 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 23 Jan 2009 07:09:40 +0000 Subject: [M3devel] chosing SIG_SUSPEND? In-Reply-To: <46D5FC1C-7F28-4C9B-83CD-8FE0E4290A56@cs.purdue.edu> References: <46D5FC1C-7F28-4C9B-83CD-8FE0E4290A56@cs.purdue.edu> Message-ID: I noticed in some of the code..I think for SegV, Quit,etc., not for thread suspension, that if the signalis already set to other than SIG_DFL, Modula-3 refrainsfrom changing it. So, I was thinking, would it be reasonable to iterate through, saySIGUSR1, SIGUSR2, and SIGRTMIN through SIGRTMAX, anduse the "first" one that isn't set to SIG_DFL?By "first", I don't mean to imply what order to check in,probably my statement has the order backwards.The point is to check them and not just hijack them. OR, is there another way to do this? Doesn't or can't the Modula-3 code "check a flag""every so often" and then voluntarily yield?Of course, the allocator would check the flag. Perhaps I just really need to get "that paper" into my head?Understand the issue around "other threads running intight computation loops for a long time", and therefore not checkingon yielding? Is the signal mechanism actually preemptive anyway? - Jay> From: hosking at cs.purdue.edu> To: jay.krell at cornell.edu> Date: Wed, 21 Jan 2009 09:42:38 -0500> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] chosing SIG_SUSPEND?> > Yes, we want a signal no-one else is using to stop the threads.> > On 21 Jan 2009, at 08:37, Jay wrote:> > >> > Solaris at least currently has SIGRTMAX.> > I want to switch RTSignalC.c to "something" here.> > I can preserve compat, like> >> > #ifdef __sun> > SIGUSR2> > #else..> >> > or..?> >> > I could do> > #ifdef SIGUSR2> > #define SIG_SUSPEND SIGUSR2> > #elif defined(SIGRTMAX)> > #define SIG_SUSPEND SIGRTMAX> > #else> > #error> > #endif> >> > I'll go with a compatible version for now and you can change it if > > you want.> > I'll test on Linux/x86, FreeBSD (AMD64, but hopefully there is gcc - > > m32),> > Linux/PPC, Solaris, Cygwin, Darwin/PPC (uh, actually, no, Darwin isn't> > really relevant, but I'll make sure the result does what is intended.)> >> > It looks like SIGRTMAX is a function call on Solaris.> >> > This stuff is like broken, right?> > I mean, there's a small number of signals and there's no arbitration.> > People just take them over and hope nobody else cares.> >> >> > There's no way to just queue a function call to a thread, in > > portable/general?> > Windows has QueueUserAPC or SuspendThread (SuspendThread is dangerous,> > thread could be doing anything), QueueUserAPC only interrupts at > > certain times.> >> >> > - Jay> >> >> > ----------------------------------------> >> From: hosking at cs.purdue.edu> >> To: jay.krell at cornell.edu> >> Date: Wed, 21 Jan 2009 03:42:01 +1100> >> CC: m3devel at elegosoft.com> >> Subject: Re: [M3devel] chosing SIG_SUSPEND?> >>> >> Choose SIGRTMAX first if defined, then SIGUSR2. I don't thing NSIG-1> >> is reliable, but just works on some systems.> >>> >> On 21 Jan 2009, at 01:12, Jay wrote:> >>> >>>> >>> What is the algorithm for chosing SIG_SUSPEND?> >>>> >>> Something like:> >>>> >>> #include> >>>> >>> #ifdef __APPLE__> >>> /* nothing -- SIG_SUSPEND not used */> >>> #elif defined(NSIG)> >>> #define SIG_SUSPEND (NSIG - 1)> >>> #elif defined(_NSIG)> >>> #define SIG_SUSPEND (_NSIG - 1)> >>> #elif defined(SIGRTMAX)> >>> #define SIG_SUSPEND SIGRTMAX> >>> #else> >>> #define SIG_SUSPEND SIGUSR2> >>> #endif> >>>> >>> ?> >>>> >>> Whatever it is, I think it should be in RTSignalC.c.> >>>> >>> - Jay> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Jan 23 14:27:39 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 23 Jan 2009 08:27:39 -0500 Subject: [M3devel] chosing SIG_SUSPEND? In-Reply-To: References: <46D5FC1C-7F28-4C9B-83CD-8FE0E4290A56@cs.purdue.edu> Message-ID: On 23 Jan 2009, at 02:09, Jay wrote: > I noticed in some of the code..I think for SegV, Quit, > etc., not for thread suspension, that if the signal > is already set to other than SIG_DFL, Modula-3 refrains > from changing it. > > So, I was thinking, would it be reasonable to iterate through, say > SIGUSR1, SIGUSR2, and SIGRTMIN through SIGRTMAX, and > use the "first" one that isn't set to SIG_DFL? > By "first", I don't mean to imply what order to check in, > probably my statement has the order backwards. > The point is to check them and not just hijack them. Maybe. I would argue the opposite: that M3 apps that use signals should avoid using the one dedicated to thread suspension. > OR, is there another way to do this? > > Doesn't or can't the Modula-3 code "check a flag" > "every so often" and then voluntarily yield? > Of course, the allocator would check the flag. This is a reasonable approach for Modula-3-compiled code: the polling points are called GC-safe-points. You just need to insert poll-points on backward branches and calls. The real problem is stopping threads that are off in native code and system calls. We could wrap every native call with a code to save GC-relevant state before going native, and then check the flag on return from native in case a GC is in progress. Many Java implementations use that approach. > Perhaps I just really need to get "that paper" into my head? > Understand the issue around "other threads running in > tight computation loops for a long time", and therefore not checking > on yielding? > > Is the signal mechanism actually preemptive anyway? Preemptive in what sense? Depending on the OS, signals tend to get delivered at system calls or thread context-switches. > > > - Jay > > > > > > > > From: hosking at cs.purdue.edu > > To: jay.krell at cornell.edu > > Date: Wed, 21 Jan 2009 09:42:38 -0500 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] chosing SIG_SUSPEND? > > > > Yes, we want a signal no-one else is using to stop the threads. > > > > On 21 Jan 2009, at 08:37, Jay wrote: > > > > > > > > Solaris at least currently has SIGRTMAX. > > > I want to switch RTSignalC.c to "something" here. > > > I can preserve compat, like > > > > > > #ifdef __sun > > > SIGUSR2 > > > #else.. > > > > > > or..? > > > > > > I could do > > > #ifdef SIGUSR2 > > > #define SIG_SUSPEND SIGUSR2 > > > #elif defined(SIGRTMAX) > > > #define SIG_SUSPEND SIGRTMAX > > > #else > > > #error > > > #endif > > > > > > I'll go with a compatible version for now and you can change it if > > > you want. > > > I'll test on Linux/x86, FreeBSD (AMD64, but hopefully there is > gcc - > > > m32), > > > Linux/PPC, Solaris, Cygwin, Darwin/PPC (uh, actually, no, Darwin > isn't > > > really relevant, but I'll make sure the result does what is > intended.) > > > > > > It looks like SIGRTMAX is a function call on Solaris. > > > > > > This stuff is like broken, right? > > > I mean, there's a small number of signals and there's no > arbitration. > > > People just take them over and hope nobody else cares. > > > > > > > > > There's no way to just queue a function call to a thread, in > > > portable/general? > > > Windows has QueueUserAPC or SuspendThread (SuspendThread is > dangerous, > > > thread could be doing anything), QueueUserAPC only interrupts at > > > certain times. > > > > > > > > > - Jay > > > > > > > > > ---------------------------------------- > > >> From: hosking at cs.purdue.edu > > >> To: jay.krell at cornell.edu > > >> Date: Wed, 21 Jan 2009 03:42:01 +1100 > > >> CC: m3devel at elegosoft.com > > >> Subject: Re: [M3devel] chosing SIG_SUSPEND? > > >> > > >> Choose SIGRTMAX first if defined, then SIGUSR2. I don't thing > NSIG-1 > > >> is reliable, but just works on some systems. > > >> > > >> On 21 Jan 2009, at 01:12, Jay wrote: > > >> > > >>> > > >>> What is the algorithm for chosing SIG_SUSPEND? > > >>> > > >>> Something like: > > >>> > > >>> #include > > >>> > > >>> #ifdef __APPLE__ > > >>> /* nothing -- SIG_SUSPEND not used */ > > >>> #elif defined(NSIG) > > >>> #define SIG_SUSPEND (NSIG - 1) > > >>> #elif defined(_NSIG) > > >>> #define SIG_SUSPEND (_NSIG - 1) > > >>> #elif defined(SIGRTMAX) > > >>> #define SIG_SUSPEND SIGRTMAX > > >>> #else > > >>> #define SIG_SUSPEND SIGUSR2 > > >>> #endif > > >>> > > >>> ? > > >>> > > >>> Whatever it is, I think it should be in RTSignalC.c. > > >>> > > >>> - Jay > > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Fri Jan 23 15:01:49 2009 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 23 Jan 2009 06:01:49 -0800 Subject: [M3devel] chosing SIG_SUSPEND? In-Reply-To: Your message of "Fri, 23 Jan 2009 08:27:39 EST." Message-ID: <200901231401.n0NE1ngq007378@camembert.async.caltech.edu> Tony Hosking writes: > ... >> probably my statement has the order backwards. >> The point is to check them and not just hijack them. > >Maybe. I would argue the opposite: that M3 apps that use signals >should avoid using the one dedicated to thread suspension. I agree! Signals are not the Modula-3 Way. Something you mess with only when you're trying to interface with C code that hasn't heard of "threads". Yuck. ... >> Is the signal mechanism actually preemptive anyway? > >Preemptive in what sense? Depending on the OS, signals tend to get >delivered at system calls or thread context-switches. Isn't the whole point of signals to interrupt a computation...? ctrl-C, ctrl-Z, ctrl-\, SIGALRM, etc.... Mika From rcoleburn at scires.com Mon Jan 26 01:43:27 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 25 Jan 2009 19:43:27 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20090125163615.DABA3904003@birch.elegosoft.com> References: <20090125163615.DABA3904003@birch.elegosoft.com> Message-ID: <497CC069.1E75.00D7.1@scires.com> Jay: Please explain what you are doing here. I don't want to break stuff just to make extremely old and no longer supported toolsets work. My recollection is that the cvtres program is used in getting icon resources et al added to the executable. I know that the CM3IDE package is dependent on the WindowsResources package as are a lot of my programs. If you make changes here, we need to make sure it doesn't break existing stuff. Also, if there is a better way to go about it, I don't mind learning, but we will need to deal with making everything that depends on windowsResources continue to work. Regards, Randy >>> Jay Krell 1/25/2009 5:36 PM >>> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jan 26 02:50:35 2009 From: jay.krell at cornell.edu (Jay) Date: Mon, 26 Jan 2009 01:50:35 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <497CC069.1E75.00D7.1@scires.com> References: <20090125163615.DABA3904003@birch.elegosoft.com> <497CC069.1E75.00D7.1@scires.com> Message-ID: There is never any need to run cvtres. I have never seen anyone do this. You just pass the .res file to the linker and it works. I would turn things around and ask why it was written this way in the first place, different than all other systems? I can imagine one very marginal very minor point. If the .res file is linked into multiple executables, there might be microscropic build perf win in running cvtres once. I would like further simplification here but I didn't do the research needed. In particular, I don't think clients should have to say if equal (TARGET, "WIN32"). The Quake code already does that, but you'd have to make sure the package is shipped for all platforms so they have the .tmpl file. - Jay _______________________________ > Date: Sun, 25 Jan 2009 19:43:27 -0500 > From: rcoleburn at scires.com > To: jkrell at elego.de; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Jay: > > > > Please explain what you are doing here. I don't want to break stuff just to make extremely old and no longer supported toolsets work. > > > > My recollection is that the cvtres program is used in getting icon resources et al added to the executable. I know that the CM3IDE package is dependent on the WindowsResources package as are a lot of my programs. If you make changes here, we need to make sure it doesn't break existing stuff. > > > > Also, if there is a better way to go about it, I don't mind learning, but we will need to deal with making everything that depends on windowsResources continue to work. > > > > Regards, > > Randy > >>>> Jay Krell 1/25/2009 5:36 PM>>> > 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 jay.krell at cornell.edu Wed Jan 28 15:37:20 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 28 Jan 2009 14:37:20 +0000 Subject: [M3devel] gratuitous platform differences? Message-ID: I'm looking to add user thread support to the stuff I'm working on. As part of this, I'm surveying various platform-specific code, to find the commonality. Some of this should be common Modula-3 code. Where there are dealings with struct sigaction or sigset_t, the code should be rewritten in C to avoid requiring other additional platform-dependent code. It seems to me that many of the differences are gratuitous. Here are two: - some platforms unmap, or at least take away write access, to the last page in the stack; and then remap it (or add back write access) before disposing Now, I'm not going to move all ports to "my rewritten headers", just ones that I can test and are "somewhat active". In this case, I think that leads to all platforms being the same. So the question of "why not always do this?" doesn't matter. - Regarding disallow_sigvtalrm, allow_sigvtalrm, some platforms initialize the mask in the module's initializer, some recreate it for every call. Is there a reason for this? Creating it once is faster. But does require the initializer run early enough. And one would hope that the cached struct isn't too huge and memory wasting. To be safe, I could just provide two versions here, one that makes the mask over and over, one that does not. - Jay From jay.krell at cornell.edu Wed Jan 28 15:57:17 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 28 Jan 2009 14:57:17 +0000 Subject: [M3devel] sigbus? Message-ID: Here is something very suspicious, that I find by comparing similar platform-specific code to other similar platforms, trying to find what needs to be forked or #ifdefed per-platfform and why: All the Darwin ports, and no other ports, have: C:\dev2\cm3.2\m3-libs\m3core\src\runtime\AMD64_DARWIN\RTSignal.m3(34): SetHandler (6, Usignal.SIGBUS, SegV); but none of them do anything with SIGBUS in RestoreHandlers. - It must be a mistake to not RestoreHandler, right? - Either all of the ports should handle SIGBUS, or none of them, right? At least if all the underlying platforms define it? Granted, no x86 or AMD64 platform is likely to ever issue it, but maybe for, like, using sse or cmpxchg 8b? - Jay From jay.krell at cornell.edu Wed Jan 28 16:56:42 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 28 Jan 2009 15:56:42 +0000 Subject: [M3devel] gratuitous platform differences? In-Reply-To: References: Message-ID: Another difference is that some platforms set the last page of the stack to be PROT_NONE, while others use PROT_READ, with a comment: (* The protection should be 0, but making the page read-only is good enough to prevent unchecked runtime errors *) except ALPHA_OSF says: (* The protection should be 0, but a bug in MIPS/Ultrix 4.2 (vmdup) causes kernel panics when it is. Making the page read-only is good enough to prevent unchecked runtime errors *) Also, whenever calling Usignal stuff, there are three styles i := Usignal.something() WITH i = Usignal.something() DO END; EVAL Usignal.something() It COULD be that the functions fail on some platforms and EVAL is used to ignore the result. I favor the first style -- I find that code should avoid indentation in general -- given a choice between an if/else and if/continue, I'll use if/continue, adding a local variable or using WITH, add a local variable. Etc. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Wed, 28 Jan 2009 14:37:20 +0000 > Subject: [M3devel] gratuitous platform differences? > > > I'm looking to add user thread support to the stuff I'm working on. > As part of this, I'm surveying various platform-specific code, > to find the commonality. > Some of this should be common Modula-3 code. > Where there are dealings with struct sigaction or sigset_t, the > code should be rewritten in C to avoid requiring other additional > platform-dependent code. > > > It seems to me that many of the differences are gratuitous. > > > Here are two: > > > - some platforms unmap, or at least take away write access, to the > last page in the stack; and then remap it (or add back write access) > before disposing > Now, I'm not going to move all ports to "my rewritten headers", > just ones that I can test and are "somewhat active". > In this case, I think that leads to all platforms being the same. > So the question of "why not always do this?" doesn't matter. > > > - Regarding disallow_sigvtalrm, allow_sigvtalrm, some platforms > initialize the mask in the module's initializer, some recreate it > for every call. > Is there a reason for this? > Creating it once is faster. > But does require the initializer run early enough. > And one would hope that the cached struct isn't too huge and memory wasting. > > > To be safe, I could just provide two versions here, one that makes the mask > over and over, one that does not. > > > - Jay From jay.krell at cornell.edu Wed Jan 28 17:04:34 2009 From: jay.krell at cornell.edu (Jay) Date: Wed, 28 Jan 2009 16:04:34 +0000 Subject: [M3devel] gratuitous platform differences? In-Reply-To: References: Message-ID: (There is an ASSERT in two of the styles, but it apparently got removed by some buggy mail software in the stack..) - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Wed, 28 Jan 2009 15:56:42 +0000 > Subject: Re: [M3devel] gratuitous platform differences? > > > Another difference is that some platforms set the last page of the stack to be PROT_NONE, while others use PROT_READ, with a comment: > > (* The protection should be 0, but making the page read-only > is good enough to prevent unchecked runtime errors *) > > except ALPHA_OSF says: > > (* The protection should be 0, but a bug in MIPS/Ultrix 4.2 (vmdup) > causes kernel panics when it is. Making the page read-only > is good enough to prevent unchecked runtime errors *) > > Also, whenever calling Usignal stuff, there are three styles > > i := Usignal.something() > > > > WITH i = Usignal.something() DO > > END; > > > EVAL Usignal.something() > > > > It COULD be that the functions fail on some platforms and EVAL is used to ignore the result. > I favor the first style -- I find that code should avoid indentation in general -- given a choice between an if/else and if/continue, I'll use if/continue, adding a local variable or using WITH, add a local variable. Etc. > > > - Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Wed, 28 Jan 2009 14:37:20 +0000 >> Subject: [M3devel] gratuitous platform differences? >> >> >> I'm looking to add user thread support to the stuff I'm working on. >> As part of this, I'm surveying various platform-specific code, >> to find the commonality. >> Some of this should be common Modula-3 code. >> Where there are dealings with struct sigaction or sigset_t, the >> code should be rewritten in C to avoid requiring other additional >> platform-dependent code. >> >> >> It seems to me that many of the differences are gratuitous. >> >> >> Here are two: >> >> >> - some platforms unmap, or at least take away write access, to the >> last page in the stack; and then remap it (or add back write access) >> before disposing >> Now, I'm not going to move all ports to "my rewritten headers", >> just ones that I can test and are "somewhat active". >> In this case, I think that leads to all platforms being the same. >> So the question of "why not always do this?" doesn't matter. >> >> >> - Regarding disallow_sigvtalrm, allow_sigvtalrm, some platforms >> initialize the mask in the module's initializer, some recreate it >> for every call. >> Is there a reason for this? >> Creating it once is faster. >> But does require the initializer run early enough. >> And one would hope that the cached struct isn't too huge and memory wasting. >> >> >> To be safe, I could just provide two versions here, one that makes the mask >> over and over, one that does not. >> >> >> - Jay From jay.krell at cornell.edu Thu Jan 29 18:10:53 2009 From: jay.krell at cornell.edu (Jay) Date: Thu, 29 Jan 2009 17:10:53 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <495B901F.1E75.00D7.1@scires.com> References: <20081231105208.9CF4710D5DDE@birch.elegosoft.com> <495B4846.1E75.00D7.1@scires.com> <495B901F.1E75.00D7.1@scires.com> Message-ID: > In reading your post, you state that you deoptimized the native implementation > to make it match Cygwin. Now, I'm not sure how I was wrong on this point. Cygwin's setjmp.h incorrectly typedefs jmp_buf, indeed, to be much larger than "native", but the header is incorrect. Cygwin actually has a slightly smaller jmp_buf than native (13 ints vs. 16 ints), but we use the native size always, deoptimizing the Cygwin case. - Jay ________________________________ > Date: Wed, 31 Dec 2008 15:30:40 -0500 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > > > > > Jay: > > > > First, I do want to say thanks for all you are doing for the cause of Modula-3. I don't think we say thanks enough for what others do for us. THANK YOU! > > > > I don't want to be perceived as "complaining", rather I am trying to voice my opinion in the hopes of influencing future direction. Of course, since I'm not doing the work, I can only make suggestions. > > > > In reading your post, you state that you deoptimized the native implementation to make it match Cygwin. Now, I'm not sure how much effect this deoptimization has (maybe little), but it is clear that in this case your implementation choice has favored the non-native implementation over the native one. IMO, tradeoffs of this type are not good. If one is trying to convince someone to use Modula-3, why would you want to give them a "deoptimized" version just to make it easier to support a non-native environment---indeed, one that they may not even want/use? If we have to make a trade-off, I say favor the native implementation always over the non-native one. > > > > What I'm trying to say here is that my experience as a software, systems, and program engineer is that I've always been forced to justify the cost/benefit of development tools for any project. Many times I've had to go head to head with folks higher up in my own organization or in the customer's organization whose preconceived opinions were based on rumor and what they've heard rather than actual factual hands-on experience. I want to pick the best tool for the job instead of being forced to pick an inferior tool because someone higher in the food chain demanded it based on faulty preconceived opinion. I like Modula-3. I've found that I am more productive using it. But, if the compiler doesn't produce efficient code, I lose ground in arguing with the higher-ups. > > > > As for Python, I've never ventured to learn it, so for me, it is something of a mystery. But you miss the point. I'm not arguing the merits of Python, I'm just saying that anything Modula-3 requires on top of what is provided by the standard host platform represents a potential obstacle or barrier to ease of use/implementation. It also sends the message that somehow Modula-3 is not complete on its own, we have get Python just to install and oh yes we need a C compiler and a linker and a ...? IMO, ultimately we need a turn-key download and install routine for Modula-3 that just works, out-of-the-box. If you give me an EXE, a CMD, or a BAT, for the install, I can run it on Windows, but if you give me an install routine that requires I first install something else, e.g. Python, then that becomes a barrier to the folks who don't know Python or already have it installed. > > > > Am I alone in this line of thought? If so, I'll just be quiet. > > > > BTW, I can certainly help in maintaining the CMD/BAT install routines or in making a better CMINSTALL. My problem is that right now, it is hard to understand all the dependencies for proper building of cm3 from scratch. Indeed, I've contributed some CMD/BAT install stuff in the past, but it is now out of date. Perhaps if there is a way we could better document the proper build order and dependencies, it would be easier for folks in the community to help in this area. I certainly would volunteer to do the CMD files as long as I had enough information to do it right. At one point, I thought we had a file that showed the package build order and dependencies. Not sure if the format of this file is well-documented or if the file is kept up-to-date. > > > > Regards, > > Randy > > >>>> Jay 12/31/2008 1:34 PM>>> >> you've made the CYGWIN implementation "appear" >> be the same as the native Windows implementation. >> But they are not the same. > > > But they mostly are, from the front end's point of view. > They are both little endian, x86, use the same jump_buf size (I grew it to match Cygwin's, which is a deoptimization of stack use on native NT386), the same type sizes and alignments..er..not sure about LONGINT. > They might vary in newline and one uses the internal backend and one the external, however which backend they use is actually minor to the front end, though I think it affects if the front end "deals with" calling conventions, particularly left-to-right vs. right-to-left and struct returns. > Object code produced by one can generally be linked with object code produced by the other. > > > SOLgnu and SOLsun are a better example of this, though they do go ahead and duplicate tons of stuff that if I had implemented them, I would have avoided. > They are truly identical in every respect in the front end and back end. > They only vary in the config file. > This is wasteful, because, "by default", if I'm put together a comprehensive cross build system without being a little smarter, I end up building two identical m3cgs. My config files are willing to "probe across" SOLsun and SOLgnu though, so I need only one m3cg for the two of them. > > > Given that "NT386" can describe a combinatorial explosion of configurations, it makes some sense to keep it just one if possible. The compiler mostly doesn't care. > > > >> "- BUILD_DIR does not necessarily equal HOST or TARGET, >> because of how I structured I386_CYGWIN to be a "configuration" >> where TARGET is still NT386." > >> IMO, it would be wrong to change the meaning of things like "BUILD_DIR", "HOST", and "TARGET". > > BUILD_DIR also does not equal HOST or TARGET when doing profiled builds, which admittedly I never have. > Therefore, BUILD_DIR is arbitrary. > I might be confusing something here though -- since I have never built a profiled build, I also haven't shipped one. It could be that "shipped BUILD_DIR" does equal TARGET, for profiled builds, in which case I did set a precedent. But the "override" code isn't using shipped files, so.. > I have to check. > >> as long as it does not compromise the native Windows implementation > > Agreed and it basically doesn't. > Show me where it does. > The only thing I can think of is the jmpbuf size. > >> I don't want to have to install CYGWIN either in order to make >> the native implementation work on Windows. > > Please don't complain about stuff that isn't true or without being more specific. > I know of no dependency by the native implementation on Cygwin. > > In fact, installing Cygwin does tend to break the native implementation, depending on $PATH, because it has a link.exe that is a completely different program (ie: ln.exe). > I tried experimenting with using cl to drive link.exe but couldn't quite get it to work, for stupid reasons related to response files, which surely is fixable by extending response file support in cm3... > > As it is, I usually delete \cygwin\bin\link.exe, or remove cygwin from $PATH. > True, I don't ever uninstall Cygwin for testing, so the dependency could creep in by accident. > > >> I also still prefer the CMINSTALL, CMD, or BAT files >> for install as opposed to having to get Python or something else. Just my 2 cents. > > Once built and installed, there is no dependency on cmd, bat, cminstall, or python. > cminstall is pretty worthless imho, as long as you set PATH, INCLUDE, and LIB. > That is also a competing workaround for paths with spaces. > And allows moving around among different versions of Visual C++, which is good and bad. > Either you can have n installs of cm3, each configured tightly for one specific Visual C++, > or you can have 1 install of cm3, that is flexibly configured, that you "reconfigure" by altering the environment. I do the second. > > If you want to build the system, in a well automated way, with cmd and bat, you are welcome to write them. > Maybe the ones I left in the tree work, but i never use them any longer. > I use the Python all the time. > > Or you can manually cd around (as I suspect Tony does). > Personally I find cmd/bat among the worst programming languages ever and would rather not write it. > jscript via cscript.exe would be a good alternative, it is always there at least as of Windows 2000 or perhaps with IE installed on older versions, but then you have to duplicate work across Unix and Windows. > That is, for Windows-only no-cmd, no-install command line automation, JScript and VBScript are good choices, but Windows-only rules them out. The install is worth it. > Python is a very decent programming language that is very portable across "all" systems. > Perl would be the next best choice, though..I just don't like much. > sh/bash requires an install on Windows, so its built-inness on Posix I claim isn't a conclusive win. > I strongly encourage you to try out Python. > > Another avenue is to merge the sh/cmd/python into cm3 itself. > It shouldn't be all that hard. > > Modula-3 still needs a C linker. > And there is C code that I didn't put in -- hand.c and dtoa.c. > If someone writes a linker in Modula-3, or gets the .obj loader working, I'll be more open to eliminating C. > > But using C is much less error prone and much more portable, in some parts of the system. > > You may label C as "evil", but the other "evil" I am battling is tedious error prone "header cloning". > You pretty much must chose one. > The header cloning can be reduced, and its error proned-ness and difficulty various per system, depending on how gnarled up the headers are with ifdefs, compatibility hacks, processor-specificty, "cleansing" (where the installed headers are processor specific, deriving from #ifdef'ed or somesuch other files, but now I argue both sides, #ifdef is hard to read, but removing them removes information unless you track further back), etc. For example the OpenBSD headers are much more readable. I suspect NetBSD are too but haven't looked yet. The Linux headers contain a lot of #ifdef and they are also processor-specific I think -- you know, my /usr/include/errno.h on one system I think didn't show that x86 and SPARC use different values. > > > - Jay > > > > ________________________________ > > > Date: Wed, 31 Dec 2008 10:28:37 -0500 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay: > > > > Please explain what you mean by: > > > > "- BUILD_DIR does not necessarily equal HOST or TARGET, > because of how I structured I386_CYGWIN to be a "configuration" > where TARGET is still NT386." > > > > IMO, it would be wrong to change the meaning of things like "BUILD_DIR", "HOST", and "TARGET". Indeed, I have stuff that depends on the meaning of these things. Your statement seems to imply that "under the covers" you've made the CYGWIN implementation "appear" to be the same as the native Windows implementation. But they are not the same. > > > > On another note, All this CYGWIN stuff may be a nice way for die-hard Unix fans to run Modula-3 on Windows, and I have no objection to providing it, as long as it does not compromise the native Windows implementation. My main concern is the native implementation of Modula-3 on Windows. My preference would be to keep the NT386 implementation's dependencies on other stuff to a bare minimum, i.e., don't introduce anything that would require someone to have to acquire something besides what comes in the standard Windows OS in order to make Modula-3 run. As it is now, we already have to get a C compiler and linker. Fortunately, Microsoft has made the Visual Studio Express editions a free download, so this is not too bad. I don't want to have to install CYGWIN either in order to make the native implementation work on Windows. I also still prefer the CMINSTALL, CMD, or BAT files for install as opposed to having to get Python or something else. Just my 2 cents. > > > > Finally, I would go a step further and suggest that the Modula-3 implementation on every platform should strive to require minimal dependencies on anything not provided standard with that platform's operating system. > > > > Call me an idealist, but it just galls me that I have to have a C compiler/linker to build Modula-3. Modula-3 is a systems programming language. It should stand on its own. From a purely economical viewpoint, why should I have to buy something I don't want (C language development environment) in order to have the privilege of using what I do want (Modula-3 language development environment). > > > > Regards, > > Randy > >>>> Jay Krell 12/31/2008 11:52 AM>>> > CVSROOT:/usr/cvs > Changes by:jkrell at birch.08/12/31 11:52:08 > > Modified files: > cm3/m3-comm/netobj/src/: netobj-ov.tmpl > cm3/m3-comm/sharedobj/src/: sharedobj-ov.tmpl > cm3/m3-libs/libm3/src/bundleintf/: bundle-ov.tmpl > cm3/m3-ui/zeus/src/: m3zume-ov.tmpl > cm3/m3-ui/juno-2/juno-app/src/: m3makefile > > Log message: > Partly kinda sorta fix some cross build scenarios, without > affecting native builds. > > It's a larger more general problem though. > > - BUILD_DIR does not necessarily equal HOST or TARGET, > because of how I structured I386_CYGWIN to be a "configuration" > where TARGET is still NT386. > > - a cross build can run the shipped binary anyway, > and probably should (I didn't have the unshipped binaries around) > > - There should probably be automation to ensure all the tools are build. > ie: do-cm3-tools or do-cm3-crosstools. ie: build just the needed packages, > for the sniffed native platform. > > Cross builds have other problems. > > I keep hitting the following annoyances: > > ignoring foo/bar override when foo\bar already overridden > override paths should either be canonicalized to one slash type > or at least when there is a duplicate, canonicalize then and only > complain if canonicals vary > This is due to mixing I386_NT and I386_CYGWIN. > Similarly the problem demonstrated regarding m3unix.h in Uwaitpid.quake. > > Perhaps the change I made to allow forward slashes on Win32 was not good, esp. due to > its apparent inadequacy. > > The "lib" directory, specifically \cm3\lib\hand.obj is target..er, configuration dependent > the gcc hand.obj cannot be directly linked by Visual C++, for reasons to do with libgcc > > lib should probably have "target" or "build_dir" under it > > and/or hand.obj specifically should be merged into m3core.lib > > The mentor quake code generally fails in cross environments, probably due to slashes. > > host=NT386 (GNU?), target=LINUXLIBC6 m3zume is access violating > > I'm also highly suspicious of all this "override" stuff. > It clearly causes too much duplication and distribution of information. > I shouldn't have to know the directory structure of my dependencies, > and even if I do, I should be able to share that knowledge with their many > other dependents. The "scripts" directory also figures this sort of stuff out automatically.. > Being able to have multiple package stores is well and good. > I'm not sure they need to ever be used in an "unshipped" form, but instead just > use alternate roots and create new empty roots as needed. ? > > From rodney.bates at wichita.edu Thu Jan 29 22:43:37 2009 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 29 Jan 2009 15:43:37 -0600 Subject: [M3devel] Semantics of HasWideChars Message-ID: <49822309.7030407@wichita.edu> CM3's Text.HasWideChars, as implemented, has some strange behavior. From Text.i3: PROCEDURE HasWideChars (t: T): BOOLEAN; (* Returns "TRUE" if "t" contains any "WIDECHAR" characters. *) This reads to me like it refers to the actual characters comprising t, which also makes sense to a client of this interface. In fact, the implementation returns TRUE if the internal representation used is capable of representing any wide characters, even though they could all be narrow. Some examples: Text.HasWideChars(W"ABC") = TRUE Text.HasWideChars(W"ABC"&"def") = TRUE Text.HasWideChars(Text.Sub(W"ABC"&"def",3,3)) = FALSE Text.HasWideChars(Text.Sub(W"ABC"&"def",2,3)) = TRUE These results have nothing to do with the abstract view of TEXT as a string of characters. Moreover, a principal reason a client of Text would call HasWideChars would be to know whether it could subsequently call, e.g., Text.GetChar without having the value silently truncated to 8 bits. So I propose to fix HasWideChars. This will entail some performance penalties, as in many cases, it will have to go through the character values one at at time in a loop and range-check each one. The alternative would be to redefine HasWideChars as a one-sided approximation, (which is really is now) i.e., such that a result of FALSE means the string is guaranteed to contain no wide characters, but TRUE only means the real answer is unknown. Not very useful, and in that case, it really should be be renamed MightHaveWideChars. What do others think? Anybody using GetWideChars who would be affected? Rodney Bates From hosking at cs.purdue.edu Fri Jan 30 04:43:24 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 30 Jan 2009 14:43:24 +1100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20090130032538.030B410D5DAA@birch.elegosoft.com> References: <20090130032538.030B410D5DAA@birch.elegosoft.com> Message-ID: Probably the wrong place for this. If it is x86-dependent it should go somewhere in the x86 hierarchy, not in a top-level directory like "context". On 30 Jan 2009, at 04:25, Jay Krell wrote: > 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 wagner at elegosoft.com Fri Jan 30 12:19:29 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 30 Jan 2009 12:19:29 +0100 Subject: [M3devel] Semantics of HasWideChars In-Reply-To: <49822309.7030407@wichita.edu> References: <49822309.7030407@wichita.edu> Message-ID: <20090130121929.vz7bla8tm8sc8ggk@mail.elegosoft.com> Quoting "Rodney M. Bates" : > CM3's Text.HasWideChars, as implemented, has some strange behavior. > From Text.i3: > > PROCEDURE HasWideChars (t: T): BOOLEAN; > (* Returns "TRUE" if "t" contains any "WIDECHAR" characters. *) > > This reads to me like it refers to the actual characters comprising t, > which also makes sense to a client of this interface. > > In fact, the implementation returns TRUE if the internal representation > used is capable of representing any wide characters, even though they > could all be narrow. > > Some examples: > > Text.HasWideChars(W"ABC") = TRUE > > Text.HasWideChars(W"ABC"&"def") = TRUE > > Text.HasWideChars(Text.Sub(W"ABC"&"def",3,3)) = FALSE > > Text.HasWideChars(Text.Sub(W"ABC"&"def",2,3)) = TRUE > > These results have nothing to do with the abstract view of TEXT as > a string of characters. Moreover, a principal reason a client of > Text would call HasWideChars would be to know whether it could > subsequently call, e.g., Text.GetChar without having the value > silently truncated to 8 bits. > > So I propose to fix HasWideChars. This will entail some performance > penalties, as in many cases, it will have to go through the character > values one at at time in a loop and range-check each one. > > The alternative would be to redefine HasWideChars as a one-sided > approximation, (which is really is now) i.e., such that a result > of FALSE means the string is guaranteed to contain no wide characters, > but TRUE only means the real answer is unknown. Not very useful, and in > that case, it really should be be renamed MightHaveWideChars. > > What do others think? Anybody using GetWideChars who would be > affected? I think it should be fixed. If anybody really needs the current semantics, we can add the `might have' predicate later, but I don't see that it is very useful ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Fri Jan 30 15:35:45 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 30 Jan 2009 15:35:45 +0100 Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various Message-ID: <1233326145.8086.12.camel@faramir.m3w.org> As I can see, structure and naming of cm3-min archive for AMD64_LINUX is not consistent with LINUXLIBC6 one... And there is no cminstall inside... What to do? What am I supposed to do with these two per configuration? m3core/src/unix% grep Uucon **/m3m* Common/m3makefile: Interface("Uucontext") darwin-amd64/m3makefile:Interface ("Uucontext") darwin-i386/m3makefile:Interface ("Uucontext") darwin-ppc/m3makefile:Interface ("Uucontext") freebsd-4/m3makefile:Interface ("Uucontext") linux-64/m3makefile:Interface ("Uucontext") linux-i386/m3makefile:Interface("Uucontext") solaris-2-x/m3makefile:Interface ("Uucontext") I've added my cm3.spec to archive and built binaries for LINUXLIBC6 without problem... Same day I tried AMD64_LINUX through analog process and - build fails. Anybody had success with AMD64_LINUX build in recent CVS heads? TIA, -- Dragi?a Duri? From jay.krell at cornell.edu Fri Jan 30 16:37:05 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 30 Jan 2009 15:37:05 +0000 Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various In-Reply-To: <1233326145.8086.12.camel@faramir.m3w.org> References: <1233326145.8086.12.camel@faramir.m3w.org> Message-ID: The alternate naming and lack of cminstall is mostly deliberate. The "posix" in "amd64 linux posix" is redundant. I just call it "amd64 linux". Deliberate. The lack of a timestamp is due to "not yet implemented". (Thus "mostly" deliberate.) cminstall isn't needed. Deliberate. You just extract the archive and set $PATH. The cm3.cfg file in the archive should just work. If it doesn't, please let me know. All the releases I make and upload are like this, including the LINUXLIBC6 ones. The Uucontext.i3 problem should be fixed now. - Jay ---------------------------------------- > From: dragisha at m3w.org > To: m3devel at elegosoft.com > Date: Fri, 30 Jan 2009 15:35:45 +0100 > Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various > > As I can see, structure and naming of cm3-min archive for AMD64_LINUX is > not consistent with LINUXLIBC6 one... And there is no cminstall > inside... What to do? > > What am I supposed to do with these two per configuration? > > m3core/src/unix% grep Uucon **/m3m* > Common/m3makefile: Interface("Uucontext") > darwin-amd64/m3makefile:Interface ("Uucontext") > darwin-i386/m3makefile:Interface ("Uucontext") > darwin-ppc/m3makefile:Interface ("Uucontext") > freebsd-4/m3makefile:Interface ("Uucontext") > linux-64/m3makefile:Interface ("Uucontext") > linux-i386/m3makefile:Interface("Uucontext") > solaris-2-x/m3makefile:Interface ("Uucontext") > > I've added my cm3.spec to archive and built binaries for LINUXLIBC6 > without problem... Same day I tried AMD64_LINUX through analog process > and - build fails. Anybody had success with AMD64_LINUX build in recent > CVS heads? > > TIA, > > -- > Dragi?a Duri? > From dragisha at m3w.org Fri Jan 30 22:33:16 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 30 Jan 2009 22:33:16 +0100 Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various In-Reply-To: References: <1233326145.8086.12.camel@faramir.m3w.org> Message-ID: <1233351197.8086.268.camel@faramir.m3w.org> What remains as a problem is /lib vs. /lib64 thing. I've done this by applying this: @@ -37,9 +37,13 @@ %------------------------------------------------------------------------------ readonly BIN_INSTALL = INSTALL_ROOT & SL & "bin" % executables -readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & PROFILING_P % libraries +if equal(TARGET, "AMD64_LINUX") + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib64" & PROFILING_P % libraries +else + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & PROFILING_P % libraries +end readonly PKG_INSTALL = INSTALL_ROOT & SL & "pkg" % packages readonly DOC_INSTALL = INSTALL_ROOT & SL & "doc" % documents This way I can choose which development to use, while maintaining both runtimes on-system. LINUXLIBC6 and AMD64_LINUX separation will work for pkg, but folder containing links - $INSTALLROOT + SL + "lib" on AMD64_LINUX must use lib64. On Fri, 2009-01-30 at 15:37 +0000, Jay wrote: > The alternate naming and lack of cminstall is mostly deliberate. > > The "posix" in "amd64 linux posix" is redundant. I just call it "amd64 linux". Deliberate. > > The lack of a timestamp is due to "not yet implemented". (Thus "mostly" deliberate.) > > cminstall isn't needed. Deliberate. > > You just extract the archive and set $PATH. > The cm3.cfg file in the archive should just work. > If it doesn't, please let me know. > > > All the releases I make and upload are like this, including the LINUXLIBC6 ones. > > > The Uucontext.i3 problem should be fixed now. > > - Jay > > ---------------------------------------- > > From: dragisha at m3w.org > > To: m3devel at elegosoft.com > > Date: Fri, 30 Jan 2009 15:35:45 +0100 > > Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various > > > > As I can see, structure and naming of cm3-min archive for AMD64_LINUX is > > not consistent with LINUXLIBC6 one... And there is no cminstall > > inside... What to do? > > > > What am I supposed to do with these two per configuration? > > > > m3core/src/unix% grep Uucon **/m3m* > > Common/m3makefile: Interface("Uucontext") > > darwin-amd64/m3makefile:Interface ("Uucontext") > > darwin-i386/m3makefile:Interface ("Uucontext") > > darwin-ppc/m3makefile:Interface ("Uucontext") > > freebsd-4/m3makefile:Interface ("Uucontext") > > linux-64/m3makefile:Interface ("Uucontext") > > linux-i386/m3makefile:Interface("Uucontext") > > solaris-2-x/m3makefile:Interface ("Uucontext") > > > > I've added my cm3.spec to archive and built binaries for LINUXLIBC6 > > without problem... Same day I tried AMD64_LINUX through analog process > > and - build fails. Anybody had success with AMD64_LINUX build in recent > > CVS heads? > > > > TIA, > > > > -- > > Dragi?a Duri? > > -- Dragi?a Duri? From jay.krell at cornell.edu Fri Jan 30 22:53:17 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 30 Jan 2009 21:53:17 +0000 Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various In-Reply-To: <1233351197.8086.268.camel@faramir.m3w.org> References: <1233326145.8086.12.camel@faramir.m3w.org> <1233351197.8086.268.camel@faramir.m3w.org> Message-ID: That's very reasonable. You could just commit that imho. More general and reasonable would be: > + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & WORD_SIZE & PROFILING_P % libraries or even > + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib/" & TARGET & PROFILING_P % libraries though granted, most systems aren't biarch/multiarch, so what you have is maybe best, possibly manually adding in biarch/multiarch systems as they are discovered -- e.g. most but not all x86 systems. (This area is actually "surprisingly large" Irix has two 32bit ABIs, there are 32bit ABIs for IA64, I think like on HP-UX). The full lib/TARGET helps for NT386 vs. NT386GNU. - Jay ---------------------------------------- > Subject: RE: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various > From: dragisha at m3w.org > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Date: Fri, 30 Jan 2009 22:33:16 +0100 > > What remains as a problem is /lib vs. /lib64 thing. > > I've done this by applying this: > > @@ -37,9 +37,13 @@ > > %------------------------------------------------------------------------------ > > readonly BIN_INSTALL = INSTALL_ROOT & SL & "bin" % executables > -readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & PROFILING_P % libraries > +if equal(TARGET, "AMD64_LINUX") > + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib64" & PROFILING_P % libraries > +else > + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & PROFILING_P % libraries > +end > readonly PKG_INSTALL = INSTALL_ROOT & SL & "pkg" % packages > readonly DOC_INSTALL = INSTALL_ROOT & SL & "doc" % documents > > > This way I can choose which development to use, while maintaining both > runtimes on-system. LINUXLIBC6 and AMD64_LINUX separation will work for > pkg, but folder containing links - $INSTALLROOT + SL + "lib" on > AMD64_LINUX must use lib64. > > On Fri, 2009-01-30 at 15:37 +0000, Jay wrote: >> The alternate naming and lack of cminstall is mostly deliberate. >> >> The "posix" in "amd64 linux posix" is redundant. I just call it "amd64 linux". Deliberate. >> >> The lack of a timestamp is due to "not yet implemented". (Thus "mostly" deliberate.) >> >> cminstall isn't needed. Deliberate. >> >> You just extract the archive and set $PATH. >> The cm3.cfg file in the archive should just work. >> If it doesn't, please let me know. >> >> >> All the releases I make and upload are like this, including the LINUXLIBC6 ones. >> >> >> The Uucontext.i3 problem should be fixed now. >> >> - Jay >> >> ---------------------------------------- >>> From: dragisha at m3w.org >>> To: m3devel at elegosoft.com >>> Date: Fri, 30 Jan 2009 15:35:45 +0100 >>> Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various >>> >>> As I can see, structure and naming of cm3-min archive for AMD64_LINUX is >>> not consistent with LINUXLIBC6 one... And there is no cminstall >>> inside... What to do? >>> >>> What am I supposed to do with these two per configuration? >>> >>> m3core/src/unix% grep Uucon **/m3m* >>> Common/m3makefile: Interface("Uucontext") >>> darwin-amd64/m3makefile:Interface ("Uucontext") >>> darwin-i386/m3makefile:Interface ("Uucontext") >>> darwin-ppc/m3makefile:Interface ("Uucontext") >>> freebsd-4/m3makefile:Interface ("Uucontext") >>> linux-64/m3makefile:Interface ("Uucontext") >>> linux-i386/m3makefile:Interface("Uucontext") >>> solaris-2-x/m3makefile:Interface ("Uucontext") >>> >>> I've added my cm3.spec to archive and built binaries for LINUXLIBC6 >>> without problem... Same day I tried AMD64_LINUX through analog process >>> and - build fails. Anybody had success with AMD64_LINUX build in recent >>> CVS heads? >>> >>> TIA, >>> >>> -- >>> Dragi?a Duri? >>> > -- > Dragi?a Duri? > From dragisha at m3w.org Fri Jan 30 23:02:35 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 30 Jan 2009 23:02:35 +0100 Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various In-Reply-To: References: <1233326145.8086.12.camel@faramir.m3w.org> <1233351197.8086.268.camel@faramir.m3w.org> Message-ID: <1233352955.8086.270.camel@faramir.m3w.org> "lib" & WORD_SIZE is not usual, IMO, because lib64 is addition, and lib was always there. Also - best approach would be to scratch itch by itch. Trying too generally can make mess in advance. What script do you use to make yours cm3-min? dd On Fri, 2009-01-30 at 21:53 +0000, Jay wrote: > That's very reasonable. You could just commit that imho. > > > More general and reasonable would be: > > > > + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & WORD_SIZE & PROFILING_P % libraries > > or even > > > + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib/" & TARGET & PROFILING_P % libraries > > > though granted, most systems aren't biarch/multiarch, so what you have is maybe best, possibly manually adding in biarch/multiarch systems as they are discovered -- e.g. most but not all x86 systems. (This area is actually "surprisingly large" Irix has two 32bit ABIs, there are 32bit ABIs for IA64, I think like on HP-UX). > > > The full lib/TARGET helps for NT386 vs. NT386GNU. > > - Jay > > > ---------------------------------------- > > Subject: RE: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various > > From: dragisha at m3w.org > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Date: Fri, 30 Jan 2009 22:33:16 +0100 > > > > What remains as a problem is /lib vs. /lib64 thing. > > > > I've done this by applying this: > > > > @@ -37,9 +37,13 @@ > > > > %------------------------------------------------------------------------------ > > > > readonly BIN_INSTALL = INSTALL_ROOT & SL & "bin" % executables > > -readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & PROFILING_P % libraries > > +if equal(TARGET, "AMD64_LINUX") > > + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib64" & PROFILING_P % libraries > > +else > > + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & PROFILING_P % libraries > > +end > > readonly PKG_INSTALL = INSTALL_ROOT & SL & "pkg" % packages > > readonly DOC_INSTALL = INSTALL_ROOT & SL & "doc" % documents > > > > > > This way I can choose which development to use, while maintaining both > > runtimes on-system. LINUXLIBC6 and AMD64_LINUX separation will work for > > pkg, but folder containing links - $INSTALLROOT + SL + "lib" on > > AMD64_LINUX must use lib64. > > > > On Fri, 2009-01-30 at 15:37 +0000, Jay wrote: > >> The alternate naming and lack of cminstall is mostly deliberate. > >> > >> The "posix" in "amd64 linux posix" is redundant. I just call it "amd64 linux". Deliberate. > >> > >> The lack of a timestamp is due to "not yet implemented". (Thus "mostly" deliberate.) > >> > >> cminstall isn't needed. Deliberate. > >> > >> You just extract the archive and set $PATH. > >> The cm3.cfg file in the archive should just work. > >> If it doesn't, please let me know. > >> > >> > >> All the releases I make and upload are like this, including the LINUXLIBC6 ones. > >> > >> > >> The Uucontext.i3 problem should be fixed now. > >> > >> - Jay > >> > >> ---------------------------------------- > >>> From: dragisha at m3w.org > >>> To: m3devel at elegosoft.com > >>> Date: Fri, 30 Jan 2009 15:35:45 +0100 > >>> Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various > >>> > >>> As I can see, structure and naming of cm3-min archive for AMD64_LINUX is > >>> not consistent with LINUXLIBC6 one... And there is no cminstall > >>> inside... What to do? > >>> > >>> What am I supposed to do with these two per configuration? > >>> > >>> m3core/src/unix% grep Uucon **/m3m* > >>> Common/m3makefile: Interface("Uucontext") > >>> darwin-amd64/m3makefile:Interface ("Uucontext") > >>> darwin-i386/m3makefile:Interface ("Uucontext") > >>> darwin-ppc/m3makefile:Interface ("Uucontext") > >>> freebsd-4/m3makefile:Interface ("Uucontext") > >>> linux-64/m3makefile:Interface ("Uucontext") > >>> linux-i386/m3makefile:Interface("Uucontext") > >>> solaris-2-x/m3makefile:Interface ("Uucontext") > >>> > >>> I've added my cm3.spec to archive and built binaries for LINUXLIBC6 > >>> without problem... Same day I tried AMD64_LINUX through analog process > >>> and - build fails. Anybody had success with AMD64_LINUX build in recent > >>> CVS heads? > >>> > >>> TIA, > >>> > >>> -- > >>> Dragi?a Duri? > >>> > > -- > > Dragi?a Duri? > > -- Dragi?a Duri? From jay.krell at cornell.edu Fri Jan 30 23:33:56 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 30 Jan 2009 22:33:56 +0000 Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various In-Reply-To: <1233352955.8086.270.camel@faramir.m3w.org> References: <1233326145.8086.12.camel@faramir.m3w.org> <1233351197.8086.268.camel@faramir.m3w.org> <1233352955.8086.270.camel@faramir.m3w.org> Message-ID: > What script do you use to make yours cm3-min? scripts/python/make-dist.py - Jay ---------------------------------------- > From: dragisha at m3w.org > To: jay.krell at cornell.edu > Date: Fri, 30 Jan 2009 23:02:35 +0100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various > > "lib" & WORD_SIZE is not usual, IMO, because lib64 is addition, and lib > was always there. > > Also - best approach would be to scratch itch by itch. Trying too > generally can make mess in advance. > > What script do you use to make yours cm3-min? > > dd > > On Fri, 2009-01-30 at 21:53 +0000, Jay wrote: >> That's very reasonable. You could just commit that imho. >> >> >> More general and reasonable would be: >> >> >>> + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & WORD_SIZE & PROFILING_P % libraries >> >> or even >> >>> + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib/" & TARGET & PROFILING_P % libraries >> >> >> though granted, most systems aren't biarch/multiarch, so what you have is maybe best, possibly manually adding in biarch/multiarch systems as they are discovered -- e.g. most but not all x86 systems. (This area is actually "surprisingly large" Irix has two 32bit ABIs, there are 32bit ABIs for IA64, I think like on HP-UX). >> >> >> The full lib/TARGET helps for NT386 vs. NT386GNU. >> >> - Jay >> >> >> ---------------------------------------- >>> Subject: RE: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various >>> From: dragisha at m3w.org >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Date: Fri, 30 Jan 2009 22:33:16 +0100 >>> >>> What remains as a problem is /lib vs. /lib64 thing. >>> >>> I've done this by applying this: >>> >>> @@ -37,9 +37,13 @@ >>> >>> %------------------------------------------------------------------------------ >>> >>> readonly BIN_INSTALL = INSTALL_ROOT & SL & "bin" % executables >>> -readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & PROFILING_P % libraries >>> +if equal(TARGET, "AMD64_LINUX") >>> + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib64" & PROFILING_P % libraries >>> +else >>> + readonly LIB_INSTALL = INSTALL_ROOT & SL & "lib" & PROFILING_P % libraries >>> +end >>> readonly PKG_INSTALL = INSTALL_ROOT & SL & "pkg" % packages >>> readonly DOC_INSTALL = INSTALL_ROOT & SL & "doc" % documents >>> >>> >>> This way I can choose which development to use, while maintaining both >>> runtimes on-system. LINUXLIBC6 and AMD64_LINUX separation will work for >>> pkg, but folder containing links - $INSTALLROOT + SL + "lib" on >>> AMD64_LINUX must use lib64. >>> >>> On Fri, 2009-01-30 at 15:37 +0000, Jay wrote: >>>> The alternate naming and lack of cminstall is mostly deliberate. >>>> >>>> The "posix" in "amd64 linux posix" is redundant. I just call it "amd64 linux". Deliberate. >>>> >>>> The lack of a timestamp is due to "not yet implemented". (Thus "mostly" deliberate.) >>>> >>>> cminstall isn't needed. Deliberate. >>>> >>>> You just extract the archive and set $PATH. >>>> The cm3.cfg file in the archive should just work. >>>> If it doesn't, please let me know. >>>> >>>> >>>> All the releases I make and upload are like this, including the LINUXLIBC6 ones. >>>> >>>> >>>> The Uucontext.i3 problem should be fixed now. >>>> >>>> - Jay >>>> >>>> ---------------------------------------- >>>>> From: dragisha at m3w.org >>>>> To: m3devel at elegosoft.com >>>>> Date: Fri, 30 Jan 2009 15:35:45 +0100 >>>>> Subject: [M3devel] AMD64_LINUX; duplicate Uucontext.i3 in m3core/src/unix/...; cm3-min...; various >>>>> >>>>> As I can see, structure and naming of cm3-min archive for AMD64_LINUX is >>>>> not consistent with LINUXLIBC6 one... And there is no cminstall >>>>> inside... What to do? >>>>> >>>>> What am I supposed to do with these two per configuration? >>>>> >>>>> m3core/src/unix% grep Uucon **/m3m* >>>>> Common/m3makefile: Interface("Uucontext") >>>>> darwin-amd64/m3makefile:Interface ("Uucontext") >>>>> darwin-i386/m3makefile:Interface ("Uucontext") >>>>> darwin-ppc/m3makefile:Interface ("Uucontext") >>>>> freebsd-4/m3makefile:Interface ("Uucontext") >>>>> linux-64/m3makefile:Interface ("Uucontext") >>>>> linux-i386/m3makefile:Interface("Uucontext") >>>>> solaris-2-x/m3makefile:Interface ("Uucontext") >>>>> >>>>> I've added my cm3.spec to archive and built binaries for LINUXLIBC6 >>>>> without problem... Same day I tried AMD64_LINUX through analog process >>>>> and - build fails. Anybody had success with AMD64_LINUX build in recent >>>>> CVS heads? >>>>> >>>>> TIA, >>>>> >>>>> -- >>>>> Dragi?a Duri? >>>>> >>> -- >>> Dragi?a Duri? >>> > -- > Dragi?a Duri? > From jay.krell at cornell.edu Fri Jan 30 23:49:25 2009 From: jay.krell at cornell.edu (Jay) Date: Fri, 30 Jan 2009 22:49:25 +0000 Subject: [M3devel] using *context functions for user threading? Message-ID: Tony, can you tell me more of what you have in mind here? In particular...I /think/ it goes like: use getcontext + makecontext to "create a thread" use simple struct copying/memcpy of the third parameter to the signal handler for context switching in particular -- setcontext/makecontext never used -- except to start a thread, but not to switch to/from already started threads. ? Implication here is that even on systems without context APIs, our ucontext_t needs to match what the signal handler gets. That isn't the case for what I just got "working" (prototype, proof of concept, whatever) on OpenBSD, but easy enough. An alternative is to call setcontext in the signal handler, but that makes me nervous. It seems best to exit "cleanly" out of a signal handler? And then I get to seeing very murky things, like, can a system call be interrupted by an alarm signal? If so, switching threads then...what would that do? Seems bad. So then I guess I see the origin of all the original system call wrappers -- to turn of thread switching during system calls. ? The current code does appear to longjmp out of a system call -- or rather, to longjmp from one alarm signal to another. Again this seems confusing if alarm signals can interrupt system calls. Some abstraction that encompasses Win32 fibers might be nice, though there would remain the question of how to preempt. - Jay From hosking at cs.purdue.edu Sat Jan 31 04:09:23 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 31 Jan 2009 14:09:23 +1100 Subject: [M3devel] using *context functions for user threading? In-Reply-To: References: Message-ID: On 31 Jan 2009, at 09:49, Jay wrote: > Tony, can you tell me more of what you have in mind here? I didn't plan anything other than using swapcontext instead of longjmp in switch_thread, and using makecontext instead of InitContext to get a forked thread's context. > In particular...I /think/ it goes like: > > > use getcontext + makecontext to "create a thread" > use simple struct copying/memcpy of the third parameter to the > signal handler for context switching No, swapcontext. > in particular -- setcontext/makecontext never used -- except to > start a thread, but not to switch to/from already started threads. Right. > ? > > > Implication here is that even on systems without context APIs, our > ucontext_t needs to match what the signal handler gets. That isn't > the case for what I just got "working" (prototype, proof of concept, > whatever) on OpenBSD, but easy enough. I don't know what you are saying here. swapcontext should be enough. > An alternative is to call setcontext in the signal handler, but that > makes me nervous. > It seems best to exit "cleanly" out of a signal handler? You're right, but this is probably broken for the current longjmp- based implementation too. > And then I get to seeing very murky things, like, can a system call > be interrupted by an alarm signal? If so, switching threads > then...what would that do? Seems bad. Yes, I was never convinced that the longjmp-based implementation was safe either. I figured that it probably worked only because it was a single-threaded process, but I don't know if that really prevents a timer signal arriving inside the signal handler, and what impact that might have. > So then I guess I see the origin of all the original system call > wrappers -- to turn of thread switching during system calls. No, those were only for GC. > ? > > The current code does appear to longjmp out of a system call -- or > rather, to longjmp from one alarm signal to another. Again this > seems confusing if alarm signals can interrupt system calls. Right... > Some abstraction that encompasses Win32 fibers might be nice, though > there would remain the question of how to preempt. The safest solution for all of this is to have the timer signal handler set a flag and for the M3 compiler to inject a test of the flag at calls/backward branches, and explicitly yield if the flag is set. > > > - Jay From jay.krell at cornell.edu Sat Jan 31 04:46:53 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 31 Jan 2009 03:46:53 +0000 Subject: [M3devel] using *context functions for user threading? In-Reply-To: References: Message-ID: I think setjmp/longjmp would continue to be ok. It has very little machine dependency, and I /guess/ works and is portable. I guess. We are both leary, but it's been there a while. It is InitContext imho that could be "better" -- more portable, remove all the mucking around with frames and stack pointers. I was late to see this because it is in the machine-independent chunk of code. What does swapcontext buy over setjmp/longjmp, once a thread is "already started"? I can see there is a "unifying" reason. If makecontext is used to InitContext, then swapcontext is needed to "start" a thread. setjmp/longjmp could be used to suspend/resume, but if you phrase "start" and "resume" as the same thing, then "stuck" with swapcontext. For some time I was under the impression that Modula-3 repeatedly longjmped to a buffer that only had setjmp called once, or where the function that setjmp was called from had returned, but I'm not sure of that now. It seems viable to "follow the rules" wrt setjmp/longjmp, other than the "escaping from a signal handler" aspect. > The safest solution for all of this is to have the timer signal > handler set a flag and for the M3 compiler to inject a test of the > flag at calls/backward branches, and explicitly yield if the flag is > set. Yes that makes me much more comfortable as well. Is it cut & dry agreed to and such? Someone should just do it? Or there are concerns that: - it might not be often enough? There are no "forward" or "backward" branches at the Modula-3 level, are there? It is at the whim of the backend, right? I guess you might be able to conceptually label branches as forward or backward, even if the backend "rotates" things or adds more branches (you know, like loops often starting with a forward branch). - it might be too often? - it might be too code bloating? Or too slow when "checks" greatly outweight actual switches? - a call out to a function or a check of a variable? - only do it if a compiler command line switch is given? Or for platforms known to support user threads? (given the design though..it could be every platform) Though I raise the issues, it still seems the right thing, vs. longjmping out of a signal handler. The OpenBSD sigaction manpage does seem to have in mind an ability to "switch threads" in a signal handler: "When a caught signal is delivered, the current state of the process is saved, a new signal mask is calculated (as described below), and the signal handler is invoked. The call to the handler is arranged so that if the signal han- dling routine returns normally the process will resume execution in the context from before the signal's delivery. If the process wishes to re- sume in a different context, then it must arrange to restore the previous context itself. " but the idea here is not longjmp or I think exactly swapcontext, but manually swapping a context with the third parameter to the signal handler. > single-threaded process, but I don't know if that really prevents a > timer signal arriving inside the signal handler, and what impact that > might have. Right. I don't see that control-c can't come in at about the same time as timer. Though I think sigaction allows for fixing this -- block all signals during the signal handler. I'll reread some manpages. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Sat, 31 Jan 2009 14:09:23 +1100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] using *context functions for user threading? > > On 31 Jan 2009, at 09:49, Jay wrote: > >> Tony, can you tell me more of what you have in mind here? > > I didn't plan anything other than using swapcontext instead of longjmp > in switch_thread, and using makecontext instead of InitContext to get > a forked thread's context. > >> In particular...I /think/ it goes like: >> >> >> use getcontext + makecontext to "create a thread" >> use simple struct copying/memcpy of the third parameter to the >> signal handler for context switching > > No, swapcontext. > >> in particular -- setcontext/makecontext never used -- except to >> start a thread, but not to switch to/from already started threads. > > Right. > >> ? >> >> >> Implication here is that even on systems without context APIs, our >> ucontext_t needs to match what the signal handler gets. That isn't >> the case for what I just got "working" (prototype, proof of concept, >> whatever) on OpenBSD, but easy enough. > > I don't know what you are saying here. swapcontext should be enough. > >> An alternative is to call setcontext in the signal handler, but that >> makes me nervous. >> It seems best to exit "cleanly" out of a signal handler? > > You're right, but this is probably broken for the current longjmp- > based implementation too. > >> And then I get to seeing very murky things, like, can a system call >> be interrupted by an alarm signal? If so, switching threads >> then...what would that do? Seems bad. > > Yes, I was never convinced that the longjmp-based implementation was > safe either. I figured that it probably worked only because it was a > single-threaded process, but I don't know if that really prevents a > timer signal arriving inside the signal handler, and what impact that > might have. > >> So then I guess I see the origin of all the original system call >> wrappers -- to turn of thread switching during system calls. > > No, those were only for GC. > >> ? >> >> The current code does appear to longjmp out of a system call -- or >> rather, to longjmp from one alarm signal to another. Again this >> seems confusing if alarm signals can interrupt system calls. > > Right... > >> Some abstraction that encompasses Win32 fibers might be nice, though >> there would remain the question of how to preempt. > > The safest solution for all of this is to have the timer signal > handler set a flag and for the M3 compiler to inject a test of the > flag at calls/backward branches, and explicitly yield if the flag is > set. > >> >> >> - Jay > From hosking at cs.purdue.edu Sat Jan 31 05:08:49 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 31 Jan 2009 15:08:49 +1100 Subject: [M3devel] using *context functions for user threading? In-Reply-To: References: Message-ID: <4D53B3C7-7089-4372-AD7C-3B879D43D2C8@cs.purdue.edu> It doesn't work because of security enhancements that prevent forgery of a context as the current system does. swapcontext *is* used on Solaris (as currently implemented) but the InitContext code needs replacing with makecontext. longjmp is not async-signal-safe, and so just as bad as swapcontext when called from a signal handler. Indeed, BSD seems to imply swapcontext can be used in a signal handler. I don't want to leap into explicit polling of a yield flag without further thought. Better to get 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 31 Jan 2009, at 14:46, Jay wrote: > > I think setjmp/longjmp would continue to be ok. > It has very little machine dependency, and I /guess/ works and is > portable. > I guess. We are both leary, but it's been there a while. > It is InitContext imho that could be "better" -- more portable, > remove all the > mucking around with frames and stack pointers. > I was late to see this because it is in the machine-independent > chunk of code. > > > What does swapcontext buy over setjmp/longjmp, once a thread is > "already started"? > I can see there is a "unifying" reason. > If makecontext is used to InitContext, then swapcontext is needed to > "start" a thread. > setjmp/longjmp could be used to suspend/resume, but if you phrase > "start" and "resume" as the same thing, then "stuck" with swapcontext. > > > For some time I was under the impression that Modula-3 repeatedly > longjmped to a buffer that only had setjmp called once, or where the > function that setjmp was called from had returned, but I'm not sure > of that now. It seems viable to "follow the rules" wrt setjmp/ > longjmp, other than the "escaping from a signal handler" aspect. > > >> The safest solution for all of this is to have the timer signal >> handler set a flag and for the M3 compiler to inject a test of the >> flag at calls/backward branches, and explicitly yield if the flag is >> set. > > > Yes that makes me much more comfortable as well. > > > Is it cut & dry agreed to and such? > > > Someone should just do it? > > > Or there are concerns that: > - it might not be often enough? > There are no "forward" or "backward" branches at the Modula-3 > level, are there? > It is at the whim of the backend, right? I guess you might be > able to > conceptually label branches as forward or backward, even if the > backend "rotates" things or > adds more branches (you know, like loops often starting with a > forward branch). > - it might be too often? > - it might be too code bloating? Or too slow when "checks" greatly > outweight actual switches? > - a call out to a function or a check of a variable? > - only do it if a compiler command line switch is given? Or for > platforms known to support user threads? (given the design > though..it could be every platform) > > > Though I raise the issues, it still seems the right thing, vs. > longjmping out of a signal handler. > > > The OpenBSD sigaction manpage does seem to have in mind an ability > to "switch threads" in a signal handler: > > > "When a caught > signal is delivered, the current state of the process is saved, > a new > signal mask is calculated (as described below), and the signal > handler is > invoked. The call to the handler is arranged so that if the > signal han- > dling routine returns normally the process will resume execution > in the > context from before the signal's delivery. If the process > wishes to re- > sume in a different context, then it must arrange to restore the > previous > context itself. > " > > but the idea here is not longjmp or I think exactly swapcontext, but > manually swapping a context with the third parameter to the signal > handler. > > >> single-threaded process, but I don't know if that really prevents a >> timer signal arriving inside the signal handler, and what impact that >> might have. > > > Right. I don't see that control-c can't come in at about the same > time as timer. > Though I think sigaction allows for fixing this -- block all signals > during the signal handler. > I'll reread some manpages. > > > - Jay > > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Sat, 31 Jan 2009 14:09:23 +1100 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] using *context functions for user threading? >> >> On 31 Jan 2009, at 09:49, Jay wrote: >> >>> Tony, can you tell me more of what you have in mind here? >> >> I didn't plan anything other than using swapcontext instead of >> longjmp >> in switch_thread, and using makecontext instead of InitContext to get >> a forked thread's context. >> >>> In particular...I /think/ it goes like: >>> >>> >>> use getcontext + makecontext to "create a thread" >>> use simple struct copying/memcpy of the third parameter to the >>> signal handler for context switching >> >> No, swapcontext. >> >>> in particular -- setcontext/makecontext never used -- except to >>> start a thread, but not to switch to/from already started threads. >> >> Right. >> >>> ? >>> >>> >>> Implication here is that even on systems without context APIs, our >>> ucontext_t needs to match what the signal handler gets. That isn't >>> the case for what I just got "working" (prototype, proof of concept, >>> whatever) on OpenBSD, but easy enough. >> >> I don't know what you are saying here. swapcontext should be enough. >> >>> An alternative is to call setcontext in the signal handler, but that >>> makes me nervous. >>> It seems best to exit "cleanly" out of a signal handler? >> >> You're right, but this is probably broken for the current longjmp- >> based implementation too. >> >>> And then I get to seeing very murky things, like, can a system call >>> be interrupted by an alarm signal? If so, switching threads >>> then...what would that do? Seems bad. >> >> Yes, I was never convinced that the longjmp-based implementation was >> safe either. I figured that it probably worked only because it was a >> single-threaded process, but I don't know if that really prevents a >> timer signal arriving inside the signal handler, and what impact that >> might have. >> >>> So then I guess I see the origin of all the original system call >>> wrappers -- to turn of thread switching during system calls. >> >> No, those were only for GC. >> >>> ? >>> >>> The current code does appear to longjmp out of a system call -- or >>> rather, to longjmp from one alarm signal to another. Again this >>> seems confusing if alarm signals can interrupt system calls. >> >> Right... >> >>> Some abstraction that encompasses Win32 fibers might be nice, though >>> there would remain the question of how to preempt. >> >> The safest solution for all of this is to have the timer signal >> handler set a flag and for the M3 compiler to inject a test of the >> flag at calls/backward branches, and explicitly yield if the flag is >> set. >> >>> >>> >>> - Jay >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Jan 31 18:31:39 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 31 Jan 2009 18:31:39 +0100 Subject: [M3devel] make_dir failure Message-ID: <1233423099.16504.4.camel@faramir.m3w.org> I am trying to build rpm for AMD64_LINUX... I have this situation (strace output fragment) 25802 utimes("/tmp/cm3/usr/local/cm3/pkg/m3core/AMD64_LINUX/libm3core.so", {{1233421816, 0}, {1233421693, 0}}) = 0 25802 stat("/tmp/cm3/usr/local/cm3/bin/../lib64", 0x7fff53109270) = -1 ENOENT (No such file or directory) 25802 stat("/tmp/cm3/usr/local/cm3/bin/..", 0x7fff531090d0) = -1 ENOENT (No such file or directory) 25802 stat("/tmp/cm3/usr/local/cm3/bin", 0x7fff53108f30) = -1 ENOENT (No such file or directory) 25802 stat("/tmp/cm3/usr/local/cm3", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 25802 mkdir("/tmp/cm3/usr/local/cm3/bin", 0777) = 0 25802 mkdir("/tmp/cm3/usr/local/cm3/bin/..", 0777) = -1 EEXIST (File exists) 25802 fcntl(2, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) 25802 fcntl(2, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0 25802 write(2, "\"/usr/src/redhat/BUILD/cm3/m3-li"..., 312) = 312 25802 fcntl(2, F_SETFL, O_RDWR|O_LARGEFILE) = 0 25802 fcntl(2, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) 25802 fcntl(2, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0 25802 write(2, "\n", 1) = 1 25802 fcntl(2, F_SETFL, O_RDWR|O_LARGEFILE) = 0 25802 fcntl(1, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) 25802 fcntl(1, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0 25802 write(1, "Fatal Error: package build faile"..., 34) = 34 25802 fcntl(1, F_SETFL, O_RDWR|O_LARGEFILE) = 0 25802 unlink("m3make.args") = 0 .M3SHIP command in question is: make_dir("/usr/local/cm3/bin/../lib64") Looks like path normalization function are a bit... confused? -- Dragi?a Duri? From jay.krell at cornell.edu Sat Jan 31 20:05:36 2009 From: jay.krell at cornell.edu (Jay) Date: Sat, 31 Jan 2009 19:05:36 +0000 Subject: [M3devel] make_dir failure In-Reply-To: <1233423099.16504.4.camel@faramir.m3w.org> References: <1233423099.16504.4.camel@faramir.m3w.org> Message-ID: It looks ok to me. What happens if you create /usr/local/cm3/bin and /tmp/cm3/usr/local/cm3/bin? Unix is imho bogusly finicky and doesn't like foo/../bar unless foo exists. Windows parses out the .. without checking if foo exists, leaving this sort of construct more useful. The Modula-3/Quake code I think never smushes out the ".." here, but making it do so is very reasonable. This is part of how I avoid cminstall and just having one cm3.cfg -- all the paths are computed from the path of cm3/cm3.cfg. Probably defaulting them in the Modula-3 code instead of requiring them be set by Quake would be good, as part of a larger goal of more Modula-3 and less Quake. Quake coudl still override them if necessary. - Jay ---------------------------------------- > From: dragisha at m3w.org > To: m3devel at elegosoft.com > Date: Sat, 31 Jan 2009 18:31:39 +0100 > Subject: [M3devel] make_dir failure > > I am trying to build rpm for AMD64_LINUX... I have this situation > (strace output fragment) > > 25802 utimes("/tmp/cm3/usr/local/cm3/pkg/m3core/AMD64_LINUX/libm3core.so", {{1233421816, 0}, {1233421693, 0}}) = 0 > 25802 stat("/tmp/cm3/usr/local/cm3/bin/../lib64", 0x7fff53109270) = -1 ENOENT (No such file or directory) > 25802 stat("/tmp/cm3/usr/local/cm3/bin/..", 0x7fff531090d0) = -1 ENOENT (No such file or directory) > 25802 stat("/tmp/cm3/usr/local/cm3/bin", 0x7fff53108f30) = -1 ENOENT (No such file or directory) > 25802 stat("/tmp/cm3/usr/local/cm3", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 > 25802 mkdir("/tmp/cm3/usr/local/cm3/bin", 0777) = 0 > 25802 mkdir("/tmp/cm3/usr/local/cm3/bin/..", 0777) = -1 EEXIST (File exists) > 25802 fcntl(2, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) > 25802 fcntl(2, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0 > 25802 write(2, "\"/usr/src/redhat/BUILD/cm3/m3-li"..., 312) = 312 > 25802 fcntl(2, F_SETFL, O_RDWR|O_LARGEFILE) = 0 > 25802 fcntl(2, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) > 25802 fcntl(2, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0 > 25802 write(2, "\n", 1) = 1 > 25802 fcntl(2, F_SETFL, O_RDWR|O_LARGEFILE) = 0 > 25802 fcntl(1, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) > 25802 fcntl(1, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0 > 25802 write(1, "Fatal Error: package build faile"..., 34) = 34 > 25802 fcntl(1, F_SETFL, O_RDWR|O_LARGEFILE) = 0 > 25802 unlink("m3make.args") = 0 > > .M3SHIP command in question is: > > make_dir("/usr/local/cm3/bin/../lib64") > > Looks like path normalization function are a bit... confused? > -- > Dragi?a Duri? > > From dragisha at m3w.org Sat Jan 31 21:26:19 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 31 Jan 2009 21:26:19 +0100 Subject: [M3devel] make_dir failure In-Reply-To: References: <1233423099.16504.4.camel@faramir.m3w.org> Message-ID: <1233433579.16504.7.camel@faramir.m3w.org> This can look good to you, but this breaks with errno 17 - file exists. Look at 7th row of strace. On Sat, 2009-01-31 at 19:05 +0000, Jay wrote: > It looks ok to me. > What happens if you create /usr/local/cm3/bin and /tmp/cm3/usr/local/cm3/bin? > Unix is imho bogusly finicky and doesn't like foo/../bar unless foo exists. > Windows parses out the .. without checking if foo exists, leaving this sort of construct more useful. > The Modula-3/Quake code I think never smushes out the ".." here, but making it do so is very reasonable. > > > This is part of how I avoid cminstall and just having one cm3.cfg -- all the paths are computed from the path of cm3/cm3.cfg. Probably defaulting them in the Modula-3 code instead of requiring them be set by Quake would be good, as part of a larger goal of more Modula-3 and less Quake. Quake coudl still override them if necessary. > > > - Jay > > ---------------------------------------- > > From: dragisha at m3w.org > > To: m3devel at elegosoft.com > > Date: Sat, 31 Jan 2009 18:31:39 +0100 > > Subject: [M3devel] make_dir failure > > > > I am trying to build rpm for AMD64_LINUX... I have this situation > > (strace output fragment) > > > > 25802 utimes("/tmp/cm3/usr/local/cm3/pkg/m3core/AMD64_LINUX/libm3core.so", {{1233421816, 0}, {1233421693, 0}}) = 0 > > 25802 stat("/tmp/cm3/usr/local/cm3/bin/../lib64", 0x7fff53109270) = -1 ENOENT (No such file or directory) > > 25802 stat("/tmp/cm3/usr/local/cm3/bin/..", 0x7fff531090d0) = -1 ENOENT (No such file or directory) > > 25802 stat("/tmp/cm3/usr/local/cm3/bin", 0x7fff53108f30) = -1 ENOENT (No such file or directory) > > 25802 stat("/tmp/cm3/usr/local/cm3", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 > > 25802 mkdir("/tmp/cm3/usr/local/cm3/bin", 0777) = 0 > > 25802 mkdir("/tmp/cm3/usr/local/cm3/bin/..", 0777) = -1 EEXIST (File exists) > > 25802 fcntl(2, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) > > 25802 fcntl(2, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0 > > 25802 write(2, "\"/usr/src/redhat/BUILD/cm3/m3-li"..., 312) = 312 > > 25802 fcntl(2, F_SETFL, O_RDWR|O_LARGEFILE) = 0 > > 25802 fcntl(2, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) > > 25802 fcntl(2, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0 > > 25802 write(2, "\n", 1) = 1 > > 25802 fcntl(2, F_SETFL, O_RDWR|O_LARGEFILE) = 0 > > 25802 fcntl(1, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) > > 25802 fcntl(1, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0 > > 25802 write(1, "Fatal Error: package build faile"..., 34) = 34 > > 25802 fcntl(1, F_SETFL, O_RDWR|O_LARGEFILE) = 0 > > 25802 unlink("m3make.args") = 0 > > > > .M3SHIP command in question is: > > > > make_dir("/usr/local/cm3/bin/../lib64") > > > > Looks like path normalization function are a bit... confused? > > -- > > Dragi?a Duri? > > > > -- Dragi?a Duri?