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